Loop Engineering: Gue Berhenti Nge-Prompt Agent, dan Mulai Design Sistem yang Nge-Prompt Agent Buat Gue

Gue inget exactly momen gue sadar cara gue pake AI agent itu salah. Juli 2026, gue lagi review pull request di repo blog ini. Gue buka Claude Code, ketik prompt: "review PR ini, cari bug, kasih suggestion." Tunggu 2 menit. Baca output. Prompt lagi: "fix bug di line 45." Tunggu. Prompt lagi: "tambahin test buat fix-nya." Tunggu. Prompt lagi: "jalanin testnya, kalau fail, fix."

2 jam berlalu. Gue ngerasa produktif - lihat PR udah ke-review, bug ke-fix, test ke-tambah. Tapi waktu gue taruh di prompt box, bukan di keputusan teknis. Gue jadi operator prompt, bukan engineer. Lo nulis 1 prompt, tunggu, baca, nulis prompt lagi, tunggu, baca. That's a loop - tapi lo yang jadi loop-nya, bukan agent.

Terus gue baca quote Boris Cherny (Head of Claude Code di Anthropic): "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." Satu kalimat itu yang ngeubah cara gue mikir. Lo gak harus nge-prompt agent. Lo harus design sistem yang nge-prompt agent. Itu loop engineering.

Artikel ini bukan tutorial "cara pake loop-engineering CLI." Ini filosofi kenapa mindset-nya beda, apa bedanya sama prompt engineering yang selama ini kita pake, dan kenapa gue pikir ini bukan hype - ini evolusi yang sebenernya udah lama datang.

---

Prompt Engineering Itu Masih Manual Labor

Prompt engineering = seni nulis instruction buat LLM biar output-nya sesuai harapan. Lo craft prompt yang detail, kasih context, kasih contoh, kasih constraint. Makin bagus prompt-nya, makin bagus output-nya.

Itu skill yang valid. Gue masih pake tiap hari - nulis system prompt buat blog ini, ngasih instruction ke Claude buat nulis artikel dengan voice MSNCode. Tapi prompt engineering punya limit fundamental: lo harus nge-prompt manual tiap kali lo mau sesuatu dilakuin.

Bayangin lo punya 5 PR yang butuh review. Approach prompt engineering: buka Claude, prompt buat PR pertama, tunggu, baca, prompt buat PR kedua, tunggu, baca, dst. 5x manual labor. Lo gak scale. Lo jadi bottleneck.

Loop engineering jawab: kenapa lo yang nge-prompt? Kenapa gak design sistem yang nge-prompt agent tiap ada PR baru, jalanin review, kasih report ke lo, dan lo cuma baca hasilnya?

Filosofi yang berubah: dari "gue yang nge-prompt agent" ke "gue yang design loop yang nge-prompt agent." Lo naik 1 level abstraksi. Lo gak ngoding prompt, lo ngoding sistem yang ngoding prompt.

---

Apa Itu Loop Engineering Sebenernya

Cobus Greyling (yang nge-populerin term-nya lewat repo GitHub) nge-definisinya kayak gini: loop engineering = design sistem yang schedule, triage, dan orchestrate AI agent di cadence tertentu, dengan state yang persistent di luar conversation, dan human gate buat hal yang risky.

Inti filosofinya: agent itu stateless. Lo harus nyediain state. Kalau lo chat sama Claude Code, dia lupa context 1 jam lalu. Loop engineering nyediain "memory spine" - file STATE.md, LOOP.md, run logs - yang agent baca tiap loop jalan.

Bayangin analogi: prompt engineering itu kayak gue ngasih instruksi ke asisten setiap kali gue mau sesuatu dilakuin. "Tolong review PR ini." "Tolong fix bug ini." Tiap kali, dari awal. Loop engineering itu kayak gue nulis SOP yang asisten jalanin otomatis tiap jam: "cek PR baru, kalau ada, review, report ke Slack. Kalau gak ada, tidur."

5 building blocks yang bikin loop engineering jalan (dari repo Cobus):

1. Automations / Scheduling - kapan loop jalan. Tiap jam? Tiap hari? Tiap ada PR baru? Cron job, GitHub Actions, systemd timer. Tanpa scheduling, lo balik jadi operator manual.

2. Worktrees - eksekusi paralel yang aman. Kalau agent mau nulis code, dia kerjain di git worktree terisolasi. Gak ganggu branch utama. Kalau gagal, buang worktree-nya. Kalau sukses, merge.

3. Skills - knowledge yang persistent. Project context, codebase convention, hal-hal yang biasa lo taruh di CLAUDE.md atau AGENTS.md. Agent baca ini tiap loop, jadi gak harus di-remind.

4. Plugins & Connectors (MCP) - jangkau ke tools lo yang asli. GitHub, Slack, Jira, database. Lewat MCP (Model Context Protocol), agent bisa baca issue, bikin PR, kirim message. Tanpa ini, loop cuma bisa "baca file lokal, nulis file lokal."

5. Sub-agents - maker/checker split. Satu agent nulis code, agent lain verify. Kenapa? Karena agent yang nulis code gak objective nge-review code-nya sendiri. Maker nulis, checker verify, baru hasilnya ke human gate.

Plus Memory / State - tulang punggung di luar conversation. STATE.md yang nyatet: "PR #45 udah di-review, ada 2 bug, fix di worktree X, menunggu human approval." Agent baca ini tiap loop, jadi tau apa yang udah dilakuin, apa yang pending. Tanpa state, tiap loop mulai dari nol.

---

Anatomi Satu Loop

Gue gambarin alur satu loop yang jalan (kayak yang ada di README repo Cobus):

[Schedule] → [Triage Skill] → [Read/Write STATE] → [Worktree isolated]
→ [Implementer agent] → [Verifier agent (tests + gates)]
→ [MCP/Git/Tickets] → [Human Gate?]
→ safe/allowlisted → [Commit/PR]
→ risky/ambiguous → [Escalate ke human, dengan full context]
→ balik ke [Schedule]

Gue jelasin per step:

Schedule jalan (misal tiap 15 menit). Loop baca GitHub: ada PR baru? Ada CI fail? Ada issue yang di-label bug?

Triage Skill nentuin: mana yang prioritas? Mana yang bisa di-auto-fix? Mana yang musti escalate? Skill ini persistent - lo sekali nulis rules-nya, dipake tiap loop.

Read STATE: agent baca STATE.md - "PR #45 udah di-review, PR #46 belum. CI fail di PR #44, penyebabnya dependency conflict." Agent tau konteks tanpa lo kasih tau.

Worktree isolated: agent bikin git worktree baru buat kerja. Gak ganggu main branch. Kalau gagal, rm -rf worktree-nya.

Implementer agent nulis code: fix bug, tambah test, apapun yang triage tentuin.

Verifier agent jalanin test, lint, type check. Kalau fail, balik ke implementer. Kalau pass, lanjut.

MCP/Git/Tickets: agent commit ke worktree, bikin PR, update issue status. Lewat MCP connector, bukan manual.

Human Gate: kalau perubahan safe dan di-allowlist (misal: docs update, dependency patch), auto-merge. Kalau risky atau ambiguous, escalate ke human dengan full context - "loop nemu bug X di PR Y, fix udah di worktree Z, tests pass, tapi melibatin payment logic, butuh review lo."

---

7 Pola yang Udah Di-Production-kan

Repo Cobus nge-list 7 pattern yang udah dipake orang beneran:

| Pattern | Cadence | Level | Token cost |
|---|---|---|---|
| Daily Triage | 1 hari | L1 report | Low |
| PR Babysitter | 5-15 menit | L1 watch | High |
| CI Sweeper | 5-15 menit | L2 cautious | Very high |
| Dependency Sweeper | 6 jam-1 hari | L2 patch-only | Medium |
| Changelog Drafter | 1 hari atau tag | L1 draft | Low |
| Post-Merge Cleanup | 1 hari-6 jam | L1 off-peak | Low |
| Issue Triage | 2 jam-1 hari | L1 propose-only | Low |

Yang gue pribadi tertarik: Daily Triage dan PR Babysitter. Daily Triage = tiap pagi, agent scan repo, report: "ada 3 issue baru, 2 PR pending review, 1 CI fail." Lo baca report sambil ngopi, bukan scroll GitHub manual. PR Babysitter = tiap 15 menit, agent cek PR yang lagi open, kalau ada conflict atau CI fail, alert lo. Lo gak harus monitor terus.

Level L1/L2/L3 itu penting. L1 = report doang, gak nge-fix. L2 = assisted fix, tapi human approval sebelum merge. L3 = unattended, auto-merge. Filosofinya: mulai dari L1, baru naik ke L2/L3 kalau udah percaya. Jangan langsung L3. Itu recipe buat disaster.

---

Perbandingan: Prompt Engineering vs Loop Engineering

Ini pertanyaan yang lo semua tunggu. Mana yang lebih baik?

Jawaban gue: bukan "mana lebih baik." Mereka beda layer. Prompt engineering itu skill level individu - gimana lo ngomong sama agent. Loop engineering itu skill level sistem - gimana lo design infrastruktur yang ngomong sama agent.

| Aspek | Prompt Engineering | Loop Engineering |
|---|---|---|
| Layer | Individual - lo vs agent | Sistem - loop vs agent |
| Manual labor | Tinggi - lo prompt tiap kali | Rendah - lo design sekali, loop jalan |
| Scalability | Linear dengan usaha lo | Exponential - 1 loop jalan 1000x |
| State | Stateless - tiap prompt baru | Stateful - STATE.md, run logs |
| Verification | Lo baca output manual | Sub-agent verify + human gate |
| Context | Lo kasih tiap prompt | Skills + MCP provide otomatis |
| Cost | Token per prompt | Token per loop (bisa explode kalau gak di-budget) |
| Use case | One-off, exploratory, creative | Repetitive, scheduled, monitoring |
| Failure mode | Output jelek | Comprehension debt (lo gak baca apa yang loop ship) |
| Skill yang dibutuhin | Nulis instruction yang jelas | Design sistem: scheduling, state, gates |

Filosofi yang gue pegang: prompt engineering itu skill dasar, loop engineering itu skill lanjutan. Lo gak bisa design loop yang bagus kalau lo gak bisa nulis prompt yang bagus. Tapi lo gak akan scale kalau lo cuma nulis prompt. Naik level: prompt yang bagus → loop yang bagus.

---

Kapan Lo Pakai Loop, Kapan Tetap Prompt

Pakai prompt engineering kalau:

• Task-nya one-off. "Tolong bantu gue debug error ini." Gak perlu loop, cukup prompt sekali.
• Task-nya kreatif. "Tulis artikel tentang X." Loop gak ngebantu, justru ngganggu - kreativitas butuh dialog.
• Lo lagi eksplorasi. "Coba pake library X, gimana hasilnya?" Lo butuh interaksi real-time, bukan scheduled loop.
• Task-nya kompleks tapi sekali jalan. "Refactor module ini jadi microservices." Satu sesi panjang, bukan loop berulang.

Pakai loop engineering kalau:

• Task-nya repetitive. "Review tiap PR baru." "Fix tiap CI fail." "Update dependency tiap hari."
• Task-nya predictable. Lo tau input-nya (PR baru, CI fail), tau output yang diharap (review report, fix PR).
• Lo pengen scale. 5 PR review manual = 5x waktu lo. 1 loop = 0 waktu lo, cuma baca report.
• Task-nya low-risk kalau di-automate (L1). "Report aja, jangan fix." Kalau L2/L3, baru hati-hati.

Gue pribadi: 70% prompt engineering, 30% loop engineering. Yang repetitive (monitoring, triage) → loop. Yang kreatif (nulis artikel, design sistem) → prompt. Lo gak harus 100% salah satu. Lo pilih tool sesuai masalah.

---

Yang Gue Pelajarin Dari Nyoba

1. Token cost bisa meledak. Sub-agent + long-running loop = token burn. Gue pernah setup PR Babysitter yang jalan tiap 5 menit. 1 hari = 288 loop. Tiap loop baca PR + context = 5000 token. 288 × 5000 = 1.4 juta token sehari. Kalau pake Claude Sonnet, itu $4-5/hari cuma buat monitor PR. Bikin loop-cost estimator sebelum commit.

2. Comprehension debt itu nyata. Loop jalan, nge-fix bug, nge-merge PR. Lo gak baca semuanya. 1 bulan kemudian, codebase lo berubah tanpa lo paham kenapa. Comprehension debt grows faster than code debt. Aturan gue: tiap loop yang L2/L3 musti generate summary yang human baca. Kalau gak, loop itu jadi black box.

3. Verification tetap tanggung jawab lo. Loop bikin PR, tests pass, auto-merge. Tapi "tests pass" bukan berarti "code bener." Tests bisa gak nge-cover edge case. Logic bisa salah walau test green. L3 unattended itu bahaya kalau lo gak punya test suite yang solid. Mulai L1, baru L2, baru L3.

4. State itu yang bikin loop powerful. Tanpa STATE.md, tiap loop mulai dari nol. Dengan state, loop tau: "PR #45 udah di-review kemarin, skip. PR #46 baru, review." State = memory. Memory = konteks. Konteks = output yang lebih bagus.

5. Loop gak tau konteks bisnis. Loop bisa fix bug teknis, tapi gak tau "fitur ini di-deprioritize sama produk." Human gate tetap penting buat keputusan yang butuh konteks bisnis.

---

Yang Sering Disalahpahami

"Loop engineering = gak perlu prompt engineering." - Salah. Lo tetep harus nulis prompt yang bagus - tapi prompt-nya masuk ke skill/triage rules, bukan ke chat box. Skill yang bagus = loop yang bagus. Lo naik level, bukan ganti level.

"Loop engineering = auto-pilot." - Bahaya. Loop yang L3 unattended tanpa verification = recipe disaster. Quote Addy Osmani: "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."

"Loop engineering cuma buat tim gede." - Enggak. Solo dev yang punya 3 repo pun bisa pake Daily Triage. Token cost-nya rendah (L1 report doang). Yang penting: mulai dari yang kecil.

"Loop engineering ganti kerjaan dev." - Tidak. Loop ngurangin manual labor (monitoring, triage), tapi keputusan tetap human. Lo jadi architect yang design sistem, bukan operator yang jalanin sistem.

---

Penutup yang Jujur

Gue gak akan bilang "prompt engineering mati." Enggak. Prompt engineering masih skill fundamental. Tapi loop engineering itu evolusi yang sebenernya udah lama datang. Pas gue sadar 2 jam gue habis buat nge-prompt agent buat review PR, sedangkan gue bisa design 1 loop yang nge-prompt agent tiap 15 menit dan gue cuma baca report - itu momen "ah, gitu toh."

Filosofi yang gue bawa sekarang: lo gak harus jadi operator prompt. Lo bisa jadi designer loop. Naik 1 level abstraksi. Dari "gue yang nulis prompt" ke "gue yang design sistem yang nulis prompt." Itu bedanya engineer yang scale sama engineer yang stuck.

Kalau lo mau cobain, mulai dari yang kecil. Clone repo Cobus, jalanin npx @cobusgreyling/loop-init . --pattern daily-triage --tool claude. Setup L1 report dulu - tiap pagi, agent scan repo, report ke lo. Gak nge-fix apa-apa, cuma report. Kalau itu udah berguna, naik ke L2. Kalau L2 udah stable, naik ke L3. Tapi jangan langsung L3. Loop yang unattended tanpa verification = bom waktu.

Boris Cherny bilang: "My job is to write loops." Gue setuju. Tapi tambahan gue: job lo bukan cuma nulis loop, tapi juga baca apa yang loop ship. Loop tanpa human comprehension = comprehension debt yang numpuk. Loop dengan human review = sistem yang scale. Pilih yang kedua.