Claude Code tidak membuat produk Anda menjadi lebih baik

• Efek produktivitas agen coding tidak merata dan terbelah secara berbentuk K, dan metrik utamanya bukan jumlah baris kode per jam melainkan apakah kecepatan peningkatan produk per engineer benar-benar naik
• Dax, Karri Saarinen, dan David Cramer bukan pengkritik AI, tetapi mereka belum memperoleh keyakinan bahwa agen coding secara jelas meningkatkan kecepatan peningkatan produk, dan Cramer menilai LLM menambah kompleksitas serta pembengkakan yang memperlambat laju jangka panjang
• Jika Claude Code memberi keunggulan eksklusif di internal Anthropic selama 7 bulan, jarak dengan para pesaing seharusnya melebar secara majemuk, tetapi Codex, Cursor, Cognition, dan Factory masih tetap bersaing, sehingga besar kemungkinan bottleneck-nya bukan pada produksi kode
• Budaya engineering yang baik memperlakukan jumlah baris kode bukan sebagai aset melainkan biaya, dan ketika fitur serta integrasi bertambah, permukaan bug, dependensi, dan fitur turunan ikut meningkat sehingga kompleksitas bertambah bukan secara linear melainkan secara majemuk
• Di garis depan kualitas produk, dibanding menulis kode dengan cepat, yang lebih penting adalah penilaian dalam selera, kompresi, penghapusan, dan penolakan; Claude Code berguna untuk bergerak dari 0 ke level Camry, tetapi tidak membuat para perajin Ferrari membangun Ferrari yang lebih cepat

---

Kurva produktivitas berbentuk K

• Peningkatan produktivitas dari agen coding tidak merata dan terbelah secara berbentuk K
  • Engineer senior menunjukkan kenaikan output yang terukur sejak titik belok LLM pada 2023
  • Output engineer junior hampir stagnan atau menurun
  • Metrik pentingnya bukan jumlah baris kode per jam, melainkan apakah kecepatan peningkatan produk per engineer benar-benar naik
• Coding berbasis agen memang mengurangi waktu untuk membuat Pull Request pada tugas tertentu
  • Klaim seperti “menyelesaikan backlog 6 tahun dalam satu kuartal”, “membangun backend dalam 3 hari dengan Cursor”, dan “Claude Code sepenuhnya dikodekan dengan Claude” terus berulang
  • Namun, apakah kecepatan produksi kode merupakan metrik yang sama dengan peningkatan kualitas produk tetap menjadi persoalan terpisah

Sinyal peringatan dari engineer yang pandai membangun produk

• Dax, Karri Saarinen, dan David Cramer sama-sama bukan pengkritik AI, tetapi belum yakin bahwa agen coding secara jelas meningkatkan kecepatan peningkatan produk
  • Dax sedang membangun opencode.ai
  • Karri Saarinen adalah CEO Linear
  • David Cramer adalah sosok yang membangun Sentry dari nol hingga tumbuh menjadi bisnis dengan skala 10 juta dolar per bulan
• David Cramer menilai LLM saat ini belum menghasilkan peningkatan produktivitas bersih
  • Hambatan awal memang jadi lebih rendah, tetapi hasilnya adalah software kompleks yang sulit dipelihara
  • Ia mengatakan hal ini tampak memperlambat laju jangka panjang
  • Ia menunjuk masalah pada “kurangnya kemampuan pengembangan bertahap dalam kompleksitas”, “kurangnya kemampuan menyederhanakan secara nyata dan menghasilkan antarmuka yang idiomatis”, serta “teknik pembuatan pengujian yang ceroboh” dari LLM
  • Pada akhirnya, sebagian besar dari itu dinilainya sebagai pembengkakan (bloat)
• Dax mengatakan ia masih belum menemukan dengan jelas cara terbaik memanfaatkan agen coding
  • Sementara itu, di luar sana banyak klaim seperti “semua PR dihasilkan AI”, “kecepatan yang belum pernah ada”, dan “menyelesaikan backlog 6 tahun”
  • Dalam benar-benar meningkatkan kecepatan perbaikan produk, semuanya sama-sama mengalami kesulitan

Keunggulan eksklusif Claude Code tidak tampak sebagai jarak yang melebar

• Jika Claude Code sepenuhnya dikodekan dengan Claude, kecepatan peningkatan produk seharusnya meningkat
  • Bahkan jika penggunaan Claude Code hanya meningkatkan kecepatan peningkatan produk 1,5x, tim yang memakainya sejak awal semestinya makin menjauh dari pesaing seiring waktu
  • Produktivitas engineering adalah fungsi majemuk, jadi perbedaannya seharusnya makin besar setiap kuartal
• Situasi pasar yang nyata tidak menunjukkan jarak majemuk seperti itu
  • Codex dirilis beberapa bulan lebih lambat daripada Claude Code, tetapi secara fungsional sudah mampu bersaing
  • Arus transaksi Cursor kuat
  • Cognition dan Factory juga masih memenangkan kontrak enterprise penting
  • Orang-orang masih memperdebatkan alat mana yang lebih baik
• Bantahan kuncinya adalah: jika Anthropic memiliki Claude Code secara eksklusif selama 7 bulan, maka bila benar ada keunggulan kecepatan produk yang nyata, jarak dengan pesaing seharusnya sudah membesar sampai sulit dikejar
  • Codex seharusnya sudah menjadi tidak relevan, tetapi nyatanya tidak
  • Jika keunggulan majemuk tidak terlihat, besar kemungkinan bottleneck kualitas produk memang bukan pada kode
• Sanggahan yang mungkin justru memperkuat kesimpulan yang sama
  • Mungkin saja ada manfaat, tetapi habis dimakan oleh utang kompleksitas
  • Bisa juga tim engineering Anthropic terlalu besar sehingga keuntungan marjinal per engineer terdilusi
  • Namun bahkan dalam kasus ini pun, bottleneck-nya bukan produksi kode melainkan faktor lain yang lebih sulit

Jumlah baris kode bukan aset, melainkan biaya

• Budaya engineering yang baik memperlakukan jumlah baris kode bukan sebagai hasil produksi melainkan pengeluaran
  • Kode ditulis untuk fitur yang penting, dan tidak ditulis untuk fitur yang tidak penting
  • Codebase lebih dekat ke liabilitas daripada aset di neraca
• Anak perusahaan software milik comma.ai, tinychat, membuat alarm berbunyi ketika codebase melewati ukuran tertentu, dan merayakan kode yang dihapus
  • Setiap baris kode adalah permukaan bug
  • Setiap fungsi menjadi dependensi bagi fungsi berikutnya
  • Setiap fitur melahirkan fitur-fitur di sekitarnya
• Luas permukaan produk berkembang seperti fraktal
  • Jika menambahkan integrasi Slack, maka integrasi Teams dan jalur fallback email juga akan dibutuhkan
  • Jika menambahkan notifikasi, itu harus dibuat ulang agar sesuai dengan mobile, SMS, dan kebijakan enterprise MDM
  • Jika menambahkan dukungan MFA, maka harus kompatibel dengan Duo, Okta, dan SAML
  • Kompleksitas meningkat bukan secara linear, melainkan secara majemuk
• Linear memiliki 178 karyawan, berusia 6 tahun, dan berada di skala ARR 100 juta dolar
  • Jira 56 kali lebih besar daripada Linear dalam akumulasi upaya engineering, tetapi skor kualitas konsumennya tercatat 6 poin lebih rendah
  • Intinya, kualitas dan massa codebase bukanlah hal yang sama
• Pada skala seperti Facebook, kemampuan memproduksi kode UI dengan cepat bukanlah bottleneck
  • Engineer berpengalaman bisa membuat mockup feed Facebook dalam satu hari
  • Kendala nyata adalah mengurangi jumlah baris kode yang dibutuhkan untuk menghadirkan pengalaman itu kepada miliaran orang dengan uptime terjaga pada beban dan latensi apa pun
  • Fungsi imbalannya bukan produksi, melainkan kompresi
  • Dalam pekerjaan seperti ini, agen coding tidak bisa menilai trade-off jangka panjang dan tidak memiliki teori tentang sistem

Bottleneck yang sebenarnya adalah kemampuan mendorong frontier ide produk yang baik

• Peningkatan kualitas produk di frontier dibatasi bukan oleh seberapa cepat kode bisa ditulis, melainkan oleh seberapa cepat ide yang cukup baik untuk mendorong frontier itu bisa ditemukan
• Perbedaan antara Jira dan Linear bukan soal siapa menggambar kotak yang lebih baik
  • Linear punya visi kreatif yang spesifik tentang seperti apa software manajemen proyek seharusnya terasa, dan mengeksekusinya dengan disiplin selama bertahun-tahun
  • Kualitas seperti ini tidak lahir dari throughput token, melainkan dari selera dan keputusan untuk membuat lebih sedikit
• Klaim “menyelesaikan backlog 6 tahun” tidak seimpresif yang terdengar
  • Backlog yang penuh dengan fitur CRUD dan alat internal memang cocok dengan jenis pekerjaan yang dipercepat oleh agen coding
  • Pada saat yang sama, pekerjaan seperti itu bukan pekerjaan yang mendorong frontier produk
  • Produk tidak menjadi lebih baik hanya karena dirilis lebih cepat; produk menjadi lebih baik ketika apa yang dirilis membuat pengguna lebih peduli
• Agen coding AI memang membantu produk bergerak dari 0 ke 1 untuk lebih cepat mencapai frontier kualitas
  • Waktu menuju versi pertama yang berjalan menjadi lebih singkat
  • Peningkatan kecepatan pada pekerjaan tahap awal memang nyata
• Tetapi ada biayanya
  • Codebase bertumbuh lebih cepat daripada kualitas
  • Utang teknis menumpuk secara majemuk
  • Kecepatan yang didapat sekarang dibeli dengan biaya yang harus dibayar nanti

Camry untuk semua orang, Ferrari untuk tidak seorang pun

• Bottleneck bagi tim di frontier bukanlah agen coding, melainkan orang-orang yang punya selera
  • Kemampuan untuk menjadi yang terbaik dengan “selera untuk memangkas” seperti pada Linear dan Sentry ada pada orang-orang tertentu
  • Nan Yu dari Linear dan Kelly Johnson dari Skunk Works disebut sebagai contoh
  • Tim pilihan Kelly Johnson membuat SR-71, dan SR-71 masih disebut sebagai pesawat berawak air-breathing tercepat bahkan 60 tahun kemudian
  • Blackbird cepat bukan karena menghasilkan lebih banyak blueprint, tetapi karena Johnson punya teori tentang apa yang tidak perlu dipertahankan
  • Selera untuk menghapus, mengompresi, dan menolak tidak ada dalam roadmap model frontier mana pun, dan justru makin bernilai ketika batas bawah terus naik
• Jika Anda sudah berada di frontier, belum jelas apakah menggandakan biaya R&D lewat pengeluaran token benar-benar menciptakan nilai ekonomi
  • Engineer Ramp disebut pada dasarnya telah menggandakan gaji mereka selama setahun terakhir lewat pengeluaran token
  • Sulit memastikan apakah produk Ramp benar-benar menjadi lebih baik
  • Jika sudah nomor satu, tingkat kemenangan hampir tetap, dan menjadi “nomor satu dengan selisih lebih besar” sulit diukur
  • Untuk mengubah penilaian, diperlukan data win rate atau profit and loss Ramp
  • Sebagai pelanggan Ramp, penulis menyatakan tidak merasakan perbedaan antara sekarang dan tahun lalu
• Claude Code bisa membantu siapa pun membangun produk pesaing Camry, tetapi tidak membantu para perajin Ferrari membuat Ferrari yang lebih cepat
  • Sangat berguna untuk bergerak dari 0 ke level Camry
  • Biaya produksi software yang bukan kelas tertinggi kemungkinan akan turun drastis
  • Sebagai gantinya, banyak kekacauan dan utang akan menumpuk di kasau pabrik, dan pada akhirnya seseorang tetap harus membereskannya

[GN⁺]

Opini di Lobste.rs

• Kompleksitas meningkat secara eksponensial, dan mungkin bahkan lebih cepat dari itu. Karena itu, bahkan orang-orang yang takut pada singularitas AGI pun sering melewatkan hal ini: tidak peduli seberapa pintar manusia, model, atau agen, ketika ide, sistem, proyek, codebase, atau kumpulan fitur membesar, pada akhirnya mereka akan menabrak tembok kompleksitas yang naik tajam
  Semua proyek perangkat lunak pada awalnya relatif berjalan mulus, tetapi pada titik tertentu pertumbuhan eksponensial kompleksitas akan mengalahkan segalanya. Arsitektur, desain, dan kualitas yang baik hanya menunda titik itu; orang-orang yang kompeten dengan desain yang baik dan perhatian pada kualitas mungkin bisa membuatnya bertahan 10 kali lebih lama dalam hal ukuran, fitur, performa, dan faktor wow, tetapi pada akhirnya tetap akan mencapai tembok itu
  Bantuan LLM memungkinkan pembuatan fitur dan kode dengan kualitas tingkat tertentu, umumnya kualitas rata-rata, jauh lebih cepat. Artinya, tembok itu juga dicapai jauh lebih cepat. Ini bagus untuk pertumbuhan, eksperimen, dan pekerjaan berkompleksitas rendah yang relatif mudah tetapi memakan waktu, tetapi bukan sesuatu yang memungkinkan Anda membuat hal yang belum pernah ada sebelumnya atau proyek besar dan kompleks. Untuk itu yang dibutuhkan adalah perbaikan yang menahan kompleksitas, dan LLM saat ini belum benar-benar memberikannya

  • Ini masalah klasik. Jika sebab dan akibat terhubung langsung, keuntungan langsung mudah terlihat, tetapi jika ada jeda waktu antara sebab dan akibat, dampak negatif jauh lebih sulit dilihat
    http://bastiat.org/en/twisatwins.html
    Biaya penggunaan agen kode tidak terlihat secara langsung, dan terutama muncul dari hilangnya pemahaman kolektif tentang bagaimana sistem bekerja
  • Meski begitu, pengorganisasian hierarkis memang memberi jalan untuk mengelola kompleksitas berskala besar. Di alam pun kita bisa melihat struktur yang sangat kompleks muncul dengan cara ini. Sistem bisa dibangun dengan unit-unit independen yang digabungkan menjadi struktur yang lebih besar
    Sistem yang tangguh harus mampu bertahan dari guncangan dan beradaptasi sendiri, jadi tiap bagian harus bisa gagal secara mandiri dan kerusakan harus tetap terlokalisasi. Jika sistem diatur sebagai subsistem bertingkat, akan muncul unit mirip sel yang saling berkomunikasi untuk menyelesaikan pekerjaan. Unit-unit ini bertindak seperti subrakitan yang stabil tanpa perlu mengetahui proses internal sel lain
    Karena tiap lapisan tidak tersandera oleh apa yang terjadi di tempat lain, ia bisa mengatur dirinya sendiri dalam wilayahnya dan mempertahankan ketahanan. Ini pada dasarnya adalah cara mengenkapsulasi kompleksitas insidental di balik antarmuka, dan membuat abstraksi di mana antarmuka itu membawa makna. Lapisan lebih tepat dipandang sebagai jaringan penghubung yang menyatukan komponen dalam sistem besar
    Erlang OTP adalah contoh bagus pendekatan ini dalam perangkat lunak, dengan menyusun sistem besar sebagai proses-proses terisolasi yang saling bertukar pesan. Jika satu proses mati atau mengalami error, itu tidak meruntuhkan seluruh sistem
  • Menurut saya, “menahan kompleksitas” membutuhkan keputusan, pendirian, dan kadang penolakan atau konflik
    Jika Anda meminta seseorang mengimplementasikan sesuatu, mereka bisa menjawab seperti “ini terlalu kompleks”, “ini akan meledak setahun lagi”, “ini tidak kompatibel dengan yang sedang dikerjakan tim Y”, atau “tidak ada cukup orang untuk mengimplementasikannya”. Pernyataan terakhir bisa benar-benar faktual, atau bisa juga cara tidak langsung untuk mengatakan “tidak bisa”
    Kemungkinan LLM menjawab seperti itu sangat kecil. Terutama karena ia disetel agar optimistis dan sopan. Lagi pula, kecenderungan itu tampaknya diperlukan untuk meningkatkan engagement, jadi kecil kemungkinan penyetelannya akan diubah
    Masalah ini tampak mirip dengan kasus LLM yang membantu bunuh diri penggunanya. Itu saja sudah cukup jelas, dan LLM sudah sering melakukannya. Kematian proyek akibat kompleksitas yang tidak dikelola jauh lebih tidak jelas daripada itu, jadi ekspektasi bahwa LLM akan menjadi jauh lebih baik dalam waktu dekat tidak terlalu besar

• Penalaran seperti “jika memakai Claude Code benar-benar memberi keunggulan kecepatan pengembangan produk, dan Anthropic memonopolinya selama 7 bulan, maka jurang antara Claude Code dan semua pesaingnya seharusnya tidak mungkin dikejar. Codex seharusnya tidak berarti. Namun orang masih aktif memperdebatkan mana yang lebih baik” tidak terasa kokoh
  Claude Code adalah perangkat lunak yang bagus, tetapi bukan sihir AGI aneh yang membuat persaingan menjadi mustahil

  • Selain itu, Codex juga dibuat dengan vibe coding, jadi perbandingan itu agak lucu dari sisi itu juga. Memulai beberapa bulan lebih awal mungkin tidak terlalu berarti. Banyak fitur tambahan justru lahir dari apa yang benar-benar dilakukan pengguna dengan alat tersebut
    Bukan berarti Claude Code sejak awal sudah punya roadmap yang matang dan hambatan utamanya adalah kecepatan menulis kode. Hambatan utamanya adalah ide. Semua orang sedang mencari tahu sambil jalan
    Saya hanya sekilas membaca tulisannya jadi sulit berkomentar dalam, tetapi terlepas dari masalah kapitalisasi awal kalimat, sebagian besar tulisannya tampak seperti prosa yang ditulis LLM, jadi saya tidak terlalu ingin membacanya

• Sejauh ini, kesalahan agen cenderung terakumulasi secara multiplikatif
  Jika Anda membuat API yang secara teknis berfungsi tetapi membutuhkan sedikit kode tambahan saat dipakai, hasilnya adalah lebih banyak kode, lebih banyak duplikasi, cabang, dan tempat munculnya bug. Lalu seperti fraktal, lebih banyak lagi kode yang tidak terlalu bagus akan ditulis
  Pernah ada agen yang merancang struct dengan field id yang opsional. Field itu diperlukan hanya karena satu constructor yang ia tulis sendiri. Lalu ia tanpa lelah menulis dua versi kode untuk kasus saat id ada dan saat id tidak ada, bahkan membuat jalur fallback yang canggung untuk kasus tanpa id. Jalur fallback itu tentu saja kompleks dan rapuh. Hampir semua penggunaan struct itu, bahkan hal-hal yang bergantung padanya, ikut terinfeksi, padahal constructor tanpa id itu sendiri bahkan tidak pernah dipakai. Separuh codebase bisa dihapus dengan mudah
  Saya benar-benar tidak tahu apakah ini bisa diperbaiki hanya dengan cukup banyak instruksi seperti “kalau sedang melakukan hal bodoh, berhentilah menggali”, lalu tinggal beberapa hack lagi sampai coding benar-benar “terpecahkan”, atau apakah ini masalah jangka panjang dari nuri stokastik, sehingga peningkatan biaya yang eksponensial akan terus dibutuhkan demi perbaikan yang linear. Selama kesalahan menumpuk seperti bunga majemuk, pertumbuhan majemuk pada akhirnya akan menjegal

  • Saya juga pernah melihat hal yang sangat mirip terjadi pada developer manusia. Salah satu ciri yang membedakan developer terbaik, menurut saya, adalah kecenderungan untuk berhenti sejenak dan melihat dari level yang lebih tinggi dan lebih luar
    Kadang ini bahkan mencakup proses bisnis. Developer yang sangat memahami domain bisa saja, alih-alih menghabiskan berbulan-bulan mengimplementasikan solusi teknis, bertanya “daripada terus menggali, kenapa tidak ubah prosesnya saja?” dan jawabannya kadang “tentu saja, itu mudah”
    Pada akhirnya LLM tampaknya juga akan menjadi lebih baik dalam hal ini. Bahkan sekarang pun, jika Anda langsung bertanya “pendekatan ini tampaknya tidak bagus, bisa pikirkan alternatifnya?”, cukup sering ia bisa menemukannya. Hanya saja saat ini keberhasilan dan kegagalannya masih tidak konsisten, dan begitu ia sudah melakukan sesuatu yang bodoh, kecil kemungkinan ia akan menyadarinya sendiri ketika sedang mengerjakan hal lain yang tidak terkait
    Ada trade-off di sini juga. Orang-orang sudah mengeluh bahwa model terlalu overthinking dan menghabiskan token. Jika ada pengalaman dan intuisi tentang seperti apa seharusnya kode yang memecahkan masalah tertentu, developer secara alami tahu kapan harus mundur dan meninjau ulang. Mungkin agen juga akan mendapatkan intuisi semacam itu dengan pelatihan yang lebih baik

• Akan menarik melihat pembaruan berdasarkan data setelah titik belok November 2025