Cara membuat agen AI andal: rencana bertahap dari pengukuran sampai kerja otonom

Mengapa agen tidak andal meski modelnya kuat

Keandalan agen adalah sifat dari seluruh sistem, bukan hanya model. Tugas panjang terdiri dari puluhan langkah, dan kesalahan menumpuk: dengan 95% langkah yang benar, rantai sepuluh langkah tanpa satu kesalahan pun hanya tercapai sekitar 60% percobaan (0.95^10 ≈ 0.60), dan untuk lima puluh langkah kurang dari 10%. Akurasi model tidak bisa Anda atur, tetapi Anda bisa menangkap kesalahan pada langkah yang sama dan membuatnya murah. Di situlah harness bekerja: instruksi, alat, lingkungan, status, dan umpan balik di sekitar model.

Berikut rencana yang membawa Anda dari «perasaan» menuju keandalan yang terukur, lalu menuju kerja otonom. Langkahnya disusun menurut dampaknya: setiap langkah berikutnya bertumpu pada yang sebelumnya.

Langkah 1. Berhenti menilai «berdasarkan perasaan»

Seorang insinyur yakin prompt baru itu mengubah segalanya, yang lain tidak melihat bedanya, dan tidak ada yang menghitung metriknya. Mulailah dengan log kegagalan: setiap kali agen macet, merusak sesuatu, atau melaporkan fitur yang tidak berfungsi, catat satu baris.

| tanggal | tugas              | yang terjadi                      | subsistem      |
|---------|--------------------|-----------------------------------|----------------|
| 10/10   | diskon di keranjang| «selesai», e2e tidak dijalankan   | umpan balik    |
| 10/10   | webhook pembayaran | tidak bisa menyalakan basis data  | lingkungan     |
| 11/10   | refaktor API       | mengulang solusi yang ditolak     | status         |

Kolom «subsistem» adalah yang terpenting. Setelah satu minggu akan terlihat di mana letak hambatannya, dan Anda memperbaiki titik itu, bukan semuanya sekaligus. Menghitung keandalan dari proporsi percobaan yang sukses adalah kekeliruan: justru log hambatanlah yang menunjukkan di mana agen jatuh.

Langkah 2. Ukur dua metrik: MTBF dan MTTR

Keandalan terdiri dari dua angka. MTBF (rata-rata waktu antarkegagalan) untuk agen adalah berapa banyak langkah yang bisa dilewatinya sebelum macet. MTTR (rata-rata waktu pemulihan) adalah berapa lama dibutuhkan untuk kembali ke keadaan kerja setelah gagal. Ketersediaan naik baik karena yang pertama bertambah maupun karena yang kedua berkurang.

Mengejar agen yang sama sekali tidak pernah salah adalah perlombaan tanpa akhir. MTTR biasanya bisa diturunkan dalam satu hari. Karena itu mulailah dari angka kedua.

Langkah 3. Buat kesalahan menjadi murah

Otonomi dapat diterima bukan ketika agen berhenti salah, tetapi ketika biaya kesalahan turun hampir ke nol. Untuk itu dibutuhkan tiga hal:

• Commit kecil yang bersih — setiap perubahan bisa dibatalkan dengan satu perintah.
• Isolasi — agen bekerja di cabang atau salinan kerja terpisah, misalnya dengan git worktree, dan di sandbox tanpa akses ke produksi.
• Skrip reset lingkungan — basis data, dependensi, dan layanan kembali ke keadaan awal dengan satu perintah.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # buat ulang DB, terapkan migrasi, muat fixture

Ukur dengan stopwatch berapa lama pemulihan penuh ke keadaan kerja. Itulah MTTR Anda. Sekaligus batasi radius dampak: tetapkan batas ukuran diff untuk satu tugas dan larangan mengubah file di luar area tugas itu.

Langkah 4. Tutup lingkaran umpan balik

Tanpa pemeriksaan, agen adalah hakim tunggal bagi dirinya sendiri, dan ia dengan tulus menganggap pekerjaannya selesai. Berikan perintah yang bisa ia gunakan untuk memeriksa diri, dan jadikan perintah itu wajib.

• Fail-fast: pemeriksaan gagal pada kesalahan pertama dengan pesan yang jelas, bukan memuntahkan seratus baris derau.
• Pemeriksaan cepat setelah setiap perubahan: linter dan pemeriksaan tipe lewat hook agen.
• Redundansi: pemeriksaan kedua yang independen untuk sifat yang sama — skenario E2E di atas tes unit. Tes unit yang hijau tidak membuktikan bahwa fitur berfungsi bagi pengguna.

Tulis kriteria «selesai» sebagai kondisi yang bisa diverifikasi: «skenario E2E checkout dengan kode promo lulus», bukan «diskon sudah diimplementasikan».

Langkah 5. Pindahkan memori ke file

Agen tidak mengingat sesi sebelumnya. Semua yang dibutuhkan untuk melanjutkan kerja harus ada di repositori: tujuan, hal yang sudah dikerjakan dan cara verifikasinya, keputusan dengan alasannya, jalan buntu, dan langkah berikutnya. Tanda baiknya: sesi baru yang hanya menerima repositori dan kata «lanjutkan» langsung memulai pekerjaan yang berguna.

Riwayat percakapan yang dipadatkan memberi kesan kesinambungan, tetapi kehilangan hal yang paling berharga, yaitu alasan di balik opsi yang ditolak. Mengakhiri sesi secara sengaja dengan status tertulis yang lengkap biasanya lebih murah.

Langkah 6. Satu tugas dalam satu waktu

Hukum Little: jumlah tugas yang sedang dikerjakan sama dengan laju kedatangan dikali waktu tugas di dalam sistem. Dengan kapasitas tetap, tugas paralel tidak mempercepat pekerjaan, hanya memperpanjang setiap tugas. Untuk agen ini lebih ketat lagi: tiga fitur berarti tiga model domain di dalam satu jendela konteks.

• Pertahankan WIP=1: satu fitur sampai hasil yang terverifikasi.
• Potong tugas dengan ukuran yang tepat: satu kemampuan pengguna yang bisa diverifikasi, 1–3 file, pemeriksaan kurang dari semenit.
• Siapkan BACKLOG.md sebagai tempat untuk hal-hal «sekalian». Jika agen melihat kekurangan di dekatnya, cukup satu baris di backlog, bukan perubahan sendiri.

Langkah 7. Pisahkan pelaksana dan pemeriksa

Penilaian diri agen adalah rem yang lemah: sesi yang sama yang menulis kode cenderung menganggapnya benar. Biarkan hasil dinilai oleh subagen atau sesi terpisah yang hanya menerima persyaratan, diff, dan hasil pemeriksaan, tanpa penalaran pelaksana. Keputusan penilai harus bertumpu pada pemeriksaan mesin, bukan pada «kelihatannya baik».

Langkah 8. Lepaskan agen ke siklus otonom

Harness membuat satu kali jalan menjadi andal, siklus membuat serangkaian jalan menjadi otonom. Siklus di atas harness yang buruk hanya mempercepat perbanyakan kesalahan, sehingga langkah ini ditempatkan terakhir. Siklus paling sederhana bisa ditulis dalam tiga baris:

Tujuan:      skenario E2E pembayaran dengan kode promo lulus
Verifikasi:  make lint && make test && make e2e
Berhenti:    tujuan tercapai ATAU 15 percobaan ATAU 2 jam → panggil manusia

Pilih jenis siklus sesuai tugas. Jika pekerjaan punya garis akhir, dibutuhkan siklus berbasis tujuan: memori kemajuan, penilai independen, dan anggaran langkah. Jika tidak ada akhirnya (pemeriksaan CI pagi hari, pemilahan error baru), gunakan siklus berjadwal. Kesalahan yang sering terjadi adalah menjadwalkan tugas yang punya akhir: setiap peluncuran memulainya dari nol.

Aturan otonomi yang aman

• Kondisi berhenti hanya yang bisa diverifikasi mesin, ditambah batas percobaan dan anggaran.
• Eskalasi: sebelumnya tulis daftar hal yang tidak dipercayakan kepada siklus (migrasi produksi, uang, penghapusan data).
• Jika tugas macet dan kemajuan tidak nyata, itu tanda untuk menyerahkannya kepada manusia, bukan terus berputar.
• Baca diff-nya. Kecepatan siklus jangan melampaui kecepatan membaca Anda, kalau tidak Anda kehilangan pemahaman atas basis kode sendiri.

Kesalahan umum di jalur ini

Mulai dengan menulis ulang instruksi

Respons paling populer terhadap kegagalan agen adalah menambah aturan di AGENTS.md. Setelah beberapa bulan file membengkak menjadi ratusan baris, dan aturan penting di dalamnya tenggelam. Jika log kegagalan menunjukkan agen tidak menjalankan pemeriksaan, yang harus diperbaiki adalah umpan balik: perintah verifikasi dan hook, bukan paragraf teks tambahan.

Memperbaiki semuanya sekaligus

Kelima subsistem harness ingin diperbaiki bersamaan. Akibatnya tidak jelas apa yang sebenarnya membantu. Nilai setiap subsistem dengan skala 1 sampai 5, habiskan setengah jam untuk yang paling lemah, dan jalankan lima tugas tipikal yang sama sebelum dan sesudah. Perbedaan di log kegagalan akan menunjukkan apakah ada efeknya.

Menyamakan «tes hijau» dengan «fitur berfungsi»

Agen bisa menulis tes yang memeriksa implementasinya sendiri, bukan persyaratannya. Tes seperti itu selalu hijau. Pertahanannya adalah pemeriksaan di tingkat pengguna (skenario E2E), ditulis sebelum implementasi atau oleh pemeriksa independen, dan aturan bahwa agen tidak boleh mengubah tes agar lulus.

Mematikan pemeriksaan demi kecepatan

Pemeriksaan yang lambat menggoda untuk dilewati «kali ini saja». Lebih baik dipisah: linter dan pemeriksaan tipe yang cepat setelah setiap perubahan, serangkaian tes lengkap dan E2E sebelum kata «selesai». Dengan begitu lingkaran umpan balik tetap pendek dan tidak menghambat kerja.

Menjadikan ablasi sebagai langkah pertama

Anda bisa mematikan subsistem harness satu per satu dan melihat seberapa jauh kualitas turun. Ini berguna, tetapi mahal dan bukan langkah pertama: log kegagalan harus lebih dulu menunjuk hambatannya, dan ablasi hanya mengonfirmasi hipotesis. Penurunan nol saat sebuah komponen dimatikan tidak berarti komponen itu tidak diperlukan — mungkin saja set tugas yang dipilih tidak menggunakannya.

Tangga kematangan

Kesimpulan

Cara membuat agen AI andal: ukur, temukan subsistem yang lemah dari log kegagalan, buat kesalahan murah, tutup lingkaran umpan balik, simpan memori di file, pertahankan satu tugas dalam satu waktu, dan pisahkan pelaksana dari pemeriksa. Hanya setelah itu siklus otonom dengan kondisi berhenti yang bisa diverifikasi mesin menjadi aman. Setiap langkah dalam rencana ini dibahas langsung dalam praktik di kursus harness engineering.