Hambatannya Ada di Spesifikasi, Bukan di Model

Tahun pertama transformasi AI kami bergerak dari nol ke 33 solusi yang deploy. Periode berikutnya hanya menambah sepuluh.

Tebakan gampangnya: anggaran habis, orang kurang, ide mentok. Data saya bilang bukan itu. Kapasitas memproduksi kode tidak pernah jadi batasnya. Yang melambat justru pekerjaan di kiri dan kanan produksi itu. Menentukan persis apa yang harus dibuat, lalu membuktikan hasilnya benar. Dua-duanya bergerak di kecepatan manusia.

Kalau adopsi agent di tim kamu ikut mendatar setelah pilot, itu hal pertama yang perlu dicek. Kurang kapasitas, atau kurang spesifikasi? Jawabannya mengubah apa yang kamu danai berikutnya.

Cerita yang beredar sekarang kira-kira begini. Coding agent membuat spesifikasi jadi beban yang tidak perlu, tinggal prompt, lihat hasilnya, ulangi. Saya sudah membangun empat aplikasi produksi dengan pendekatan spec-first, plus dua produk indie di dua toolchain spesifikasi yang sengaja berbeda. Cerita itu runtuh begitu ada yang harus dirawat.

Poin penting

• Batasannya pindah dari menulis kode ke dua pekerjaan yang lebih lambat: menentukan persis apa yang harus dibuat, lalu membuktikan hasilnya benar. Throughput naik saat kamu mengisi dua posisi itu, bukan saat kamu mengganti model.
• Simpan spesifikasi di repository dan tinjau seperti kode. Itu garis pemisah antara tim yang mengirim software buatan agent dan tim yang cuma menumpuk kode tanpa pemilik.
• Jalankan tes regenerasi di satu modul sebelum memperbesar tooling. Satu sore cukup untuk tahu kamu punya spesifikasi atau sekadar dokumentasi.
• Anggarkan beban review, bukan token. Approval fatigue datang duluan, dan yang kena orang paling senior di tim kamu.

Hambatannya Terbelah Jadi Dua

Dua paper Google 2026 menunjuk arah berlawanan. Boonstra dalam Spec-Driven Production Grade Development menulis bahwa AI menghapus hambatan produksi kode. Batasannya pindah ke hilir, ke manusia yang meninjau, menguji, dan mengintegrasikan hasilnya. Osmani, Saboo, dan Kartakis di The New SDLC With Vibe Coding menunjuk ke hulu. Yang ditunggu sekarang bukan tangan manusia yang mengetik boilerplate. Yang ditunggu pikiran manusia yang menetapkan batasannya.

Menurut saya keduanya benar, dan justru itu temuan yang tidak dinyatakan satu paper pun. Hambatannya terbelah dua. Spesifikasi pindah ke depan, verifikasi pindah ke belakang, bagian tengahnya rontok. Kebanyakan organisasi tidak mengisi keduanya. Lalu heran kenapa kenaikan produktivitas 25 sampai 39 persen yang dilaporkan survei industri tidak muncul di angka pengiriman. Studi METR yang dikutip paper yang sama justru menemukan hal sebaliknya. Developer berpengalaman 19 persen lebih lambat pada tugas tertentu, terutama karena waktu memverifikasi dan memperbaiki keluaran AI.

Ini bukan persoalan akademis. Per awal 2026, 85 persen developer profesional rutin memakai coding agent dan 51 persen memakainya setiap hari. Sekitar 41 persen kode baru dihasilkan AI. Volumenya sudah ada di repository kamu. Yang belum jelas, apa yang berdiri di hulunya.

Tes Regenerasi

Ini pemeriksaan yang saya jalankan sebelum menyerahkan satu modul ke agent. Hapus modulnya. Berikan satu agent baru hanya spesifikasinya. Lihat apakah hasilnya lolos test yang sama dan mendarat di arsitektur yang sama.

Saya menyebutnya tes regenerasi. Tiga bagiannya: spesifikasi sebagai satu-satunya masukan, agent bersih tanpa memori sesi, dan test suite yang sudah ada sebagai jurinya. Kalau hasil regenerasinya gagal, selisih antara dua artefak itu persis bagian yang hilang dari spesifikasi kamu. Tulis selisihnya. Jangan tulis ulang kodenya.

Tesnya lahir dari klaim Boonstra bahwa kode sekarang bersifat sekali pakai. Dengan spesifikasi yang cukup kokoh, seluruh basis kode bisa diregenerasi berulang kali. Bahkan dipindah dari satu bahasa ke bahasa lain dalam satu sore. Klaim itu biasanya dibaca sebagai janji. Saya membacanya sebagai syarat yang bisa diuji. Kalau tidak bisa diregenerasi, yang kamu punya bukan spesifikasi. Yang kamu punya dokumentasi, deskripsi kode yang sudah terlanjur ada, dan itu akan melenceng.

Aturan keputusan yang layak kamu tempel di dokumen review: jalankan tes regenerasi di modul dengan churn tertinggi lebih dulu; kalau menutup selisihnya butuh lebih dari satu hari kerja menulis, modul itu belum siap dikerjakan agent, dan langkah jujurnya menahan modul itu di mode kendali langsung. Lewati pemeriksaan ini, dan yang kamu kirim adalah basis kode yang hanya bisa diregenerasi di demo.

Dua produk indie itu memberi saya perbandingan paling bersih, karena saya sengaja menjalankannya dengan metode berbeda. Yang satu memuat 18 lebih spesifikasi formal. Masing-masing ditulis sebagai triad requirements, design, dan tasks, dengan dokumen steering yang menjaga konsistensinya. Yang lain berjalan di atas plan review dan catatan keputusan bernomor. Bentuknya beda, sifatnya sama. Di keduanya satu modul bisa diregenerasi dari artefak tertulisnya, dan jaring pengaman produk pertama adalah rangkaian sekitar 260 test.

Apa yang Harus Ada Sebelum Agent Menyentuh Modulnya

Isinya lebih baku daripada kelihatannya. Daftar Boonstra: desain teknis lengkap, skema basis data, kontrak API, versi pustaka yang dikunci, alasan di balik keputusannya, dan skenario yang mencakup kasus tepi. Spesifikasi berbasis perilaku dengan struktur Given / When / Then memikul beban terberat. Formatnya memaksa model berpikir dalam urutan state, action, outcome, dan menutup ruang menebak maksud.

Format ternyata berpengaruh nyata. Studi SkCC oleh Ouyang dan kolega dilaporkan di paper yang sama. Agent LLM ternyata begitu sensitif pada format instruksi. Markdown generik yang tidak dioptimalkan menurunkan performa sampai 40 persen. Untuk konfigurasi bersarang lebih dari tiga tingkat, YAML mencapai akurasi parsing 51,9 persen. Bandingkan dengan 43,1 persen untuk JSON dan 33,8 persen untuk XML. Narasi di Markdown, struktur di YAML. Perubahan lima menit yang mengembalikan akurasi yang selama ini kamu bayar di siklus review.

Bagian organisasinya lebih menentukan daripada sintaksnya. Spesifikasi tinggal di folder specs yang masuk version control, diindeks agent, dibaca manusia. Paper The New SDLC tegas kepada engineering leader. Berkas aturan, system prompt, eval suite, dan pustaka skill harus ditinjau lewat pull request. Semuanya diberi versi bersama proyeknya, dan dimiliki engineer yang jelas namanya.

Lapisan itu punya nama di paper yang sama. Harness adalah semua yang membungkus model. Isinya instruksi, tools, sandbox, guardrail, sampai observability. Penulisnya terus terang soal kepemilikan. Permukaan seluas itu tanggung jawab tim kamu, bukan penyedia model. Tanpa pemilik yang jelas, harness melenceng dan perilaku agent berhenti bisa direproduksi lintas tim. Pergeseran disiplin yang sama sudah saya tulis di skala AI dari eksperimen menjadi infrastruktur, hanya satu lapis lebih bawah. Itu juga alasan spesifikasi berubah saat software jadi probabilistik.

Tagihannya Datang sebagai Beban Review

Lewati pekerjaan hulu, dan artefaknya justru bertambah. Lebih banyak, lebih cepat, tanpa saringan. Boonstra menyebut tiga kategori kegagalannya dengan tepat: konflik merge karena beberapa developer mendarat di berkas yang sama dalam satu jam, kemacetan review saat satu pull request besar berubah jadi sarang sub-request yang saling bergantung, dan fragmentasi konteks, saat agent mengutip potret berkas yang sudah usang lalu menghasilkan kode yang memanggil fungsi yang sudah tidak ada.

Lalu ongkos manusianya. Riset Quantum Workplace yang dilaporkan CNBC menemukan pola yang tidak enak. Pengguna AI intensif 45 persen lebih mungkin mengalami burnout tinggi dibanding yang bukan pengguna. Mekanismenya, kata Boonstra, adalah approval fatigue. Arus persetujuan mikro datang terus sampai developer menekan approve secara refleks. Tim lalu diam-diam berhenti memeriksa kerja mesin demi mengejar ritmenya. Timnya sendiri menemukan batas itu lewat satu insiden. Sebuah agent dalam mode auto-approve menekan tombol baru, tersambung ke layanan usang tanpa pengaman, lalu mengirim lima puluh rekan kerja surel berisi konten halusinasi.

Kalau agent berbuat salah, periksa harness sebelum menyalahkan model. Di benchmark Terminal Bench 2.0, satu tim menaikkan coding agent dari luar 30 besar ke 5 besar. Yang mereka ubah hanya harness, tanpa mengganti model. Studi terpisah di LangChain menaikkan skor 13,7 poin. Yang disesuaikan hanya system prompt, tools, dan middleware di sekitar model yang sama. Sebagian besar kegagalan agent, kalau diperiksa jujur, adalah kegagalan konfigurasi.

Mulai dari Satu Modul, Bukan dari Mandat

Godaan di level pimpinan adalah mengumumkan spec-driven development sebagai kebijakan. Yang lahir dari situ dokumen kepatuhan yang tidak pernah diregenerasi siapa pun.

Versi yang lebih sempit adalah yang bisa dibuktikan repository saya sendiri. Ambil modul dengan churn tertinggi dan cakupan test paling jelas. Tulis spesifikasinya sampai lolos tes regenerasi. Masukkan ke version control dengan pemilik yang jelas namanya. Lalu ukur perubahan jam review, bukan baris kode yang dihasilkan, karena di jam review itulah batasannya sekarang tinggal.

Buku Osmani menyebut batas atasnya dengan jujur. AI menangani sekitar 70 persen sebuah fitur. Sisa 30 persennya, berupa kasus tepi, arsitektur, dan kemudahan perawatan, tetap butuh keahlian manusia yang serius. Paper setahun setelahnya menyebutnya masalah 80 persen. Pergeseran antara dua angka itu intinya. Porsi yang ditangani mesin terus naik, dan residunya makin sulit dan makin senior. Keunggulan kamu ada di seberapa presisi kamu menjelaskan pekerjaannya sebelum dimulai, dan seberapa cepat kamu tahu pekerjaan itu benar-benar selesai. Itulah kerja agentic engineering yang menggantikan pola terima tiket.

Jadi pilih satu modul minggu ini. Jalankan tes regenerasi di modul itu, catat jam review sebelum dan sesudahnya, lalu bawa angkanya ke siklus perencanaan berikutnya. Angka itu menutup perdebatan tooling lebih cepat daripada satu demo vendor lagi.

Referensi

• Boonstra, L. (2026). Spec-Driven Production Grade Development in the Age of Vibe Coding: The Blueprint for Scalable Workflows and Team Evolution. Google, May 2026.
• Osmani, A., Saboo, S., & Kartakis, S. (2026). The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering. Google, May 2026.
• Osmani, A. (2025). Beyond Vibe Coding: From Coder to AI-Era Developer. O’Reilly Media. ISBN 979-8-341-63475-6.