Sejak AI Bottleneck Engineering Hilang. Ternyata Bottleneck-nya Tidak Pernah Pindah.

Awalnya saya percaya AI memindahkan bottleneck di software development. Kalau AI bisa generate code dalam hitungan menit, code bukan lagi bagian yang paling lambat. Bottleneck-nya pasti pindah ke review, testing, deployment, atau release.

Logikanya masuk akal. Sebelum generative AI, kapasitas tim sangat bergantung pada berapa banyak perubahan yang bisa ditulis engineer. Mau mengerjakan lebih banyak, tambah orang. Mau lebih cepat, tambah tooling.

Sekarang satu engineer bisa menghasilkan perubahan dalam volume yang sebelumnya butuh beberapa orang. Kelihatannya seperti bottleneck lama sudah hilang.

Code hanya bagian yang paling mudah dilihatlink

Begitu volume perubahan naik, masalah lain mulai kelihatan. Pull request bisa selesai dalam satu jam. Tapi reviewer tetap harus memahami kenapa perubahan itu dibuat, asumsi apa yang dipakai, dan apa yang terjadi kalau asumsi itu salah.

Test bisa ikut di-generate. Tapi test yang lahir dari interpretasi yang sama hanya membuktikan bahwa code dan test konsisten satu sama lain. Belum tentu keduanya menyelesaikan masalah yang benar.

Deployment bisa dilakukan lebih sering. Tapi ketika sesuatu rusak di production, tim tetap harus menjelaskan perilakunya, mencari keputusan yang melahirkannya, lalu menentukan siapa yang bertanggung jawab memperbaikinya.

Bagian generate memang menjadi lebih cepat. Bagian memahami tidak.

Output bertambah. Pemahaman tidaklink

Di sinilah bottleneck yang sebenarnya mulai terasa. Seorang reviewer membuka perubahan yang secara teknis rapi. Type check lewat. Test hijau. Implementasinya terlihat masuk akal.

Tapi tidak ada yang bisa menjawab dengan cepat:

• Kenapa flow ini yang dipilih?

• Constraint apa yang tidak boleh dilanggar?

• Kasus mana yang sengaja tidak didukung?

• Kalau hasilnya salah, siapa yang memutuskan perilaku berikutnya?

Review akhirnya berubah dari memeriksa perubahan menjadi merekonstruksi pemikiran yang seharusnya ada sebelum perubahan itu dibuat. AI tidak menghilangkan pekerjaan itu. AI hanya membuat kita bisa menumpuk lebih banyak pekerjaan semacam itu dalam waktu yang lebih singkat.

Ini yang saya sebut cognitive debtlink

Technical debt adalah cost dari desain yang kita tunda atau kompromikan. Cognitive debt adalah jarak antara perubahan yang bisa dihasilkan sistem dan perubahan yang benar-benar bisa dijelaskan, dievaluasi, dan dimiliki oleh tim.

Debt ini tidak selalu terlihat seperti code yang buruk. Sering kali code-nya justru bersih. Abstraksinya rapi. Test-nya banyak. Dokumentasinya bahkan ikut dibuat.

Masalahnya baru muncul ketika perilakunya harus diubah. Tidak ada yang yakin bagian mana yang aman disentuh. Tidak ada yang tahu apakah sebuah abstraction dibuat karena kebutuhan nyata atau karena agent menganggapnya sebagai best practice. Tidak ada yang bisa membedakan keputusan bisnis dari keputusan implementasi.

Codebase terus bertambah. Pemahaman tim tidak ikut bertambah.

AI tetap membuat engineering lebih cepatlink

Untuk pekerjaan yang sudah jelas, AI memberi leverage yang nyata. Generate adapter dari kontrak yang sudah diputuskan. Menulis migration dari skema yang sudah disepakati. Mengubah pola yang sama di banyak file. Mencari edge case dari behavior yang sudah punya batasan.

Di situ AI mempercepat eksekusi tanpa menambah banyak ketidakpastian. Masalahnya muncul ketika kita memakai kecepatan eksekusi untuk menutupi keputusan yang belum selesai.

• Lifecycle belum jelas, minta AI buat workflow yang fleksibel.

• Ownership belum jelas, minta AI buat abstraction supaya semua tim bisa pakai.

• Launch criteria belum jelas, minta AI tambah test sebanyak mungkin.

Kita terlihat bergerak. Padahal ketidakpastiannya hanya dipindahkan ke dalam code.

Bottleneck engineering tidak pernah benar-benar pindahlink

Bottleneck-nya tetap sama: kemampuan tim untuk membuat keputusan yang cukup jelas sebelum perubahan menjadi mahal.

Sebelum AI, keputusan yang buruk tertahan oleh lambatnya implementasi. Ada waktu untuk mendebat, mengoreksi, atau membatalkan. Sekarang keputusan yang sama bisa berubah menjadi ribuan baris code sebelum tim sadar pertanyaannya belum pernah dijawab.

AI bukan menciptakan masalah baru. AI menghilangkan jeda yang dulu memberi kita kesempatan untuk melihat masalah lama.

Workflow-nya tidak perlu lebih panjang. Tapi urutannya harus benarlink

Sebelum meminta AI membangun sesuatu, saya ingin empat hal ini punya jawaban:

1. Intent: perubahan apa yang harus terjadi untuk user atau bisnis?

2. Boundary: apa yang sengaja tidak diselesaikan sekarang?

3. Proof: bukti paling kecil apa yang menunjukkan perubahan ini bekerja?

4. Ownership: siapa yang memahami trade-off-nya dan akan mengambil keputusan kalau hasilnya salah?

Setelah itu, biarkan AI mempercepat implementasinya.

Kalau empat hal tadi belum jelas, prompt yang lebih panjang tidak akan menyelamatkan hasilnya. Agent hanya akan mengisi ruang kosong dengan asumsi yang terdengar masuk akal.

Dan asumsi yang terdengar masuk akal adalah bentuk overbuild yang paling sulit dideteksi. Code-nya terlihat benar. Sistemnya terlihat matang. Baru beberapa bulan kemudian tim sadar mereka membangun fleksibilitas untuk keputusan yang tidak pernah dibuat.

AI mempercepat kesalahan lamalink

Kesalahan itu bukan di code. Tapi di keputusan yang tidak pernah dibuat.

Jadi pertanyaan pentingnya bukan lagi, seberapa banyak code yang bisa kita hasilkan minggu ini? Pertanyaannya, seberapa banyak perubahan yang masih bisa dipahami, dibuktikan, dan dimiliki oleh tim setelah minggu ini selesai?

Kalau jawabannya tidak ikut naik, bottleneck kamu tidak hilang. Kamu hanya sedang membangun cognitive debt lebih cepat.