Sebagian besar tim yang mengadopsi pengodean agentik hanya memindahkan hambatan dari pembuatan ke peninjauan. Tanpa memperbaiki siklusnya, peningkatan kecepatan bersih nyaris nol.
Di lingkungan CI berskala besar—dengan jutaan pengujian setiap malam dan ratusan engineer—tugas agen yang paling bernilai adalah mengarahkan masalah kepada pemiliknya dan melakukan triase, bukan menghasilkan kode.
Output agen yang berguna tetap dapat diandalkan setelah ditelaah dan menjelaskan hubungan sebab-akibat, bukan sekadar mencocokkan pola.
Merancang lapisan pengumpulan bukti dan penyusunan konteks lebih penting daripada lapisan pembuatan.
Sebagian besar pembahasan tentang pengodean agentik masih berawal dari janji sederhana: menulis lebih banyak kode dengan lebih cepat.
Terkadang, janji itu berkembang menjadi visi yang lebih ambisius: agen merencanakan pekerjaan, membuka PR, dan merilis perubahan dengan campur tangan manusia seminimal mungkin. Namun, bagi sebagian besar tim engineering, manfaat jangka pendek yang paling nyata memiliki cakupan lebih sempit. Fokusnya adalah mengurangi biaya iterasi.
Penyediaan software bukan sekadar menghasilkan kode. Menulis kode hanyalah satu tahap dalam siklus yang lebih panjang, yang mencakup peninjauan, pengujian, deployment, dan investigasi ketika terjadi masalah. Sebagian besar tim yang mengadopsi pengodean agentik tanpa merancang ulang siklus peninjauan hanya memindahkan hambatan ke tahap berikutnya.
Mempercepat pembuatan saja tidak otomatis membuat tim bekerja lebih cepat. Hal itu justru dapat mengalihkan lebih banyak upaya ke peninjauan, verifikasi, dan upaya membangun kepercayaan.
Di banyak lingkungan engineering, bagian yang mahal bukanlah menghasilkan draf pertama, melainkan mencapai tingkat keyakinan yang memadai.
Apakah perubahan tersebut benar-benar memperbaiki masalah atau meningkatkan sistem? Apakah perubahan itu menimbulkan regresi di tempat lain? Apakah kegagalan terjadi pada kode, lingkungan, pengujian, atau dependensi? Apakah perbaikan yang diusulkan mengatasi penyebabnya atau hanya gejala yang terlihat?
Agen dapat membantu di sini, bukan karena menggantikan engineer, melainkan karena dapat melakukan pemeriksaan awal secara terstruktur terhadap bukti yang tidak rapi: memeriksa log, membandingkan perubahan terbaru, merangkum sinyal yang relevan, menelusuri kemungkinan penyebab, menjalankan pemeriksaan, dan memberikan hasil yang dapat dikaji lebih lanjut oleh manusia.
Di banyak tim, penggunaan agen yang memberikan dampak terbesar bukanlah menghasilkan kode dari nol. Manfaat utamanya adalah mempersempit ruang pencarian masalah sebelum manusia menghabiskan waktu berjam-jam untuk melakukannya secara manual.
Hal ini sangat jelas terlihat dalam alur kerja debugging berskala besar. Bayangkan CI yang setiap malam menjalankan jutaan pengujian pada berbagai basis kode yang dikerjakan oleh ratusan engineer—kenyataan yang dialami salah satu klien kami. Ketika terjadi kegagalan, mengarahkannya kepada pemilik yang tepat tidaklah mudah. Masalahnya mungkin terletak pada kode aplikasi, dependensi, harness pengujian, atau bagian lain dari stack. Ukuran log dapat mencapai beberapa gigabita, dan tim yang pertama kali menemukan masalah belum tentu merupakan tim yang bertanggung jawab atasnya.
Alur kerja semacam itu tidak serta-merta membutuhkan satu agen untuk menulis perbaikannya. Alur tersebut lebih cocok untuk sistem yang dapat mempersempit ruang masalah dengan cepat.
Pipeline yang berguna dapat mengambil log, memilih bukti yang relevan, merangkum hal-hal penting, memeriksa kode di sandbox, lalu menghasilkan analisis akar masalah yang terstruktur, lengkap dengan skor keyakinan, ketertelusuran, dan saran langkah berikutnya. Untuk menghasilkan skor keyakinan, pakar bidang terkait menilai output awal agen. Penilaian ini kemudian dimasukkan ke LLM sebagai penilai untuk mengotomatiskan pemberian skor berikutnya, sekaligus mempertahankan keselarasan dengan penilaian manusia.
Tujuannya bukan menghilangkan pertimbangan engineer, melainkan memberi peninjau titik awal yang lebih kuat. Triase regresi, peninjauan PR, perbaikan pengujian, validasi rilis, dan investigasi pascadeployment memiliki pola yang sama. Semuanya sarat bukti dan peninjauan, serta penuh ambiguitas. Semua itu tidak mengharuskan agen menggantikan proses engineering, tetapi cukup membantu proses tersebut terus berjalan.
Inilah alasan lain mengapa tim harus berhati-hati dalam menilai sistem-sistem ini.
Pertanyaan yang keliru adalah apakah agen dapat menghasilkan sesuatu yang mengesankan secara mandiri. Pertanyaan yang lebih tepat adalah apakah agen dapat memperbaiki alur kerja nyata tanpa menimbulkan hambatan di bagian lain.
Artinya, kita perlu menilai apakah output cukup spesifik untuk diverifikasi, apakah output menjelaskan sebab-akibat alih-alih sekadar mencocokkan pola, dan apakah output mempermudah peninjauan, bukan malah mempersulitnya. Jawaban yang masuk akal belum tentu berguna. Dalam praktiknya, tim memercayai output agen jika hasilnya tetap dapat diandalkan setelah ditelaah dan memberikan sesuatu yang konkret untuk diperiksa.
Pelajaran yang lebih mendalam adalah bahwa sistem agentik yang berguna membutuhkan lebih dari sekadar pembuatan output. Kegunaannya bergantung pada cara bukti dikumpulkan, konteks disusun, output diperiksa, dan ketidakpastian disampaikan kepada peninjau.
Itulah sebabnya masa depan jangka pendek engineering agentik kemungkinan besar bukan satu lompatan besar menuju otonomi penuh. Masa depan tersebut lebih mungkin berupa serangkaian siklus yang dirancang secara cermat, tempat agen membantu tim memeriksa, meninjau, memverifikasi, dan menyempurnakan pekerjaan dengan mengurangi upaya yang terbuang di antara setiap tahap.
Hal itu mungkin tidak sedramatis gagasan besar tentang otonomi, tetapi jauh lebih mendekati cara sistem yang berguna benar-benar diadopsi.