- Alat coding AI diklaim meningkatkan kecepatan pengembangan, tetapi bottleneck yang sebenarnya bukanlah penulisan kode melainkan proses organisasi yang tidak efisien
- Saat volume produksi kode meningkat, kemacetan pada tahap non-pengembangan seperti antrean review, keterlambatan deployment, dan requirement yang tidak jelas justru makin parah, sehingga cycle time malah bertambah
- Menurut Theory of Constraints dari Eli Goldratt, mengoptimalkan tahap yang bukan bottleneck tidak membuat sistem lebih cepat, melainkan justru merusaknya
- Dalam situasi ketika bahkan penulisnya sendiri tidak sepenuhnya memahami kode yang dihasilkan AI, muncul risiko struktural berupa meluasnya permukaan insiden dan berkurangnya orang yang mampu menalar sistem
- Keunggulan kompetitif bukan jatuh ke tim yang menulis kode paling cepat, melainkan ke tim yang tahu apa yang harus dibangun dan mampu mengirimkannya ke tangan pengguna
Awal dari optimisasi yang keliru
- Muncul klaim bahwa penerapan AI coding assistant meningkatkan output kode sebesar 40%
- Namun pertanyaan “kecepatan untuk menuju apa?” justru tidak dibahas
- Jika sumber daya ditaruh pada tahap yang sebenarnya sudah cepat, yaitu penulisan kode, maka seluruh sistem justru melambat
- Mempercepat bagian yang bukan bottleneck akan menumpuk persediaan kode yang belum selesai, serta memicu penurunan kualitas dan kekacauan
Mengoptimalkan area yang bukan bottleneck justru merusak sistem
- Inti Theory of Constraints yang diperkenalkan dalam novel The Goal karya Eli Goldratt pada 1984: setiap sistem memiliki tepat satu bottleneck, dan throughput total ditentukan oleh throughput bottleneck tersebut
- Jika tahap yang bukan bottleneck dioptimalkan, sistem tidak menjadi lebih cepat; yang terjadi justru penumpukan inventaris pekerjaan yang belum selesai, yang berujung pada lead time yang lebih panjang, kekacauan, dan penurunan kualitas
- Secara analogi, meski stasiun A membuat widget lebih cepat, jika kecepatan proses di stasiun B yang menjadi bottleneck tetap sama, hasilnya hanya tumpukan widget yang belum diproses di antara A dan B
Apa yang sebenarnya terjadi saat "output kode 3x lipat"
- Developer menghasilkan PR lebih cepat dari sebelumnya, tetapi jumlah reviewer tetap sama, sehingga PR menunggu di antrean review selama satu hari, dua hari, bahkan seminggu
- Penulisnya sudah terlanjur berpindah konteks ke fitur lain yang dibantu AI, jadi saat harus merespons komentar review pada kode yang ditulis 8 hari lalu, ia hampir tidak lagi mengingat kodenya
- Karena review terlalu banyak, muncullah rubber-stamp review yang disetujui tanpa benar-benar dibaca
- CI memakan waktu 45 menit, lalu gagal karena flaky test dan harus dijalankan ulang, sementara pipeline deployment menunggu approval manual dari penanggung jawab yang sedang rapat, sehingga fitur dibiarkan di staging selama 3 hari
- Developer sudah membuka 2 PR tambahan, sehingga WIP (Work In Progress) melonjak, semua orang mengerjakan 6 hal sekaligus, dan tidak ada yang benar-benar selesai
- Kode diproduksi lebih banyak, tetapi software yang dirilis justru lebih sedikit; cycle time memburuk, tetapi dashboard tetap menampilkan peningkatan produktivitas 40%
- Risiko tambahan dari kode buatan AI: orang yang “menulisnya” sebenarnya tidak benar-benar menulis, hanya membuat prompt lalu meninjaunya sekilas, sehingga saat terjadi insiden produksi pukul 2 pagi, baik petugas on-call maupun pembuat prompt tidak bisa menjelaskan kode tersebut
- Saat kode bertambah tetapi pemahaman berkurang, itu bukan peningkatan produktivitas, melainkan bom waktu dengan dashboard yang lebih cantik
Bottleneck yang sebenarnya 1: tidak tahu apa yang harus dibangun
- PM tidak berbicara dengan pengguna sungguhan selama 2 bulan, lalu requirement datang hanya dalam bentuk 3 baris tiket Jira dan tautan Figma
- Engineer harus membuat 50 keputusan mikro per hari—perilaku, edge case, penanganan error—tanpa spesifikasi yang jelas, sehingga semuanya dilakukan lewat tebakan
- Ada tim yang membangun fitur selama 6 minggu berdasarkan hal yang mungkin pernah dikatakan calon pelanggan dalam sebuah panggilan, lalu diteruskan oleh staf sales lewat Slack; pada akhirnya calon pelanggan itu tidak jadi membeli, dan fitur tersebut hanya dipakai 11 orang, 9 di antaranya adalah QA internal
- Jika penulisan kode dipercepat, yang meningkat hanyalah kecepatan membuat hal yang salah, karena itu tidak lebih dari otomatisasi atas tebakan
- Bottleneck-nya adalah pemahaman terhadap masalah itu sendiri, dan itu tidak bisa diselesaikan dengan mengetik lebih cepat
Bottleneck yang sebenarnya 2: semua hal setelah kode dinyatakan "selesai"
- Di sebagian besar organisasi, penulisan kode hanya sekitar 20% dari seluruh perjalanan, sementara 80% sisanya adalah waktu menunggu kode berada di berbagai antrean
- Ada kasus fitur yang hanya butuh satu sore untuk dikoding, tetapi memakan waktu 2 bulan untuk mencapai production
- PR review, CI, staging, QA, security review, product approval, deployment window, canary rollout—semuanya adalah rantai panjang handoff, waktu tunggu, dan antrean
- Hampir sepanjang waktu, kode tidak bergerak; ia hanya menunggu seseorang melihatnya, menunggu pipeline berjalan, dan menunggu izin untuk eksis
- Jika ingin merilis lebih cepat, Anda harus mencari titik tempat pekerjaan mengantre, lalu mengukur rasio antara waktu kerja nyata dan waktu tunggu di antrean
Bottleneck yang sebenarnya 3: lingkaran setan ketidakpercayaan terhadap deployment
- Saat test bersifat flaky, observability berantakan, dan tidak ada yang percaya pada proses canary, tim akan takut melakukan deployment
- Karena takut, perubahan dikumpulkan ke dalam rilis yang lebih besar; ini menciptakan risiko yang lebih tinggi, membuat deployment makin menakutkan, lalu perubahan kembali dikumpulkan dalam batch yang lebih besar—terbentuklah lingkaran setan ketakutan
- Jika output kode yang lebih cepat ditambahkan ke kondisi ini, hasilnya: kode makin banyak, budaya deployment tetap dipenuhi rasa takut, sehingga batch makin besar dan frekuensi rilis makin rendah
Bottleneck yang sebenarnya 4: tidak ada feedback setelah rilis
- Setelah fitur dibuat dan dirilis, tidak ada analitik yang memadai, tidak ada wawancara pengguna pascarilis, dan tidak ada seorang pun yang memeriksa apakah fitur itu benar-benar menyelesaikan masalah
- Fitur berikutnya kembali dibangun berdasarkan tebakan, lalu yang sesudahnya juga tebakan; seluruh product roadmap menjadi rangkaian tebakan tanpa feedback
- Output kode yang lebih cepat hanya berarti mempercepat siklus “bangun, rilis, lalu angkat bahu”
Bottleneck yang sebenarnya 5: kalender adalah dinding penopang
- Kadang bottleneck bukan masalah teknis, melainkan rapat untuk pengambilan keputusan, kesepakatan kontrak API antara 3 tim yang sudah sebulan tidak saling bicara, atau backlog 2 minggu milik arsitek yang menjadi satu-satunya titik approval untuk semua desain penting
- Karena proses perencanaan kuartalan memakan waktu 6 minggu, bahkan pekerjaan yang mendesak pun baru bisa dimulai setelah menunggu 5 minggu
- Ada situasi nyata ketika fitur belum dirilis hanya karena masih menunggu rapat dengan orang yang sedang cuti
- Ini adalah masalah koordinasi, masalah manusia, dan masalah politik, tidak ada hubungannya dengan kecepatan menulis kode
Apa yang seharusnya dilakukan
- Value stream mapping: lacak satu fitur dari ide hingga production, lalu catat berapa lama tiap tahap berlangsung dan berapa lama waktu tunggu di antara tahap-tahap tersebut
- Ukur cycle time: bukan jumlah baris kode, jumlah PR yang di-merge, atau story point, melainkan waktu dari commit hingga benar-benar dipakai pengguna di production
- Hilangkan status menunggu: jika PR review butuh 2 hari, atasi dengan pair programming, PR kecil, waktu review khusus, atau norma review asinkron. Jika deployment menunggu approval manual, otomatisasikan atau setidaknya ubah menjadi tombol Slack
- Berhenti memulai, fokus menyelesaikan: ada alasan kenapa batas WIP itu penting; 3 hal yang selesai lebih baik daripada 10 hal yang sedang dikerjakan. Semua item yang masih berjalan membawa biaya context switching
- Bicara dengan orang yang mengerjakan langsung: para developer sebenarnya sudah tahu di mana bottleneck berada; mereka sudah mengeluh di standup dan membuat meme di Slack selama berbulan-bulan. Hanya saja mereka merasa tidak ada yang mendengarkan
Kesimpulan utama
- Alih-alih VP mengumumkan “output kode naik 40%”, ia seharusnya berkata, “analisis value stream kami menunjukkan fitur rata-rata menunggu 9 hari di antara tahap-tahap proses, dan kami akan memangkasnya menjadi setengah”
- Keunggulan kompetitif bukan jatuh ke tim yang menulis kode paling cepat, melainkan ke tim yang mengetahui apa yang harus dibangun, membangunnya, lalu mengirimkannya ke tangan pengguna
- Bottleneck-nya bukan keyboard
4 komentar
> Calon pelanggan tersebut tidak jadi membeli, dan fitur itu hanya digunakan oleh 11 orang (9 di antaranya adalah QA internal)
lol
Pipeline-nya tetap sama
sepertinya cuma para developer yang jadi tidak bertanggung jawab
Rasanya ingin menjadi software craftsman
Komentar Hacker News
Saat tim kami mulai benar-benar mengadopsi pengembangan berbasis agen, kami khawatir kecepatan menulis kode akan naik tetapi waktu review juga ikut membengkak
Sampai sekarang belum ada perubahan yang jelas, dan semua orang masih belajar alur kerja baru jadi datanya belum cukup
Namun ada kasus-kasus di mana coding cepat sangat berguna — eksperimen ide, pekerjaan berulang yang kompleks, implementasi yang sederhana tapi padat tenaga, penanganan edge case setelah happy path, dan sebagainya
Agen juga bekerja sangat baik terutama ketika memperluas branch atau PR yang sudah ada
Peningkatan produktivitas terbesar adalah saya bisa mengerjakan hal lain saat agen menulis kode. Misalnya saya review PR lain, lalu ketika kembali hasilnya sudah ada
Awalnya saya skeptis, tapi sekarang mulai optimistis secara hati-hati. Peningkatan 10x mungkin berlebihan, tapi bahkan 2x peningkatan pun sudah luar biasa
Cara ini hanya layak kalau biaya kesalahannya rendah atau cakupan perubahannya kecil. Kalau tidak, kualitas dan kepuasan turun, sementara jadwal hanya jadi lebih padat
Pada akhirnya ini bukan benar-benar mendapatkan kembali waktu lewat paralelisme, melainkan cuma sedikit mengurangi penundaan terhadap pekerjaan yang memang sudah tertunda
Hanya saja, mengerjakan hal lain saat agen menulis kode menimbulkan rasa lelah yang aneh
AI memang produktif, tetapi ini jenis kerja yang sama sekali berbeda dari coding sebagai kerajinan manusia
Refactor yang kalau dikerjakan sendiri akan sulit ditinggalkan, justru lebih mudah dinilai jujur sebagai “ini ternyata kurang bagus” ketika yang mengerjakannya AI
Kalau terus multitasking, burnout akan datang lebih cepat. Sayang sekali unsur manusianya sering hilang dari diskusi
Saya tidak selalu ingin bekerja dalam keadaan yang ‘teroptimalkan’
Seseorang bilang “memahami masalah itulah bottleneck-nya”, tapi saya ingin bertanya kenapa mengetik cepat tidak bisa membantu memahami masalah
Kalau kita cepat membuat sesuatu yang salah, bukankah itu juga bisa membantu menemukan arah yang benar lebih cepat?
Saya sering baru sadar apa yang sebenarnya saya inginkan setelah mencoba membuat sesuatu. Semakin murah biaya membuat prototipe, semakin kuat kecenderungan ini
Tentu saja, akhirnya sering tetap berujung pada refleksi “kita seharusnya lebih banyak bicara dengan pengguna”, tapi itu masalah lain
Di tempat seperti bank, eksperimen paling banter cuma bisa dilakukan sekitar sekali seminggu
Tapi sebagian besar software tidak seperti itu. Menulis kode hanyalah sebagian dari seluruh pekerjaan
Sama seperti ahli bedah bukan cuma ‘orang yang memotong’, engineer juga bukan sekadar penulis kode
Kalau cuma sendirian merapikan kode, itu hanya menciptakan kebingungan yang lebih besar
Kadang satu jam bicara dengan PM atau pelanggan jauh lebih baik
Demam LLM saat ini terasa seperti solusi yang muncul lebih dulu daripada masalahnya
Kalau benar ingin meningkatkan kecepatan, pertanyaan pertama seharusnya adalah “apa bottleneck-nya?”
Eksekutif yang melihat presentasi AI lalu percaya “kalau pakai ini kita akan lebih cepat” tak lebih dari vibe management
Coding adalah bagian yang paling padat tenaga dan paling bisa diotomatisasi
LLM bisa sangat mengurangi beban di bagian ini. Terutama hal seperti penulisan test code, AI cukup bagus di sana
Developer manusia masih belum bisa melepaskan obsesi terhadap kode
Padahal kode hanyalah representasi menengah (IR) dari sebuah solusi
Seperti GCC yang melakukan optimisasi internal saat mengubah ke assembly, kalau agen menghasilkan kode pun kita seharusnya hanya perlu melihat ketepatan hasilnya
Kalau spesifikasinya jelas dan ada proses review yang berulang, baik manusia maupun agen bisa menghasilkan implementasi yang sama
LLM tidak demikian. Ia bisa salah paham atau mengalami halusinasi (hallucination)
Karena itu manusia tetap harus melakukan review
Agen sering memilih pola yang salah atau menumpuk utang teknis
Mungkin suatu hari nanti bahasa pemrograman itu sendiri akan hilang, tapi itu masih jauh
Makna bisa meluas, menyusut, atau bahkan hilang
Banyak perusahaan sebenarnya tidak sungguh-sungguh menginginkan kode yang bagus
Evaluasi internal dilakukan berdasarkan “seberapa banyak yang sudah dirilis”, dan ketika kita menunjukkan masalah, jawabannya sering “terlalu detail”
Pada akhirnya para stakeholder internal hanya ingin punya alasan untuk mengatakan bahwa mereka ‘berhasil’
Tugas teknisi adalah menjelaskan risiko dari pilihan tersebut
Setelah adopsi AI, penurunan kualitas benar-benar mulai terlihat
Di perusahaan kami, approval PR juga asal-asalan, CI butuh 45 menit, dan deployment bisa tertunda berhari-hari
Selain itu penggunaan AI juga dilarang. Katanya kebanyakan kodenya ditulis manusia, tapi saya ragu
Yang dilewatkan tulisan ini ada dua hal — (A) penggunaan agen dan optimasi proses bisa berjalan bersamaan, (B) ada ticket tertentu yang memang bottleneck-nya benar-benar kode
Pada akhirnya yang penting bukan AI atau tidak, melainkan perbaikan proses untuk menghilangkan bottleneck
Saya seorang solo developer. Kecepatan coding memang benar-benar masalah buat saya, karena itu menyita waktu yang seharusnya bisa dipakai untuk hal lain
Hari ini saya baru menyiapkan Claude Code, dan sekarang waktu saya untuk googling atau menulis test jadi berkurang
Produktivitas mungkin tidak naik 10x, tetapi sebagai teknologi penghemat kerja ini sudah sangat bernilai. Mirip seperti mesin pencuci piring
Sekarang AI bahkan menulis test dan memberi peringatan soal edge case
Memang tidak sempurna, tapi kecepatan merilis fitur baru meningkat dan waktu saya juga bertambah
Kalimat “AI tidak bisa dipercaya” terdengar bagi saya seperti “compiler tidak bisa dipercaya”
Pada akhirnya manusia tetap memberi arah, memperbaiki prompt, dan berkembang bersama alat itu
Dalam lingkungan startup atau VC, yang inti justru menyelesaikan masalah bisnis, bukan coding
Bertambahnya output kode tidak menjamin hasil sistem secara keseluruhan akan lebih baik
Sama seperti template atau code generator, kecepatannya memang naik, tetapi kalau penggalian requirement tidak jadi 10x lebih cepat, maka produktivitas 10x juga mustahil
Jadi analogi itu agak kurang pas
Bagaimana cara memastikan AI tidak melakukan kesalahan yang biasanya tidak dilakukan manusia?
Manusia meninjau kode secara logis langkah demi langkah, tetapi AI tidak demikian
Bahkan kalau engineer senior seperti di Amazon yang mereview, review sendiri bukan proses yang dirancang untuk menangkap semua bug
Lagi pula semakin senior seseorang, makin banyak rapatnya sehingga konteks kodenya justru kurang dikuasai. Seberapa efektif review seperti itu?
Menganggap manusia itu sempurna adalah ilusi
Kita justru menuntut standar yang lebih tinggi dari AI dibanding manusia
Pada akhirnya yang penting adalah memperkuat proses QA. Testing tidak seharusnya dibebankan ke developer saja
Ini mengingatkan saya pada buku lama yang pernah saya baca, The Goal. Ketika satu tahap dalam proses diotomatisasi, tahap berikutnya akan menjadi bottleneck
Dalam software juga sama, meski pembuatan kode jadi lebih cepat, tidak ada artinya kalau keseluruhan proses tidak bisa mengikuti
Pada akhirnya semuanya berada di bawah tujuan menghasilkan laba. Kualitas kode pun hanyalah konsep turunan dari tujuan itu
Kecepatan menulis kode bukan bottleneck dalam situasi berisiko tinggi
Kadang lebih baik bergerak lambat, merencanakan dengan hati-hati, dan mempertimbangkan hasilnya
Misalnya jika sistem raksasa dibangun terlalu cepat, seperti di industri AI, itu bisa menimbulkan risiko peradaban ke arah yang salah
Sebaliknya, kalau hanya game kecil yang dibuat sendirian saat akhir pekan, itu tidak masalah. Pada akhirnya besarnya risiko lah yang menentukan kecepatan