Mengapa Coding Agent Bekerja dan Mengapa Runtuh Image: AI generated

Model yang sama. Yang berhalusinasi di web chat mengirimkan fitur 200 baris di Claude Code dalam satu kali percobaan. /goal Codex menyelesaikan satu issue secara keseluruhan. Model tidak tiba-tiba jadi lebih pintar. Yang berubah adalah strukturnya.

Mengapa Bekerja

Loop AI percakapan seperti ini:

LLM → manusia → LLM → manusia

Semua feedback adalah bahasa alami. Generasi probabilistik diikuti evaluasi probabilistik. Akurasi terdegradasi sebagai perkalian.

Loop coding agent berbeda:

LLM → generasi kode → simpan file → jalankan tes → pass/fail → LLM
LLM → edit kode → build → berhasil/gagal → LLM
LLM → type check → pesan error → LLM

Gate deterministik tertanam dalam loop. Filesystem menyimpan persis apa yang ditulis. Tes adalah pass atau fail. Compiler bilang salah ketika salah. Ini secara tidak sengaja berfungsi sebagai ratchet.

LLM adalah komponen tidak andal. Tapi membangun protokol andal di atas komponen tidak andal adalah dasar rekayasa. Von Neumann membuktikan secara matematis pada 1956 bahwa majority voting saja bisa membuat komponen berisik melakukan komputasi andal (Von Neumann, 1956). TCP membangun pengiriman andal di atas jaringan tidak andal. RAID membangun penyimpanan andal di atas disk tidak andal. ECC membangun komputasi andal di atas memori tidak andal.

Alasan coding agent bekerja sama. LLM tidak andal dilengkapi verifier deterministik (tes, build, linter, type checker). Studi SWE-agent menunjukkan bahwa model yang sama pun menunjukkan performa yang sangat berbeda tergantung desain Agent-Computer Interface (Yang et al., NeurIPS 2024). Topologi, bukan kemampuan model, yang menyebabkan keberhasilan.

Tapi Mengapa Runtuh?

Mereka bekerja, saya bilang. Tapi kadang runtuh. Mengapa?

Karena ratchet yang ada secara kebetulan dan ratchet yang dirancang secara sadar adalah hal yang berbeda.

Ada zona tanpa ratchet

Ketika agen mengedit kode tanpa tes? Build lolos, lint lolos, tapi fungsionalitas rusak. Di zona tanpa gate deterministik, LLM menilai secara probabilistik, dan penilaian probabilistik terdegradasi sebagai perkalian.

Dari 200 endpoint, 180 punya tes dan 20 tidak. Agen menangani 180 dengan sempurna dan diam-diam menanam bug di 20. Itulah mengapa Anda mendapat “hampir selesai, tapi ada yang aneh.”

Informasi feedback tidak cukup

Saya menjalankan eksperimen pengurutan 1.000 kata. CPU: 0,08ms pada 100%. LLM: 438 detik pada 97,7%. Itu sendiri luar biasa — 97,7% melalui kognisi murni. Tapi penemuan sebenarnya ada di tempat lain.

Saya hanya memvariasikan level feedback pada hasil yang sama:

FeedbackHasil
Tidak ada6 error (99,4%)
“Ada error”10 error (99,0%) — lebih buruk
“Ada 23 error”1 error (99,9%)
“6 error, ini lokasinya”0 error (100%)

Hanya memberitahu “kamu salah” menyebabkan koreksi berlebihan dan memperburuk. Memberikan hitungan menciptakan target untuk dikejar. Memberikan lokasi mencapai kesempurnaan.

Sebagian besar agen saat ini beroperasi di level kedua. Ketika tes gagal, mereka tahu “ada yang salah,” tapi tidak menyampaikan alasan struktural. Pesan error ada, tapi itu gejala, bukan penyebab.

Titik buta ada, dan pengulangan tidak memperbaikinya

Dalam eksperimen pengurutan, LLM meninggalkan 6 error di R2. Di R3, melaporkan “tidak ada error.” Di R4b, lagi melaporkan “tidak ada error.” Melewatkan 6 yang sama dengan cara yang sama.

Tanpa petunjuk, berapa kali pun diulang, konvergen di 99,4%. Hanya ketika diberitahu “tersisa 6” akhirnya mencapai 100%.

Hal yang sama terjadi dengan coding agent. Agen membuat bug, self-review dengan “terlihat baik,” dan ketika diminta memperbaiki lagi, melewatkan titik yang sama. Huang et al. (2024) menunjukkan bahwa tanpa feedback eksternal, LLM yang mengoreksi sendiri error penalarannya justru menurunkan performa (Huang et al., ICLR 2024). Inilah mengapa retry bukan jawabannya. Titik buta adalah keterbatasan struktural dari sifat probabilistik model, bukan kurangnya usaha.

Perkalian bekerja pada skala

Akurasi 97,7% dirantai dua kali: 0,977² = 95,4%. Tiga kali: 93,2%. Sepuluh kali: 79,2%.

Agen mengedit satu file bekerja dengan baik. Tapi minta refactoring 100 file? Bahkan pada 97% per langkah, 100 langkah memberi 0,97¹⁰⁰ = 4,8%. Kegagalan hampir terjamin.

Ini penjelasan matematis untuk “vibe coding runtuh di 200 endpoint.” Di proyek kecil, jumlah rantai cukup rendah agar probabilitas bertahan. Di proyek besar, perkalian menjadi bencana.

Apa yang Dibutuhkan

Alasan bekerja dan alasan runtuh menunjuk ke tempat yang sama: ada atau tidaknya gate verifikasi deterministik.

Agen saat ini bergantung pada ratchet yang ada secara kebetulan (tes, build, linter). Merancangnya secara sadar membuatnya lebih kuat.

Apa artinya merancang ratchet secara sadar:

Pertama, identifikasi zona tanpa ratchet. Kode tanpa tes, API tanpa schema, data tanpa tipe. Setiap tempat di mana agen menilai secara probabilistik adalah kerentanan.

Kedua, tingkatkan konten informasi feedback. Mengembalikan hanya pass/fail memicu koreksi berlebihan. “Di mana, mengapa, dan bagaimana aktual berbeda dari yang diharapkan” harus disampaikan dalam bentuk terstruktur.

Ketiga, sisipkan gate deterministik di antara langkah rantai. Menjalankan 10 langkah sekaligus membuat perkalian bencana, tapi mengunci dengan ratchet di setiap langkah mereset degradasi.

LLM adalah generator luar biasa. Mereka mengurutkan 1.000 kata dengan akurasi 97,7% melalui kognisi murni. Manusia tidak bisa melakukan ini. Tapi apa pun kurang dari 100% runtuh di bawah pengulangan. 0,977 kuadrat adalah 0,954.

Coding agent bekerja bukan karena modelnya pintar. Mereka bekerja karena gate deterministik tertanam dalam loop. Mereka runtuh karena gate tersebut absen.

Generasi boleh probabilistik. Verifikasi harus deterministik.


Artikel Terkait

Referensi

  1. Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” In Shannon, C.E. & McCarthy, J. (Eds.), Automata Studies, Annals of Mathematical Studies, No. 34, Princeton University Press, pp. 43-98.
  2. Saltzer, J.H., Reed, D.P., & Clark, D.D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems, 2(4), 277-288.
  3. Patterson, D.A., Gibson, G., & Katz, R.H. (1988). “A Case for Redundant Arrays of Inexpensive Disks (RAID).” Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, pp. 109-116.
  4. Hamming, R.W. (1950). “Error Detecting and Error Correcting Codes.” The Bell System Technical Journal, 29(2), 147-160.
  5. Yao, S. et al. (2023). “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023.
  6. Shinn, N. et al. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
  7. Jimenez, C.E. et al. (2024). “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
  8. Yang, J. et al. (2024). “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” NeurIPS 2024.
  9. Huang, J. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
  10. Kamoi, R. et al. (2024). “When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs.” TACL, 12, 1298-1318.
  11. Cemri, M. et al. (2025). “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657.
  12. Arbuzov, M.L., Shvets, A.A., & Beir, S. (2025). “Beyond Exponential Decay: Rethinking Error Accumulation in Large Language Models.” arXiv:2505.24187.

Changelog

  • 2026-05-16: Rilis awal