Tim engineering yang mengevaluasi agen pengkodean biasanya memulai dengan pertanyaan yang salah. Mereka ingin tahu seberapa otonom agen tersebut dapat bekerja. Seberapa banyak bagian dari pipeline yang dapat ia kuasai? Bisakah ia menulis spesifikasi, mengedit repositori, dan melakukan push ke produksi tanpa mengganggu siapa pun? Demo-demo yang ada membuat obsesi ini terasa mudah. Anda melihat alur kerja yang mulus di mana satu prompt memicu serangkaian pengeditan dan deployment, dan insting Anda adalah mengejar kemampuan yang sama di dalam organisasi Anda sendiri. Namun, kemegahan adalah prinsip desain yang buruk. Pertanyaan yang lebih baik jauh lebih tidak menarik: siapa yang memberi otoritas pada hal ini, sistem apa yang sebenarnya dapat ia sentuh, dan apa yang terjadi ketika ia tak terelakkan melakukan kesalahan?

Jebakan Otonomi

Otonomi yang mengasyikkan adalah sebuah jebakan. Hal ini melatih kita untuk merayakan bot yang menghasilkan spesifikasi, memodifikasi repositori, dan melakukan deployment kode sambil dengan tenang mengklaim bahwa tugas telah selesai. Itu bukan engineering. Itu adalah "trust fall" dengan akses shell. Pekerjaan itu sendiri menjadi hampir terlalu mudah untuk dihasilkan. Model apa pun dapat menghasilkan kode, dokumentasi, atau rencana arsitektur dalam hitungan detik. Namun, biaya sebenarnya dalam pengembangan perangkat lunak bukanlah kecepatan mengetik. Biaya sebenarnya selalu terletak pada validasi, peninjauan, dan keputusan hati-hati untuk mengatakan ya, ini benar dan aman untuk dirilis. Pekerjaan yang dihasilkan itu murah. Persetujuan itu mahal. Perusahaan yang menemukan cara menangani persetujuan secara bersih dan konsisten akan menjadi pihak yang benar-benar merilis sistem yang andal.

Mengapa Peninjauan Mandiri Gagal

Risiko muncul dalam pola yang dapat diprediksi. Sebuah model menyusun draf rencana dan kemudian mengevaluasi apakah rencana tersebut bagus. Sebuah agen mengedit codebase Anda dan menjelaskan kepada Anda mengapa perubahannya aman. Sebuah alat mengeksekusi perintah dan meminta maaf alih-alih meminta izin. Masing-masing dari hal ini mewakili kegagalan inti yang sama. Jika sebuah agen menghasilkan spesifikasi, sesuatu di luar agen tersebut harus menyetujuinya sebelum hal itu dianggap sebagai kebenaran. Jika sebuah agen memodifikasi kode, proses terpisah harus memeriksa diff. Membiarkan generator bertindak sebagai validatornya sendiri bukanlah jalan pintas. Itu adalah bug struktural yang dibungkus sebagai kenyamanan.

Prompt Bukanlah Sistem Perizinan

Anda tidak dapat mengamankan agen dengan kata-kata yang cerdik. Memberitahu model untuk berhati-hati atau meminta izin sebelum menghapus sesuatu tidak menciptakan batasan. Prompt bukanlah sistem perizinan. Sebelum Anda membiarkan agen mendekati produksi, Anda memerlukan inventarisasi kemampuan yang jujur. Bisakah ia membaca seluruh repositori? Bisakah ia mengeksekusi perintah shell? Bisakah ia membuka browser? Bisakah ia menarik data pelanggan ke dalam context window-nya? Sebagian besar tim tidak mengetahui jawaban lengkapnya. Mereka berasumsi alat tersebut terbatas pada sandbox padahal sebenarnya ia memiliki akses tulis ke jalur-jalur kritis. Petakan area permukaannya terlebih dahulu. Baru kemudian bangun dindingnya.

Bangun Sistem Kontrol Bertingkat

Setelah Anda memahami apa yang dapat dilakukan agen tersebut, rancanglah sistem kontrol yang menyesuaikan risiko dengan hambatan (friction). Tindakan berisiko rendah, seperti memperbarui dokumentasi internal atau memformat kode agar konsisten, dapat berjalan secara otomatis. Tindakan berisiko sedang, seperti melakukan refactoring pada sebuah modul atau menambahkan dependensi baru, harus melewati checkpoint di mana manusia atau test suite yang terverifikasi mengonfirmasi langkah tersebut. Tindakan berisiko tinggi, seperti deployment ke produksi, memodifikasi infrastruktur, atau mengakses data sensitif, memerlukan penyetuju terpisah yang tidak terlibat dalam proses pembuatan. Setiap tindakan harus meninggalkan audit trail. Anda harus dapat memutar ulang secara tepat file mana yang dibaca, alat mana yang dipanggil, dan keputusan mana yang dibuat. Agentic development bukanlah lisensi untuk melewatkan peninjauan. Hambatan yang membosankan adalah sebuah fitur. Gerbang persetujuan yang tepat bertindak seperti circuit breaker ketika segala sesuatunya mulai menyimpang.

Sesuaikan Batasan dengan Risiko

Kalibrasi batasan Anda dengan bahaya yang sebenarnya. Mengubah setiap perubahan kecil format Markdown menjadi upacara kepatuhan akan menghentikan laju tim Anda. Namun, menganggap tindakan berisiko tinggi sebagai hal yang tidak berbahaya karena agen tersebut tampak percaya diri adalah hal yang sama konyolnya. Tujuannya adalah kontrol yang proporsional, bukan pembatasan yang teatrikal.

Jaga Artefak Tetap Kecil dan Dapat Diamati

Sistem agen yang paling berguna tidak mencoba memukau Anda dengan eksekusi otonom yang masif. Mereka menghasilkan artefak kecil yang dapat ditinjau. Rencana yang matang. Diff yang terfokus. Log yang mudah dibaca. Eksekusi otonom yang raksasa adalah mimpi buruk untuk di-debug. Ketika sesuatu rusak setelah sesi agen dengan lima puluh file, Anda harus mengurai niat, eksekusi, dan efek samping sekaligus. Jaga agar radius dampaknya tetap kecil. Pastikan Anda tahu file mana yang dibaca agen dan alat mana yang dipanggilnya. Sistem yang dapat diobservasi adalah sistem yang dapat dipelihara. Otonomi black-box hanyalah utang teknis dengan pemasaran yang lebih baik.

Enam Pertanyaan Sebelum Anda Memberikan Akses

Sebelum Anda memberikan tanggung jawab nyata kepada agen, uji ketahanan pengaturan Anda dengan enam pertanyaan sulit.

  • Kemampuan apa yang sebenarnya dimiliki sistem tersebut?
  • Tindakan mana yang ditolak secara default, diblokir di tingkat infrastruktur alih-alih hanya dilarang melalui kalimat sopan dalam system prompt?
  • Tindakan mana yang memerlukan persetujuan eksplisit?
  • Artefak mana yang dibekukan sebelum dikonsumsi oleh agen, sehingga ia tidak dapat memanipulasi inputnya sendiri secara diam-diam?
  • Validator mana, yang sepenuhnya terpisah dari generator, yang menilai hasil akhirnya?
  • Log mana yang membuktikan, tanpa ambiguitas, apa yang sebenarnya terjadi?

Ini adalah higiene teknik dasar. Pisahkan generator dari validator. Pertahankan otoritas manusia di batas sistem.

Ujian yang Sebenarnya

Ada