Mengapa Agen Anda Tidak Pernah Berhenti Image: AI generated

Kebanggaan 24/7

“Agen saya berjalan 24 jam nonstop.”

Kalimat yang sering terlihat di X. Seolah-olah semakin lama agen berjalan, semakin banyak pekerjaan yang diselesaikannya. Seolah-olah manusia jadi lebih produktif kalau tidak tidur.

Tapi di hadapan kalimat ini, yang muncul bukanlah kekaguman melainkan pertanyaan.

“Kenapa belum selesai juga?”

Sistem yang sehat adalah sistem yang bisa berhenti

Saya menyerahkan tugas menulis tes untuk 527 fungsi kepada sebuah agen. Hasilnya:

Agen otonom:    Setelah 40 / 527 selesai, menyatakan "Sudah selesai"
Loop CLI:       Setelah menyelesaikan 527 / 527 hingga tuntas, berhenti

Loop CLI memakan waktu 1 jam. Bukan 24 jam. Memproses satu fungsi, memverifikasinya, kalau lulus lanjut ke berikutnya, dan kalau semuanya selesai berhenti. Inti dari loop ini bukan kecepatan, melainkan bahwa kondisi terminasinya terdefinisi secara mekanis.

TODO → tulis tes → ukur coverage → PASS/DONE → berikutnya → ... → semua selesai → berhenti

finite. measurable. monotonic. Karena itu ia konvergen. Karena itu ia berhenti.

Bisa berhenti bukanlah kelemahan. Itu berarti sehat.

Tiga alasan mengapa ia tidak berhenti

Ketika sebuah agen berjalan dalam waktu lama, biasanya itu salah satu dari tiga hal.

1. Verifikatornya lemah

"looks good"
"seems better"
"more scalable"
"clean architecture"

Hal-hal seperti ini bukan kriteria konvergensi. Itu penilaian subjektif. go test mengembalikan pass/fail, tapi siapa yang menentukan “clean architecture”? LLM lain? Itu sama saja seperti bertanya “apa aku mabuk?” kepada teman yang sedang mabuk.

Bukti empiris mendukung hal ini. Juri LLM untuk evaluasi kode menjadi bias bahkan terhadap variasi permukaan dari kode yang maknanya sama, sehingga skornya membengkak atau terpangkas secara tidak adil (Moon et al. 2025), dan model menekuk jawabannya sendiri untuk menyetujui pada 58,19% kasus (SycEval, Fanous et al. 2025). “looks good” tidak ada hubungannya dengan kebenaran. Lebih jauh lagi, kriteria yang lemah tidak berhenti hanya pada soal tidak bisa berhenti — ketika pengukuran dijadikan sasaran, pengukuran itu sendiri rusak (hukum Goodhart; Manheim & Garrabrant 2018), dan model penalaran yang cakap, alih-alih memecahkan tugas secara langsung, malah meretas prosedur verifikasi itu sendiri (Bondarenko et al. 2025).

Tanpa kriteria konvergensi, tidak ada akhir.

2. Tidak ada batas tugas

"Perbaiki codebase ini"
"Buat arsitekturnya lebih rapi"
"Terus optimalkan"

Ini tugas tanpa kondisi terminasi. Bahkan developer manusia pun tersesat tanpa henti dengan tujuan semacam ini. Agen tidak ada bedanya. “Perbaikan” adalah arah, bukan tujuan akhir.

3. Entropi melampaui kecepatan koreksi

Ini pola yang paling umum sekaligus paling licik.

Agen menambahkan abstraksi sambil melakukan perbaikan. Ia menyisipkan referensi tidak langsung. Ia membuat generalisasi yang tidak perlu. Kode tampak “menjadi lebih baik”, tapi sebenarnya entropi baru bertambah lebih cepat daripada kecepatan verifikator menghilangkannya.

Abstraksi yang dibuat hari ini → besok dihapus lagi → lusa ditambahkan lagi

Ini adalah optimisasi non-monotonik (non-monotonic optimization). Tampak bergerak maju, tapi sebenarnya di tempat. Tampak seperti mesin gerak abadi, tapi sebenarnya hanya menghabiskan energi. Dalam kasus ini energi itu adalah token.

Bukti empiris berskala besar menangkap drift ini. Adopsi Cursor menaikkan kecepatan jangka pendek, tapi peringatan analisis statis dan kompleksitas kode terus meningkat, dan akumulasi inilah penyebab utama perlambatan kecepatan jangka panjang (He et al. 2025, 807 repositori open source). Dari lebih dari 300 ribu commit yang ditulis AI, 22,7% isu yang diperkenalkan bertahan sebagai utang teknis hingga versi terbaru (Liu et al. 2026). Koreksi tidak mampu mengejar entropi.

Ini bukan masalah pencarian, melainkan masalah pemenuhan kendala

Di sinilah perbedaan sudut pandang yang fundamental terungkap.

“Menjalankan agen lebih lama menghasilkan hasil yang lebih baik” adalah cara pandang yang melihat rekayasa perangkat lunak sebagai masalah pencarian (search problem). Harapan bahwa menjelajahi ruang yang luas dalam waktu lama akan menemukan solusi yang lebih baik.

Tapi rekayasa perangkat lunak pada hakikatnya adalah masalah pemenuhan kendala (constraint satisfaction problem).

  • Tipe harus cocok
  • Tes harus lulus
  • Coverage harus terpenuhi
  • Skema harus selaras
  • Aturan lint harus dipatuhi

Begitu semua kendala ini terpenuhi, selesai. Tidak perlu “mencari lebih jauh”. Mendefinisikan kendala, memenuhinya, lalu berhenti. Itu saja.

Kode sudah merupakan wilayah yang dapat diperiksa secara mekanis (machine-checkable domain). Compiler, type checker, tes, coverage, linter, validasi skema — semua ini adalah verifikator deterministik. Padahal verifikator-verifikator ini sudah ada, lalu mengapa memaksa agen mencari tanpa henti?

Penelitian pembelajaran juga menunjuk ke arah yang sama. Ketika verifikator deterministik seperti unit test dipakai sebagai reward — verifiable reward — akurasi kode menjadi lebih tinggi dibanding generasi terbuka (CodeRL, Le et al. 2022; RLTF, Liu et al. 2023). Verifikator bukan alat untuk mempersempit pencarian. Ia adalah bukti yang justru menyingkapkan bahwa masalah ini sejak awal bukanlah pencarian, melainkan pemenuhan.

Syarat sebuah loop yang baik

Loop agen yang baik tertutup dalam lima tahap:

1. Definisi tugas    — apa yang harus dicapai (tujuan yang dapat dinilai secara mekanis)
2. Pembatasan ruang  — satu unit dalam satu waktu (fungsi, endpoint, file)
3. Verifikasi simbolik — alat deterministik menentukan pass/fail
4. Konvergensi       — kalau lulus lanjut, kalau gagal coba lagi dengan umpan balik
5. Terminasi         — kalau tidak ada item tersisa, berhenti

Dalam struktur ini LLM hanya menangani nomor 3 (generasi). Sisanya semua dikerjakan oleh mesin. Yang paling penting, mesinlah yang menentukan “akhir”. Kalau Anda menyerahkan keputusan terminasi kepada LLM, Anda akan mendengar “Sudah selesai” pada 40/527.

Eksperimen juga menunjuk ke arah yang sama. Ketika LLM dilengkapi self-critique, performa pada tugas penalaran dan perencanaan justru runtuh, dan hanya membaik secara signifikan ketika dilengkapi verifikator eksternal yang sehat (Stechly et al. 2024). Koreksi diri intrinsik tanpa umpan balik eksternal akan gagal, atau kadang menjadi lebih buruk setelah dikoreksi (Huang et al. 2023). Ada alasan mengapa terminasi tidak diserahkan kepada LLM.

creative writing berbeda dari kode

Ada satu pengecualian. Tidak semua wilayah seperti ini.

Menulis, pemasaran, desain — wilayah ini verifikatornya lemah. “Apakah kalimat ini bagus?” tidak bisa dinilai secara mekanis. Di wilayah seperti ini, pencarian yang panjang bisa jadi bermakna. Caranya: agen menghasilkan berbagai variasi, lalu manusia memilih.

Tapi kode berbeda. Kode sudah merupakan dunia yang penuh dengan verifikator deterministik. Di dunia ini, mengembara (wandering) dalam waktu lama bukanlah pencarian, melainkan hanyut (drift).

Pertanyaan

Sudah berapa jam agen Anda berjalan sekarang?

Apakah ia sedang konvergen, atau sedang hanyut?

Bisakah ia berhenti?

Kalau bisa berhenti, mengapa ia belum berhenti juga?

Artikel terkait

Bacaan lebih lanjut (eksternal)

  • Designing agentic loops — Simon Willison. Harus ada kriteria keberhasilan yang jelas dan suite tes yang lulus agar loop agen bisa memverifikasi dirinya sendiri dan berhenti — pasangan konstruktif dari tulisan ini.
  • Building Effective Agents — Anthropic. Alasan pengkodean ideal untuk agen adalah karena solusinya dapat diverifikasi dengan tes otomatis — verifikator deterministik menjadi sinyal berhenti.
  • Termination logic is the underrated design problem in agentic AI systems — Glen Rhodes. Keputusan desain inti bukanlah model yang lebih baik melainkan kondisi terminasi yang terukur, dan mewaspadai “confidence laundering” di mana output yang fasih menyembunyikan non-konvergensi.
  • Harness engineering for coding agent users — Birgitta Böckeler, Thoughtworks. Keandalan datang bukan dari model melainkan dari harness alat deterministik (computational controls) — dibedakan dari kontrol inferensial berbasis AI.
  • Reward Hacking in Reinforcement Learning — Lilian Weng. “Ketika pengukuran menjadi sasaran, ia tidak lagi menjadi pengukuran yang baik” — rangkuman teknis tentang mekanisme menggaming proksi ketika verifikator lemah dipakai sebagai reward.
  • Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma. Semakin banyak token input menumpuk, output semakin memburuk — penyebab mekanis mengapa loop yang berulang menambah, menghapus, dan menambah lagi menjadi penguatan diri alih-alih koreksi diri.
  • Vibe Coding Will Destroy Your Codebase (But You’re Probably Not Doing It) — Ariel Perez. AI memperkuat rigor yang sudah ada — pada rigor yang rendah ia mempercepat kekacauan, sebuah sudut pandang praktis tentang fenomena entropi yang mendahului koreksi.

Sumber

Penilaian terminasi · batas verifikasi diri

  • Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
  • Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · ketidakandalan kritik diri

  • Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
  • Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
  • Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

Drift · peningkatan kompleksitas kode AI

  • He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
  • Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

Verifiable reward · generasi kode berbasis verifikator

  • Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
  • Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

Reward hacking · specification gaming

  • Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
  • McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
  • Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
  • Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)