Loop engineering: dari memberi prompt satu per satu ke sistem yang bekerja sampai terbukti selesai

Anatomi loop yang layak jalan tanpa diawasi: trigger, verifier deterministik, memory di luar chat, budget, dan terminal state seperti DONE_WITH_EVIDENCE.

17 Jul 2026 15 menit baca

Loop Engineering Coding Agent Automation

Coding agent biasanya diperkenalkan lewat percakapan. Engineer memberi tugas, membaca hasil, mengoreksi arah, lalu mengirim prompt berikutnya sampai perubahan kode terlihat selesai. Pola itu berguna, tetapi manusia masih menjadi scheduler, memory, reviewer, dan stop condition pada saat yang sama. Loop engineering mencoba memindahkan empat fungsi tersebut ke sistem yang dapat dijalankan berulang dengan batas yang jelas.

Istilahnya baru populer pada pertengahan 2026, tetapi mekanismenya tidak muncul dari ruang kosong. Agent loop sudah menjadi inti coding agent: model menerima context, meminta tool, membaca hasil tool, lalu mengulang sampai menghasilkan final response. Geoffrey Huntley sebelumnya memperlihatkan pola "Ralph" yang terus memberi pekerjaan dan feedback kepada agent dalam repository, sementara Anthropic mendokumentasikan progress file dan handoff lintas context window untuk long-running agent. Nama baru itu merangkum praktik yang mulai menyatu menjadi satu lapisan engineering tersendiri.

Agent loop bukan otomatis loop engineering

Setiap coding agent sudah memiliki loop internal. Codex, Claude Code, Gemini CLI, dan tool serupa mengirim prompt ke model, mengeksekusi tool call, menambahkan observation ke context, lalu meminta model menentukan tindakan berikutnya. OpenAI menyebut mekanisme ini sebagai core logic yang mengatur hubungan user, model, dan tools. Tanpa loop tersebut, model hanya menghasilkan teks dan tidak dapat menguji atau memperbaiki pekerjaannya sendiri.

Loop engineering bekerja satu tingkat di atas mekanisme itu. Engineer tidak hanya menentukan tool yang dapat dipanggil oleh satu agent, tetapi juga kapan pekerjaan dimulai, bagaimana pekerjaan dibagi, siapa yang memeriksa hasil, state apa yang dipertahankan, dan kapan sistem wajib berhenti. Addy Osmani menggambarkannya sebagai sistem yang menemukan pekerjaan, membagikannya, memeriksa hasil, mencatat progress, lalu menentukan pekerjaan berikutnya. Jadi, agent loop adalah mesin dasarnya, sedangkan loop engineering adalah desain operasional yang membuat mesin tersebut bekerja berulang dalam proses nyata.

Perbedaan ini penting karena sebuah while true bukan desain yang cukup. Loop tanpa verifier hanya mengulang keyakinan model. Loop tanpa memory dapat mengulangi kegagalan yang sama pada sesi berikutnya. Loop tanpa stop condition dapat membakar token, mengubah terlalu banyak file, atau berhenti karena model merasa puas meskipun acceptance criteria belum terpenuhi.

Prompt, context, harness, dan loop tidak saling menggantikan

Istilah baru sering dipasarkan seolah-olah istilah sebelumnya sudah mati. Dalam praktiknya, setiap lapisan tetap dibutuhkan karena mengendalikan hal yang berbeda. Prompt yang buruk tetap dapat merusak loop yang bagus, dan memory yang besar tidak menolong bila verifier mengukur sasaran yang salah.

Lapisan	Pertanyaan yang dijawab	Artifact utama
Prompt engineering	Apa instruksi untuk langkah atau keputusan ini?	Prompt, rubric, task instruction
Context engineering	Informasi apa yang harus terlihat oleh model saat ini?	File, retrieval, tool result, compacted history
Harness engineering	Lingkungan apa yang memungkinkan satu agent bekerja dengan aman dan efektif?	Tools, sandbox, repository conventions, skills, permissions
Loop engineering	Bagaimana pekerjaan dimulai, diulang, diverifikasi, disimpan, dan dihentikan?	Trigger, state machine, verifier, memory, budget, terminal states

OpenAI menunjukkan bahwa kegagalan agent sering berasal dari environment yang kurang terbaca, bukan sekadar model yang kurang kuat. Tim pada studi kasus harness engineering memperbaiki repository, test, tools, dan feedback path agar Codex dapat mengerjakan task yang lebih besar. Loop engineering menggunakan fondasi itu, lalu menambahkan mekanisme untuk menjalankan pekerjaan secara berkala atau sampai bukti tertentu terpenuhi.

Urutan tersebut juga tidak selalu linear. Tim dapat memperbaiki prompt sambil mengubah harness dan verifier pada hari yang sama. Yang berubah adalah unit analisisnya: engineer tidak lagi menilai satu jawaban model, tetapi menilai perilaku sistem selama banyak langkah dan banyak run.

Anatomi loop yang dapat dipertanggungjawabkan

Kerangka praktis Addy Osmani menyusun loop dari automations, worktrees, skills, connectors, sub-agents, dan memory. LangChain melihatnya sebagai tumpukan agent loop, verification loop, event-driven loop, dan hill-climbing loop. Dua kerangka itu memakai bahasa yang berbeda, tetapi bertemu pada komponen operasional yang sama.

Komponen	Fungsi	Pertanyaan desain
Trigger	Memulai run dari jadwal, event, issue, atau permintaan manusia	Apa yang cukup penting untuk menyalakan loop?
Goal	Menetapkan outcome yang harus dicapai	Apakah goal dapat diperiksa, bukan hanya dideskripsikan?
Executor	Membuat rencana dan melakukan perubahan melalui tools	Tool dan permission apa yang benar-benar diperlukan?
Verifier	Menguji output terhadap test, rubric, policy, atau evidence	Bukti apa yang harus ada sebelum status berubah menjadi selesai?
Memory / state	Menyimpan progress, kegagalan, keputusan, dan task berikutnya	Apa yang harus bertahan setelah context dibuang?
Isolation	Mencegah dua run saling menimpa	Apakah setiap task memakai branch, worktree, sandbox, atau environment terpisah?
Stop condition	Mengakhiri run secara sukses, gagal, atau escalated	Kapan agent harus berhenti meskipun goal belum tercapai?
Budget	Membatasi token, waktu, tool call, biaya, dan scope perubahan	Berapa harga maksimum satu hasil?
Human escalation	Mengembalikan keputusan yang ambigu atau berisiko	Perubahan apa yang tidak boleh dilakukan secara otomatis?

Sebuah preprint pada Juni 2026 memakai istilah loop specification untuk artifact yang memuat trigger, goal, verification, stopping rule, dan memory. Kerangka tersebut berguna karena memaksa loop memiliki terminal state yang dinamai, misalnya DONE_WITH_EVIDENCE, BLOCKED, BUDGET_EXCEEDED, atau NEEDS_HUMAN. Status seperti itu lebih informatif daripada membiarkan model menulis "task completed" pada akhir percakapan.

Terminal state juga perlu terikat pada state sumber. Test yang lulus sebelum agent mengubah file bukan bukti bahwa commit terakhir aman. Review yang dijalankan pada branch berbeda tidak membuktikan branch target siap merge. Verifier harus bekerja pada artifact terbaru yang benar-benar akan dipromosikan.

Verifier adalah pusat loop, bukan aksesori

Agent dapat menghasilkan banyak perubahan dengan cepat, tetapi volume tidak identik dengan progress. LangChain menempatkan verification loop tepat setelah agent loop: output dinilai terhadap rubric, lalu feedback dikembalikan jika hasil belum memenuhi syarat. Untuk dokumentasi, verifier dapat memeriksa link, CI, format, dan scope diff. Untuk kode, verifier dapat berupa test suite, type checker, linter, security scan, browser test, atau kombinasi beberapa alat.

Verifier deterministik biasanya lebih kuat daripada penilaian verbal untuk hal yang dapat dihitung. Status HTTP, unit test, schema validation, checksum, dan query invariant memberi signal yang lebih konsisten daripada meminta model menilai apakah hasilnya "terlihat benar". LLM-as-a-judge masih berguna untuk framing, relevance, atau kualitas narasi, tetapi tidak seharusnya menggantikan test mekanis yang sudah tersedia.

Pemisahan maker dan checker mengurangi kecenderungan agent membenarkan pekerjaannya sendiri. Agent berbeda untuk implementasi dan review, bahkan dengan model atau reasoning effort berbeda, memberi second opinion yang lebih jujur. Biayanya lebih tinggi karena setiap checker juga membaca context dan memakai tools. Tambahan biaya itu masuk akal hanya untuk bagian yang benar-benar membutuhkan second opinion.

Test juga harus tahan terhadap manipulasi. Agent tidak boleh memperbaiki skor dengan menghapus test, memperlemah assertion, atau mengubah acceptance criteria tanpa izin. Anthropic menemukan bahwa struktur state dan instruksi yang tegas diperlukan agar long-running agent tidak menandai fitur sebagai lulus dengan cara yang merusak tujuan awal.

Memory harus berada di luar percakapan

Context window bukan database proyek. Ketika sesi berakhir, diringkas, atau dipindahkan ke agent lain, detail tentang keputusan lama dapat hilang. Anthropic menggambarkan masalah ini seperti pergantian shift engineer tanpa ingatan tentang pekerjaan sebelumnya. Solusinya bukan sekadar context lebih panjang, tetapi artifact yang meninggalkan state secara eksplisit.

Progress file yang baik mencatat task selesai, task berikutnya, percobaan yang gagal, alasan kegagalan, hasil test, limitation, dan commit terakhir yang stabil. Git history memberi jalur recovery saat perubahan baru memperburuk keadaan. Issue tracker dapat menyimpan ownership dan status lintas agent, sedangkan file seperti AGENTS.md, CLAUDE.md, atau skill file menyimpan aturan yang relatif stabil.

Memory juga perlu dibedakan berdasarkan umur. Project rules dan architecture decision dapat bertahan lama. Scratch notes, log mentah, dan tool output besar sebaiknya disaring agar tidak memenuhi context berikutnya. Loop yang hanya menumpuk semua history akan menjadi semakin mahal dan semakin sulit memahami signal penting.

Addy Osmani merangkum prinsip ini dengan sederhana: model dapat lupa, tetapi repository tidak. Karena itu state yang menentukan pekerjaan berikutnya harus dapat dibaca ulang tanpa bergantung pada percakapan yang masih terbuka.

Parallel agent membutuhkan isolasi, bukan hanya lebih banyak model

Menjalankan beberapa agent secara bersamaan terlihat seperti cara mudah mempercepat pekerjaan. Masalahnya, dua agent yang mengubah file, dependency, atau migration yang sama dapat menghasilkan konflik yang sulit dilacak. Worktree, branch, container, dan sandbox memberi boundary agar setiap run memiliki sumber dan output yang jelas.

Parallelism paling efektif ketika task memang dapat dipisahkan. Satu agent dapat mengeksplorasi codebase, satu membuat implementation, dan satu melakukan review. Untuk task yang memiliki dependency kausal kuat, agent sequential sering lebih aman karena setiap langkah membutuhkan hasil langkah sebelumnya. Menambah sub-agent pada masalah yang tidak dapat diparalelkan hanya menambah token dan koordinasi.

Hasil parallel run juga memerlukan tahap integrasi. Merge agent atau human reviewer perlu mengetahui branch mana yang menjadi sumber kebenaran, test apa yang sudah dijalankan, dan conflict mana yang diselesaikan. Tanpa control plane, sekumpulan terminal agent hanya memindahkan beban dari menulis kode menjadi melacak banyak sesi.

OpenAI membangun Symphony setelah menemukan bahwa engineer mulai kewalahan mengelola beberapa sesi interaktif. Sistem itu memakai issue tracker sebagai control plane, memberi satu agent pada task yang terbuka, dan mengembalikan hasil untuk review manusia. Angka peningkatan PR pada artikel tersebut adalah klaim studi kasus OpenAI, tetapi masalah yang ingin diselesaikan lebih umum: human attention menjadi bottleneck ketika jumlah agent bertambah.

Contoh loop untuk memperbaiki regression

Satu loop yang sempit lebih mudah dievaluasi daripada automation yang mencoba mengelola seluruh SDLC. Contohnya adalah loop yang mencari regression dari CI pada repository aktif. Trigger-nya adalah test gagal pada branch utama atau schedule harian yang membaca kegagalan sejak run terakhir.

Loop kemudian membuat task terisolasi dan meminta explorer mengumpulkan commit terkait, log, stack trace, serta test yang terdampak. Executor membuat perubahan pada worktree sendiri. Verifier menjalankan test yang semula gagal, regression suite yang relevan, linter, dan batas scope diff. Jika bukti belum cukup, hasil verifier kembali menjadi feedback untuk percobaan berikutnya.

State file menyimpan root-cause hypothesis, percobaan yang sudah dilakukan, commit, dan hasil test. Loop berhenti sebagai DONE_WITH_EVIDENCE ketika seluruh gate lulus, BLOCKED ketika dependency eksternal rusak, NEEDS_HUMAN ketika pilihan produk diperlukan, atau BUDGET_EXCEEDED ketika batas waktu dan token habis. Hanya status pertama yang boleh membuka pull request siap review.

Diagram alur loop perbaikan regression: trigger CI atau schedule, siklus kumpulkan bukti, worktree terisolasi, verifikasi gate deterministik, state dan feedback, lalu terminal state DONE_WITH_EVIDENCE, BLOCKED, NEEDS_HUMAN, atau BUDGET_EXCEEDED — Loop perbaikan regression: siklus berulang sampai gate lulus; hanya DONE_WITH_EVIDENCE yang membuka pull request.

Diagram tersebut terlihat sederhana karena kompleksitas sengaja ditempatkan pada contract. Goal, gate, state, dan terminal state harus jelas sebelum agent diberi kebebasan mengulang. Model yang lebih kuat dapat meningkatkan kualitas tiap percobaan, tetapi tidak menggantikan contract tersebut.

Event-driven dan self-improving loop berada pada tingkat risiko berbeda

Loop paling dasar dijalankan manusia untuk satu task. Event-driven loop bergerak lebih jauh: schedule, webhook, issue baru, atau file baru dapat memulai pekerjaan tanpa prompt manual. Begitu trigger menjadi otomatis, idempotency, deduplication, retry policy, dan permission menjadi bagian dari desain utama.

LangChain menambahkan lapisan hill-climbing yang menganalisis trace dan mengusulkan perubahan pada prompt, tool, grader, atau memory. Ide ini menjanjikan karena feedback produksi dapat memperbaiki harness. Namun, sistem yang mengubah aturan evaluasinya sendiri memiliki risiko berbeda dari sistem yang hanya mengulang task. Perubahan terhadap verifier harus diperlakukan seperti perubahan kode produksi, lengkap dengan versioning, held-out eval, review, dan rollback.

Self-improvement tanpa test terpisah mudah berubah menjadi optimasi terhadap metric yang sempit. Agent dapat terlihat semakin berhasil karena rubric dibuat lebih mudah, bukan karena kualitas kerja meningkat. Karena itu, loop yang mengubah dirinya sendiri memerlukan boundary lebih ketat daripada loop yang hanya mengubah application code.

Human oversight tetap diperlukan pada keputusan yang memiliki konsekuensi tinggi. Database migration, financial transaction, permission change, deployment production, dan penghapusan data tidak layak dilepas hanya karena beberapa test lokal lulus. Automation dapat menyiapkan bukti dan rekomendasi, tetapi approval final tetap menjadi gate eksplisit.

Trade-off yang sering hilang dari demo

Loop mengubah biaya dari satu inference menjadi rangkaian inference, tool call, test, dan review. Verification meningkatkan kualitas, tetapi juga menambah latency dan token. Sub-agent, parallel branch, dan long-running memory memperbesar biaya lebih jauh. Karena itu metrik yang tepat bukan harga satu prompt, melainkan cost per accepted task.

Loop juga dapat menghasilkan activity tanpa progress. Agent mungkin bolak-balik antara dua solusi, mengulang test yang sama, atau membuat perubahan kecil agar terlihat aktif. Counter seperti jumlah tool call atau jumlah commit tidak cukup. Progress harus diukur terhadap acceptance criteria yang benar-benar mendekat ke outcome.

Risiko kedua adalah comprehension debt. Sistem dapat menghasilkan lebih banyak perubahan daripada yang mampu dipahami tim. Ketika incident terjadi, engineer harus mengetahui architecture, dependency, dan alasan keputusan, bukan hanya memiliki log bahwa agent pernah menjalankan test. Kecepatan merge yang melebihi kecepatan pemahaman akan memindahkan biaya ke maintenance dan incident response.

Risiko ketiga adalah keamanan. Connector memperluas apa yang dapat dibaca dan dilakukan loop. Prompt injection pada issue, email, dokumentasi, atau halaman web dapat mencoba mengubah perilaku agent. Principle of least privilege, sandbox, allowlist tool, approval untuk tindakan sensitif, dan audit trail harus menjadi bagian loop sejak awal.

Kapan loop engineering layak digunakan

Loop engineering paling cocok untuk pekerjaan berulang dengan outcome yang dapat diuji. CI triage, dependency update, dokumentasi yang memiliki link checker, migration dengan invariant, data cleanup dengan reconciliation, dan bug fixing dengan reproducer adalah kandidat yang baik. Task seperti itu memiliki trigger jelas, evidence yang dapat dikumpulkan, dan failure state yang dapat didefinisikan.

Pekerjaan subjektif dengan goal yang terus berubah lebih sulit. Menentukan positioning produk, memilih architecture baru, atau menulis kebijakan perusahaan memerlukan judgment dan negosiasi yang tidak dapat diringkas menjadi test lulus atau gagal. Agent tetap dapat membantu mencari opsi dan menyiapkan draft, tetapi loop sebaiknya berhenti pada titik keputusan manusia.

Loop juga tidak layak bila satu kesalahan memiliki konsekuensi besar dan rollback sulit. Automation untuk produksi dapat dibangun secara bertahap, dimulai dari mode read-only, recommendation-only, lalu action dengan approval. Autonomy seharusnya meningkat setelah evidence menunjukkan sistem stabil, bukan sebelum monitoring tersedia.

Prinsip awal yang aman adalah memilih satu workflow sempit, satu source of truth, satu verifier deterministik, satu budget, dan satu jalur escalation. Setelah failure mode terlihat dan dapat direproduksi, barulah trigger, parallelism, serta scope diperluas.

Loop engineering bukan tujuan akhir

Loop engineering menjawab cara satu atau beberapa agent bekerja berulang sampai mencapai terminal state. Ia tidak sendiri menjawab siapa yang bertanggung jawab atas architecture, bagaimana organisasi mengelola risk, bagaimana output masuk ke SDLC, atau kemampuan apa yang harus dimiliki engineer. Pertanyaan itu berada pada wilayah agentic engineering.

Hubungan keduanya serupa dengan event loop dan software engineering. Event loop adalah mekanisme penting, tetapi membangun produk memerlukan design, testing, observability, security, deployment, dan ownership. Dalam sistem agentic, loop adalah mekanisme eksekusi; agentic engineering adalah disiplin untuk merancang dan mengoperasikan seluruh sistem kerja manusia dan agent.

Karena itu artikel berikutnya tidak menganggap loop engineering sudah usang. Justru loop menjadi salah satu primitive terpenting di dalam agentic engineering. Perbedaannya terletak pada scope: loop mengatur pengulangan pekerjaan, sedangkan agentic engineering mengatur outcome dan tanggung jawab sistem secara keseluruhan.

Penutup

Perubahan terbesar loop engineering bukan bahwa agent dapat bekerja lebih lama. Coding agent memang sudah dapat memanggil tool berulang sejak awal. Perubahannya adalah manusia mulai mengemas trigger, goal, verifier, memory, isolation, budget, dan stop condition menjadi artifact yang dapat dijalankan ulang. Dengan artifact itu, reliability tidak lagi bergantung penuh pada engineer yang terus mengawasi terminal.

Loop yang baik tidak meminta kepercayaan pada agent. Ia meminta bukti dari environment. Test, trace, commit, state, dan approval menentukan apakah pekerjaan dapat bergerak ke tahap berikutnya. Semakin tinggi autonomy, semakin kuat bukti dan boundary yang dibutuhkan.

Loop engineering juga tidak menghapus prompt engineering atau context engineering. Ia menggunakan keduanya di dalam sistem yang lebih besar. Pertanyaan praktisnya bukan lagi "prompt apa yang harus saya tulis berikutnya?", tetapi "sistem apa yang dapat menentukan langkah berikutnya, memeriksa hasilnya, dan berhenti sebelum membuat kerusakan?" Mulailah dari satu workflow dengan acceptance criteria mekanis, tulis terminal state sebelum menulis automation, simpan progress di luar chat, hitung biaya per accepted task, dan tambahkan autonomy hanya setelah verifier serta audit trail bekerja.