Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.
Kenapa brief harian yang terbuka menghasilkan nol commit, dan prosedur bernomor — commit pertama di giliran keenam, mendarat di giliran ketiga puluh — yang berhasil.
Matthews Wong
Software Engineer
Ringkasan Utama
Agen tanpa pengawasan yang diberi tugas terbuka akan menjelajah sampai kehabisan giliran dan tidak menghasilkan commit apa pun. Mengganti brief-nya dengan prosedur bernomor — satu item kecil, commit pertama dalam enam giliran, push lebih awal, berhenti commit di giliran ketiga puluh, tidak pernah berakhir dengan nol commit — mengubah run yang mengambang menjadi pull request yang ter-merge.
Agen coding harian saya melakukan hal ini dua malam berturut-turut: membuat branch, membaca berkas selama tiga puluh lima giliran, lalu berhenti. Tanpa commit, tanpa pull request, tanpa error. Modelnya bekerja persis seperti yang diinstruksikan, dan instruksinyalah masalahnya.
Berikut ini adalah perbedaan antara brief yang terdengar masuk akal bagi manusia dan prosedur yang benar-benar bisa dieksekusi model yang lebih lemah tanpa pengawasan. Ini satu hal dengan daya ungkit tertinggi yang saya ubah di sepanjang proyek.
Ambil item teratas dari backlog dan kerjakan adalah instruksi yang sangat baik untuk manusia. Untuk agen tanpa pengawasan dengan anggaran terbatas, ia punya tiga sifat fatal.
Versi termahal yang saya lihat adalah run yang menghabiskan delapan puluh giliran dan beberapa juta token menggilas satu tugas yang memang sulit — tes integrasi basis data — dan menghasilkan satu commit yang bahkan tidak ter-push. Tidak ada yang crash. Ia sekadar memilih tugas yang tak bisa ia selesaikan lalu mengerjakannya sampai anggarannya habis.
Penulisan ulangnya mengubah sebuah tujuan menjadi urutan bernomor dengan anggaran eksplisit dan sebuah pintu darurat. Setiap klausanya ada karena ketiadaannya pernah menyebabkan kegagalan tertentu.
# The prompt that produced zero commits, twice:
"Pick the top item from BACKLOG.md and implement it."
# The prompt that produced a merged pull request:
"1. Check main is green before starting.
2. Create a branch named chore/refine-<date>.
3. Choose ONE small, self-contained improvement: a single test, one
type tightened, one doc fix. NO new dependencies. NO refactors.
4. Land your FIRST commit within 6 turns. Stop reading and start editing.
5. Push after the first commit and every ~3 commits after that.
6. By turn 30 STOP committing and open the pull request.
ESCAPE HATCH: a run that ends with zero commits is a failure. If you
are stuck, commit whatever compiles, push, and open the PR anyway."Dua klausa mengerjakan sebagian besar pekerjaannya. Daratkan commit pertama dalam enam giliran mematikan spiral eksplorasi, karena ia mengubah membaca dari aktivitas bawaan menjadi sesuatu yang harus dianggarkan agen. Dan pintu daruratnya — run yang berakhir dengan nol commit adalah kegagalan — menghapus opsi yang terus dipilih model setiap kali ia merasa ragu.
Tulis anggarannya dalam giliran, bukan dalam kata seperti cepat atau singkat. Giliran adalah sesuatu yang bisa dihitung agen; cepat adalah sesuatu yang bisa ia rasionalisasi. Setiap instruksi lunak di prompt saya pada akhirnya diganti dengan sebuah angka.
Isi prompt baru separuh pertanyaannya. Separuh lainnya adalah permukaan mana yang membawanya, dan dalam praktik otoritas mereka tidak setara.
| Permukaan | Bagus untuk apa | Apa yang saya pelajari dengan susah payah |
|---|---|---|
| Prompt run sekali pakai | Tugas spesifik hari ini beserta batasannya | Ia tidak andal menimpa berkas instruksi persisten; agen akan mengikuti berkas itu dan penilaiannya sendiri |
| Berkas instruksi persisten | Standar, disiplin, definisi selesai | Inilah permukaan kendali yang sesungguhnya. Kebiasaan mutu tinggal di sini, bukan di prompt harian |
| Berkas backlog yang dikurasi | Memilih apa yang dikerjakan berikutnya | Mengurasi item teratas adalah cara Anda mengemudi, karena berkas instruksinya menunjuk ke sana |
| Skill atau runbook | Prosedur berulangnya itu sendiri | Menjaga urutan yang sama di setiap run tanpa mengulanginya di tiap prompt |
Saya menemukan ini dengan mem-brief sebuah fitur spesifik dan mendapat sesuatu yang sama sekali lain: agen melihat pipeline-nya merah dan memperbaiki itu. Itu keputusan yang tepat, dan terjadi karena berkas persistennya menyuruh memeriksa pipeline lebih dulu. Pelajarannya, mengemudi terjadi lewat permukaan yang tahan lama, bukan lewat pesan hari ini.
Kontradiksi antar permukaan lebih buruk daripada salah satu instruksinya sendirian. Prompt harian yang berbunyi kerjakan satu hal kecil lalu berhenti, berhadapan dengan berkas instruksi yang berbunyi kerjakan backlog-nya, menghasilkan keluaran terendah dari semua konfigurasi yang pernah saya jalankan — agennya mengambil jalan tengah dan nyaris tidak melakukan apa pun.
Kegagalan yang menggantikan keadaan mengambang lebih halus dan lebih menjengkelkan: satu run menghasilkan sebelas commit bagus, memakai seluruh giliran yang tersedia untuk itu, dan tidak pernah membuka pull request-nya. Pekerjaannya ada dan tak terjangkau.
Dua aturan memperbaikinya. Push setelah commit pertama dan setiap beberapa commit sesudahnya, agar pekerjaannya sampai ke remote meski run-nya mati di tengah jalan. Dan tetapkan tenggat pendaratan eksplisit beberapa giliran sebelum batas keras, saat mana agen berhenti menambah commit terlepas dari berapa banyak sisa daftarnya. Merge yang dijamin atas enam commit mengalahkan sebelas commit yang telantar, dan pertukaran itu layak dinyatakan di prompt dengan kata-kata persis seperti itu.
Struktur prompt hanya membantu kalau ukuran tugasnya tepat. Empat kategori berikut andal muat dalam satu run tanpa pengawasan.
Yang tidak muat: fitur baru, apa pun yang butuh dependensi baru, dan apa pun yang menyentuh lebih dari segelintir berkas. Itu semua untuk sesi terawasi tempat manusia bisa mengoreksi arah saat itu juga.
Sebelum membiarkan sebuah jadwal berjalan tanpa pengawasan, verifikasi hal-hal ini — saya pernah terbakar oleh masing-masing.
Poin pertama layak diulang: pemantauan yang Anda tulis sendiri, terburu-buru, untuk mengawasi sebuah agen adalah persis kode yang paling tidak mungkin diuji, dan laporan sukses palsu lebih merusak daripada tidak ada laporan sama sekali.
Jarak antara agen yang mengambang dan agen yang merilis bukan mutu model, melainkan prosedur. Beri ia satu item kecil, nomor giliran saat commit pertama harus sudah ada, kebiasaan push, tenggat pendaratan, dan aturan eksplisit bahwa nol commit adalah kegagalan — maka model yang sederhana pun menjadi kontributor harian yang andal.
