Pembaruan tentang laporan kualitas Claude Code terbaru

• Penurunan kualitas Claude yang dirasakan selama sebulan terakhir berasal dari tiga perubahan berbeda yang terpisah di Claude Code, Claude Agent SDK, dan Claude Cowork, dan API tidak terdampak
• Setelah kekuatan penalaran default diturunkan ke medium, latensi dan batas penggunaan memang berkurang, tetapi Claude Code terasa kurang cerdas sehingga default tersebut dikembalikan pada 7 April
• Bug optimasi caching yang dirilis pada 26 Maret membuat sesi yang melewati ambang idle masuk ke keadaan menghapus riwayat penalaran di setiap giliran, yang memicu sifat pelupa, pengulangan, pemilihan tool yang aneh, dan konsumsi usage limits yang lebih cepat
• Satu baris system prompt yang masuk bersama Opus 4.7 pada 16 April dimaksudkan sebagai pembatas untuk mengurangi output yang bertele-tele, tetapi pada evaluasi yang lebih luas performa sebagian model turun 3%, sehingga perubahan itu dibatalkan pada 20 April
• Ketiga masalah tersebut kini sudah diperbaiki dan tercermin dalam v2.1.116 yang dirilis pada 20 April, dengan pengurangan perbedaan antara build internal dan publik, kontrol system prompt yang lebih ketat, evaluasi yang lebih luas, dan rollout bertahap sebagai inti pencegahan terulangnya masalah

---

Cakupan penurunan kualitas terbaru dan status pemulihan

• Penurunan kualitas Claude yang dirasakan sebagian pengguna selama sebulan terakhir berasal dari tiga perubahan terpisah di Claude Code, Claude Agent SDK, dan Claude Cowork, dan API tidak terdampak
• Ketiga masalah tersebut sudah diselesaikan, dan perbaikannya masuk dalam v2.1.116 yang dirilis pada 20 April
• Karena tiap perubahan memengaruhi jadwal yang berbeda dan segmen trafik yang berbeda, secara keseluruhan hal ini terlihat sebagai penurunan performa yang luas tetapi tidak konsisten
• Laporan terkait sudah diselidiki sejak awal Maret, tetapi pada awalnya sulit dibedakan dari fluktuasi umum pada feedback pengguna, dan dalam penggunaan serta evaluasi internal masalah yang sama juga awalnya tidak dapat direproduksi
• Per 23 April, usage limits untuk semua pelanggan telah direset

Perubahan kekuatan penalaran default Claude Code

• Saat merilis Opus 4.6 di Claude Code pada Februari, kekuatan penalaran default diatur ke high
• Tak lama kemudian, pada mode high sesekali muncul waktu berpikir yang terlalu lama sehingga UI tampak seperti macet, dan bagi sebagian pengguna latensi serta penggunaan token menjadi terlalu besar
• Tingkat effort di Claude Code digunakan sebagai cara untuk mengatur apakah model akan berpikir lebih lama atau memilih latensi yang lebih rendah dan konsumsi batas penggunaan yang lebih sedikit
  • Di layer produk, satu nilai default pada kurva komputasi saat inferensi dipilih lalu diteruskan ke Messages API sebagai parameter effort
  • Opsi lainnya tersedia melalui /effort
• Dalam evaluasi dan pengujian internal, medium menunjukkan hasil sedikit lebih rendah dalam kecerdasan tetapi dengan latensi yang jauh lebih rendah untuk mayoritas tugas
  • medium juga lebih jarang mengalami masalah latensi ekor yang sangat panjang
  • Dan juga lebih menguntungkan untuk memaksimalkan usage limits pengguna
• Berdasarkan hasil tersebut, default effort diubah menjadi medium, dan alasannya juga diberi tahu lewat dialog di dalam produk
• Segera setelah dirilis, pengguna mulai merasa Claude Code menjadi kurang cerdas
  • Sejumlah perubahan desain sudah diterapkan, seperti notifikasi saat mulai, pemilih effort inline, dan pemulihan ultrathink, untuk membuat pengaturan effort saat ini lebih terlihat
  • Namun sebagian besar pengguna tetap berada pada default medium
• Setelah mempertimbangkan feedback pelanggan tambahan, keputusan ini dibatalkan pada 7 April
  • Kini semua pengguna memakai xhigh sebagai default di Opus 4.7
  • Dan high menjadi default untuk semua model lainnya
• Perubahan ini memengaruhi Sonnet 4.6 dan Opus 4.6

Optimasi caching yang membuang riwayat penalaran sebelumnya

• Saat Claude menalar sebuah tugas, riwayat penalaran tersebut tetap berada dalam histori percakapan sehingga pada giliran berikutnya model bisa terus merujuk alasan revisi dan pemanggilan tool sebelumnya
• Pada 26 Maret, sebuah perubahan untuk meningkatkan efisiensi fitur ini dirilis
  • Anthropic menggunakan prompt caching untuk membuat panggilan API berurutan menjadi lebih murah dan lebih cepat
  • Saat permintaan API dibuat, Claude menulis token input ke cache, dan setelah periode tidak aktif tertentu prompt itu dihapus dari cache untuk memberi ruang bagi prompt lain
  • Tingkat pemanfaatan cache dikelola dengan hati-hati, dan pendekatan terkait dirangkum dalam approach
• Secara desain, jika sebuah sesi sudah idle lebih dari satu jam, thinking section sebelumnya seharusnya dibersihkan sekali agar biaya melanjutkan sesi menjadi lebih rendah
  • Permintaan itu bagaimanapun akan menjadi cache miss, jadi pesan yang tidak perlu dipotong dari permintaan untuk mengurangi jumlah token uncached yang dikirim ke API
  • Setelah itu, desainnya adalah kembali mengirim seluruh histori penalaran
  • Untuk ini digunakan header API clear_thinking_20251015 dan keep:1
• Dalam implementasi nyata terdapat bug: riwayat thinking seharusnya hanya dibersihkan sekali, tetapi justru terus dibersihkan di setiap giliran sampai sesi berakhir
• Setelah sebuah sesi melewati ambang idle satu kali, semua permintaan berikutnya dari proses tersebut dikirim ke API dengan membuang seluruh blok penalaran sebelumnya kecuali yang paling baru
• Masalah ini memburuk secara kumulatif
  • Jika Claude mengirim pesan lanjutan saat sedang menggunakan tool, itu sendiri menjadi giliran baru di bawah flag yang rusak tersebut
  • Akibatnya, bahkan penalaran pada giliran saat ini pun bisa ikut terbuang
• Claude tetap berjalan, tetapi semakin sering bertindak tanpa ingatan mengapa ia memilih perilaku tersebut
  • Bagi pengguna, ini tampak sebagai sifat pelupa, pengulangan, dan pemilihan tool yang aneh
• Karena blok thinking terus hilang pada permintaan lanjutan, permintaan-permintaan itu juga berujung menjadi cache miss
  • Laporan terpisah bahwa usage limits habis lebih cepat dari perkiraan dinilai berasal dari fenomena ini
• Dua eksperimen yang tidak terkait ikut membuat masalah ini sulit direproduksi pada awalnya
  • Eksperimen internal khusus server-side terkait message queueing
  • Dan perubahan terpisah pada cara thinking ditampilkan yang justru menutupi bug ini pada sebagian besar sesi CLI
• Bug ini berada di titik pertemuan antara manajemen konteks Claude Code, Anthropic API, dan extended thinking
  • Bug ini lolos dari code review oleh beberapa orang dan code review otomatis
  • Pengujian unit dan end-to-end
  • Serta verifikasi otomatis dan dogfooding
• Masalah ini hanya terjadi pada kasus sudut berupa sesi lama dan juga sulit direproduksi, sehingga butuh lebih dari seminggu untuk menemukan dan memastikan akar penyebabnya
• Selama investigasi, pull request yang menimbulkan masalah dibacktest menggunakan Code Review dengan Opus 4.7
  • Jika disertai repositori kode yang diperlukan untuk mengumpulkan konteks penuh, Opus 4.7 berhasil menemukan bug tersebut
  • Opus 4.6 tidak berhasil menemukannya
• Agar hal serupa tidak terulang, dukungan untuk menambahkan repositori tambahan sebagai konteks ke code review sedang diperkenalkan
• Bug ini diperbaiki pada v2.1.101 tanggal 10 April
• Perubahan ini memengaruhi Sonnet 4.6 dan Opus 4.6

Perubahan system prompt yang dimaksudkan untuk mengurangi keluaran yang bertele-tele

• Model terbaru, Claude Opus 4.7, memiliki karakteristik menghasilkan output yang sangat bertele-tele dibanding model sebelumnya
  • Karakteristik ini juga dibahas dalam pemberitahuan saat peluncuran, dan detail lebih lanjut bisa dilihat di wrote about
• Sifat bertele-tele ini membuat model lebih cerdas pada masalah sulit, tetapi juga menambah jumlah token output
• Sejak beberapa minggu sebelum peluncuran Opus 4.7, Claude Code sudah melakukan penyesuaian untuk model baru tersebut
  • Tiap model berperilaku sedikit berbeda, sehingga sebelum rilis harness dan produk dioptimalkan per model
• Untuk mengurangi sifat bertele-tele, digunakan kombinasi pelatihan model, prompting, dan peningkatan UX thinking di dalam produk
• Salah satu baris yang ditambahkan ke system prompt memberi pengaruh terlalu besar terhadap kecerdasan Claude Code
  • “Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”
• Dalam beberapa minggu pengujian internal dan set evaluasi yang dijalankan, tidak terlihat regresi, sehingga perubahan ini dipercaya dan dirilis bersama Opus 4.7 pada 16 April
• Setelah itu, selama investigasi dilakukan ablation menggunakan set evaluasi yang lebih luas untuk memisahkan dan memeriksa dampak tiap baris pada system prompt
• Dalam salah satu evaluasi tersebut, ditemukan penurunan 3% pada Opus 4.6 dan 4.7
• Prompt ini langsung dibatalkan sebagai bagian dari rilis 20 April
• Perubahan ini memengaruhi Sonnet 4.6, Opus 4.6, dan Opus 4.7

Perubahan ke depan

• Untuk menghindari masalah serupa, lebih banyak personel internal akan diubah agar menggunakan Claude Code yang persis sama dengan build publik
  • Ini adalah langkah untuk mengurangi perbedaan antara versi internal untuk pengujian fitur baru dan build publik yang benar-benar digunakan pengguna
• Tool Code Review yang digunakan secara internal akan ditingkatkan, dan versi yang sudah ditingkatkan ini juga akan dibagikan ke pelanggan
• Perubahan system prompt akan diberi prosedur kontrol yang lebih ketat
  • Untuk semua perubahan system prompt di Claude Code, evaluasi luas akan dilakukan per model
  • Ablation untuk memahami dampak tiap baris akan terus dilakukan
  • Tool baru juga sedang dibuat agar perubahan prompt lebih mudah direview dan diaudit
• Ke CLAUDE.md, ditambahkan panduan agar perubahan spesifik model hanya diterapkan pada model tersebut
• Semua perubahan yang bisa bertentangan dengan kecerdasan akan disertai soak period, set evaluasi yang lebih luas, dan rollout bertahap agar masalah bisa ditemukan lebih cepat
• Untuk menjelaskan keputusan produk dan latar belakangnya dengan lebih rinci, akun X @ClaudeDevs telah dibuat, dan pembaruan yang sama juga akan dibagikan ke thread terpusat di GitHub
• Informasi yang disampaikan melalui perintah /feedback atau contoh online yang spesifik dan dapat direproduksi membantu identifikasi dan perbaikan masalah
• Reset usage limits untuk semua pelanggan juga diterapkan kembali pada hari itu

[GN⁺]

Komentar Hacker News

• Penjelasan bahwa menghapus thinking lama pada sesi idle lebih dari 1 jam untuk mengurangi latensi terasa kurang meyakinkan
  Saya biasa membiarkan sesi kosong berjam-jam, bahkan berhari-hari, lalu melanjutkannya lagi dengan seluruh konteks tetap utuh, jadi fitur ini justru inti utamanya
  Menurunkan level thinking default masih cukup bisa dimengerti, tetapi bagian sistem prompt yang terus berubah tampaknya sesuatu yang perlu saya pahami agar bisa sengaja memilih siklus refresh sendiri

  • Di Claude Code, jika ada N pesan dalam percakapan, biasanya N-1 pesan selain 1 yang terbaru masuk ke prompt cache
    Masalahnya, jika sesi dibiarkan idle lebih dari 1 jam, saat prompt dikirim lagi semua N pesan akan kena cache miss
    Corner case ini membuat biaya token pengguna membengkak berlebihan, dan dalam kasus ekstrem seperti konteks 900k tokens, saat kembali sekali saja perlu menulis ulang 900k+ token ke cache, sehingga sangat memangkas rate limit pengguna Pro
    Karena itu mereka sempat mencoba edukasi pengguna di X dan tempat lain, berkali-kali menambahkan tips dalam produk yang menyarankan /clear saat kembali ke percakapan lama, serta menguji cara menghilangkan hasil tool lama, pesan lama, dan sebagian thinking setelah idle, dan dari semua itu penghapusan thinking memberi performa terbaik
    Dalam proses peluncurannya, bug yang tertulis di blog ikut masuk tanpa sengaja, dan mereka bilang siap menjawab pertanyaan lebih lanjut
  • Cukup mengejutkan bahwa perusahaan bernilai puluhan miliar dolar mengambil keputusan seperti ini
    Entah mereka benar-benar percaya bahwa mengorbankan kualitas output demi menurunkan latensi pada sesi idle adalah pilihan yang lebih baik, atau tujuan sebenarnya adalah penghematan biaya dan blog hanya memakai latency sebagai alasan yang terdengar masuk akal
    Akan terasa jauh lebih alami jika mereka sekadar menampilkan indikator loading yang lebih jelas saat konteks dimuat ulang
  • Ini cukup mengejutkan
    Dulu saya memakai CC seperti rekan kerja: memikirkan masalah sebentar, memperbarui rencana, lanjut berpikir sambil mandi, lalu kembali memberi masukan baru, dan setidaknya menganggapnya sebagai percakapan statis selama sekitar sehari
    Tetapi kalau batasnya 1 jam, itu terlalu singkat dan membuat saya berpikir ulang apakah akan terus mempertahankan paket anthropic
  • Penjelasan tentang penghapusan token setelah 1 jam terlihat makin mencurigakan karena waktunya kebetulan pas dengan batas cache mereka
    Sulit menganggap itu kebetulan; lebih mungkin ini perubahan yang memang sangat menurunkan biaya
  • Ini juga tampaknya akan berinteraksi paling buruk dengan reset pemakaian berbasis waktu
    Jika banyak pengguna menghabiskan jatahnya lalu membiarkan sesi beristirahat sebelum kembali lagi, ini bukan pengecualian melainkan hampir pola penggunaan default

• Agak tidak terduga kalau mereka dihantam kritik separah ini
  Tulisannya sendiri relatif jelas dan jujur serta cukup masuk akal saat dibaca
  Penurunan performa itu nyata dan menjengkelkan, tetapi sekaligus juga menyingkap ketidaktransparanan soal apa yang sebenarnya terjadi di balik layar dan struktur penagihan biaya token yang terkesan sewenang-wenang
  Dari sudut pandang orang yang pernah langsung bekerja dengan API LLM, tambahan biaya dan latensi saat melanjutkan percakapan yang lama dibiarkan jelas sudah bisa diduga, tetapi di TUI hal ini memang tampaknya perlu dibuat lebih terlihat

  • Orang marah karena selama berbulan-bulan mereka secara terbuka membantah bahwa ini masalah
    Jadi sekarang pun, meski penjelasannya sudah keluar, resistensinya tetap besar

• Menurut saya sebagian penurunan kualitas mungkin bukan karena modelnya benar-benar memburuk, melainkan perbedaan yang terasa akibat nondeterminisme
  Beberapa minggu lalu saya meminta Claude membuat aplikasi produktivitas pribadi dengan menjelaskan perilaku yang saya inginkan dalam tulisan panjang lalu memintanya menulis rencana implementasi, dan hasil pertama benar-benar sangat bagus kecuali satu bagian ambigu
  Setelah ambiguitas itu saya perbaiki, saya coba mulai dari nol lagi di chat baru tanpa menyuruhnya merevisi rencana lama; pengaturan model tetap sama, tetapi hasilnya jauh lebih buruk, dua percobaan berikutnya juga gagal, dan baru pada percobaan keempat kualitasnya kembali seperti yang pertama
  Jadi saya merasa kadang cara mendapatkan output yang lebih baik memang cukup dengan menyuruhnya mengerjakan tugas yang sama lagi, hanya saja kalau bayar dengan token sendiri itu cepat menjadi mahal

  • Saya juga merasa begitu
    Memang ada pola di mana model terasa memburuk secara berkala, tetapi bisa jadi sebenarnya hanya momen saat ia benar-benar menabrak batas kemampuannya datang lebih lambat
    Dan begitu kita mengalami output buruk karena nasib, setelah itu yang terlihat hanya itu terus
  • Jadi apakah nantinya kita perlu seperti generasi gambar, yaitu menjalankan satu prompt untuk menghasilkan 50 versi lalu manusia memilih yang terbaik secara manual
    Dari sudut pandang Anthropic, pola pemakaian seperti ini juga tentu menarik karena meningkatkan konsumsi token
  • Untuk aplikasi produktivitas yang taruhannya serendah itu, besar kemungkinan membuatnya sendiri akan lebih cepat daripada waktu yang sudah dihabiskan di sini
  • Dari kejadian ini kita memang belajar bahwa LLM jauh lebih nondeterministik daripada dugaan banyak orang, tetapi menghubungkan fakta itu langsung dengan penurunan performa belakangan bisa jadi keliru
    Nondeterminisme itu memang sudah selalu ada, dan penurunan kualitas terbaru yang dilaporkan luas bisa jadi fenomena terpisah

• Saya sudah kehilangan minat sejak Opus 4.7
  OpenAI benar-benar agresif mendekati sisi enterprise kami, sampai menawarkan token tak terbatas hingga musim panas
  Jadi saya memakai GPT5.4 dengan extra high effort selama 30 hari terakhir, dan entah saya mendapat perlakuan khusus atau tidak, saya hampir tidak melihat kesalahan
  Reasoning trace-nya juga kadang bagus sampai lucu, dan bahkan bagian yang lupa saya instruksikan pun ia antisipasi lebih dulu sambil menyiapkan hal-hal yang diperlukan agar integritas data tetap 100%

  • Saya juga merasa serupa
    Segala macam perubahan yang terkesan akal-akalan ini kemungkinan besar terjadi karena Anthropic kekurangan compute sehingga terpaksa mengambil langkah berlebihan untuk menguranginya
  • GPT-5.4 sudah lebih baik daripada Opus 4.6 di banyak area, terutama akurasi dan logika yang rumit
    Jadi saya penasaran seberapa jauh 5.5 akan meningkat
  • extra high membakar token terlalu banyak
    Untuk 90% pekerjaan, menjalankan 5.4 di medium jauh lebih fokus dan minim perubahan, lalu baru dinaikkan ke high kalau medium terlihat kewalahan
  • Betul juga
  • Saya kembali ke 4.5 dan tidak menyesal
    Lagi pula sedikit lebih murah

• Belakangan Claude sering mengeluarkan respons seolah-olah sedang menjawab prompt internalnya sendiri
  Misalnya ia mengatakan kalimat dalam tanda kurung tampak seperti upaya prompt injection sehingga akan diabaikan, atau terlihat seperti usaha menyembunyikan pedoman umumnya sehingga tidak akan dipatuhi, atau bahwa cara seperti itu sebenarnya sudah selalu diterapkan jadi tidak perlu
  Padahal saya sama sekali tidak melakukan hal-hal semacam itu, tetapi ia sering menambahkan kalimat seperti itu di akhir respons
  Sepertinya ada bagian kasar dalam pedoman internalnya dan ia gagal membedakannya dengan pertanyaan saya

  • Saya memakai stop hook scripts yang memaksa pengujian pada setiap perubahan kode, tetapi sejak 4.7 Claude tetap menjalankan skrip sambil secara berkala mengabaikan aturannya
    Saat ditanya alasannya, ia menjawab bahwa menurutnya itu tidak perlu
  • Di OpenAI saya juga sering melihat kasus model seperti menjawab perkataannya sendiri
    Rasanya seperti cara mudah bagi perusahaan untuk menambah token churn
  • Saya juga sering melihat ia memasukkan poin buatannya sendiri ke memory, lalu nanti merujuknya lagi seolah itu klaim saya
    Akibatnya muncul loop penguatan diri: model menetapkan sesuatu, menyimpannya sebagai memori, lalu melihat memori itu lagi dan menumpuk di atasnya, bahkan kadang terus berlanjut meski saya sudah jelas memintanya berhenti
  • Saya penasaran level effort dan prompt aslinya
    Bisa jadi ini gejala dari reasoning effort yang terlalu tinggi, sehingga prompt seperti itu mungkin membaik jika intensitas penalarannya sedikit diturunkan
  • Saya cukup sering meminta Claude menangani commit dan PR juga, dan minggu lalu saya berkali-kali melihatnya melakukan pekerjaan tambahan yang tidak perlu sesuka hati saat proses commit
    Ia sempat tersandung di tahap git add, tetapi dalam auto mode ada satu kali yang nyaris lolos begitu saja

• Alasan menurunkan default reasoning effort dari high ke medium karena latensinya sampai membuat UI terlihat membeku justru terdengar makin mencurigakan
  Artinya mereka menurunkan intensitas penalaran default alih-alih memperbaiki UI, dan penjelasan bahwa mereka serius menelusuri laporan penurunan performa jadi sulit dipercaya

  • Tim bilang mereka melakukan keduanya
    Mereka beberapa kali juga memperbaiki UI, termasuk status loading thinking dan membuat indikator jumlah token yang diunduh lebih jelas
    Meski begitu, setelah evaluasi dan dogfooding mereka tetap menurunkan effort default, dan mereka mengakui itu keputusan yang salah lalu sudah dibatalkan
    Mereka juga mengakui seharusnya bisa memperkirakan bahwa orang tidak benar-benar memahami bahwa kecerdasan bisa ditingkatkan lewat /effort, sehingga banyak yang akan tetap memakai default

• Pernyataan bahwa sesi idle lebih dari 1 jam adalah corner case sama sekali tidak cocok dengan pola penggunaan saya
  Untuk pekerjaan pribadi, saya sering memberi Claude Code tugas 10–15 menit dan menghabiskan cukup banyak waktu bolak-balik dengan model untuk menyusun rencana sebelum eksekusi
  Begitu eksekusi dimulai, saya biasanya pergi mengambil kopi atau beralih ke proyek lain di Codex, jadi kemungkinan besar butuh lebih dari 1 jam sebelum saya kembali ke Claude

  • Itu mungkin corner case hanya menurut ukuran para pengembangnya
    Mengira kebiasaan sendiri mewakili perilaku seluruh pengguna adalah jebakan klasik dalam pengembangan produk
  • Kedengarannya itu juga berarti mereka membuat perubahan sebesar itu tanpa cukup menguji justru kasus tepi tersebut, sehingga ketat tidaknya pengujian pun jadi dipertanyakan

• Pendekatan black box yang diambil lab frontier besar pada akhirnya akan membuat orang pergi
  Jika perilaku mendasar diubah seperti ini tanpa pemberitahuan lebih dulu lalu baru dijelaskan belakangan, pengguna pada akhirnya akan terdorong ke arah model self-hosted
  Sulit membangun pipeline, workflow, dan produk secara stabil di atas fondasi yang lantainya terus bergoyang

• Sepertinya orang-orang Anthropic yang menangani Claude Code membaca komentar-komentar ini, dan beberapa hari lalu saya menonton video theo t3.gg tentang apakah Claude menjadi bodoh
  Nadanya memang kasar dan ada kata-kata yang keras, tetapi khususnya kritik soal harness bloat terasa cukup tepat
  Menurut saya sekarang saatnya berhenti sejenak menambah fitur baru, lalu benar-benar mendorong perapian dan optimasi
  Kalau tidak, makin banyak orang akan mencari alternatif yang lebih ringan dan optimal, dan intinya adalah membuat harness lebih baik sambil menurunkan konsumsi token
  https://youtu.be/KFisvc-AMII?is=NskPZ21BAe6eyGTh

  • Terlepas dari yang lain, eksperimen untuk menghapus dukungan CC dari paket Pro saja sudah cukup membuat saya serius memikirkan alternatif
    Saya memang sudah terus waspada terhadap vendor lock-in, tetapi kejadian itu jadi peringatan yang bagus, dan kemungkinan besar saya akan melihat opencode+openrouter lebih dulu
  • Kita juga tidak boleh lupa video GPT 5 yang berlebihan dari theo dan bagaimana kemudian ia menariknya kembali
    Jelas terlihat ada sesuatu yang mengalir di belakang layar antara sebagian kreator konten dan OpenAI, entah uang atau pengaruh
  • Sejujurnya ini malah terlihat seperti sesuatu yang cukup diselesaikan dengan git reset --hard

• Ini terasa seperti hasil dari obsesi menambah fitur ketimbang menyempurnakan kualitas produk inti
  Saya sering merasa Anthropic butuh beberapa pemimpin produk senior lagi, dengan sudut pandang seperti “Escaping the Build Trap”
  Hanya karena sekarang mereka bisa menambahkan fitur dengan cepat bukan berarti semua fitur harus ditambahkan
  Saya bukan sedang melempar omongan klise organisasi produk hanya karena menyebut buku terkenal; intuisi produk yang baik adalah bakat yang berbeda dari engineering yang baik, dan belakangan Anthropic tampak kurang di area itu

  • Mereka harus mengejar permintaan, tetapi jelas tampak kekurangan sumber daya compute
    Jadi tanpa fitur-fitur seperti ini sistem bisa rusak atau mereka tidak mampu menerima pelanggan baru, dan karena keduanya sama-sama sulit diterima, mungkin mereka memang tidak punya banyak pilihan
  • Ini perusahaan yang dulu katanya punya sekitar 100 developer dengan bayaran 600 ribu dolar per tahun, jadi kekurangan talenta tampaknya bukan masalahnya
    Justru masalahnya mungkin mereka terlalu mendorong narasi vibe coding, sampai ada kandidat yang menolak permintaan wawancara karenanya
  • Mereka tampaknya sudah sangat dalam terjebak jebakan kompleksitas
    Sifat probabilistik modelnya sendiri memang sudah bermasalah, tetapi sekarang kelihatannya mereka bahkan tidak lagi bisa bernalar dengan baik soal software buatan mereka sendiri
    Terlalu banyak tuas dan dial, dan kemungkinan tak ada seorang pun yang benar-benar memahami keseluruhan kodenya
    Yang lebih buruk, melihat komentar dari Dario dan lainnya, manajemen tampaknya tidak terlalu berempati pada kekhawatiran soal kualitas ini
    Di bawah pandangan bahwa SWE bisa digantikan, tuntutan untuk memberi guard rail pada alat seperti diabaikan atau malah ditekan, dan pada akhirnya Claude Code sejak awal terasa lahir lebih sebagai eksperimen ilmiah daripada produk yang sudah matang dengan best practice yang mapan