Series: AI Agent 實戰 (2/3)
- Stop prompting agents; build systems that prompt them. Prompts become one component of a self-running loop, not the job.
- Verification cost, not loop complexity, decides what you can automate. Machine-checkable success conditions are the real prerequisite.
- Never let the agent that did the work judge whether it's done; early exit needs a separate verifier.
Table of Contents
Boris Cherny runs hundreds of agents during the day and thousands overnight.
Not because he’s prompting harder — he says he’s stopped manually prompting Claude at all. He’s designing systems that prompt agents. That shift is Loop Engineering.
TL;DR
Loop Engineering is “designing the system that prompts agents,” not the practice of prompting them better. The core insight: verification cost — not loop complexity — decides what you can automate.
Four Abstraction Jumps
From 2023 to 2026, the core skill in AI development jumped one abstraction level per year:
| Year | Core Skill | Developer Role |
|---|---|---|
| 2023 | Prompt Engineering | Write precise prompts for good outputs |
| 2024 | Agent Orchestration | Coordinate multiple agents on complex tasks |
| 2025 | Harness Engineering | Configure the agent’s environment via CLAUDE.md, hooks |
| 2026 | Loop Engineering | Design self-running feedback loops for autonomous agents |
Each layer doesn’t replace the one below — it pushes it down into infrastructure. You still write prompts. Prompts are just a component of the loop now, not the job itself.
Three People, One Week
In June 2026, three separate statements converged inside a week and triggered a recognition moment in the developer community.
Boris Cherny (head of Claude Code) described his evolution on the Acquired Unplugged podcast: IDE → prompt Claude → 5–10 parallel sessions → uninstalled IDE in November 2024 → hundreds of agents during the day, thousands overnight. He no longer manually prompts Claude. The loop runs itself.
Peter Steinberger (founder of OpenClaw) tweeted: stop directly prompting agents, design the system that prompts agents instead.
Addy Osmani (engineering lead, Google Chrome) followed with the clearest definition:
“Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”
He positions loop one layer above harness: “Harness configures the environment — but a loop has timers, spawns helpers, and can feed itself.”
Basic Loop Structure
Discover work → Dispatch to agent → Agent executes → Observe output
→ Verify correctness → Record state → Decide next step → RepeatA prompt is a one-shot trigger. A loop is a continuously self-driving system.
The practical difference: prompts consume your attention, loops consume token budget. Attention is scarce; tokens can be bought.
Five Building Blocks + Memory
Osmani breaks a complete loop into five components plus a memory layer. He notes that Claude Code and OpenAI Codex now ship with all five: “the shape is the same across products.”
Scheduled Automations — The loop’s entry point: cron jobs, GitHub Actions webhooks, or tool-native scheduling. Osmani cites real internal use at OpenAI: daily issue triage, CI failure summaries, commit briefings, weekly bug searches.
Git Worktrees — Each agent works in an isolated worktree, sharing git history without conflicts. This is what lets multiple agents run in parallel — one fixing a bug, one writing tests, one refactoring — while you sleep.
Skills — Project knowledge encoded in CLAUDE.md, AGENTS.md, and skill files. Osmani’s framing: “An agent starts every session cold and will fill any hole in your intent with a confident guess. A skill is intent written down.” Without skills, agents re-derive your conventions every time.
Plugins / MCP Connectors — External integrations via MCP (Model Context Protocol): GitHub, Slack, databases, monitoring systems. This layer defines the boundary of what agents can sense and act on.
Sub-agents (Maker-Checker Split) — Executor and verifier are separate. This is the most critical design decision. Osmani: “The reason it matters specifically inside a loop is the loop runs while you are not watching, so a verifier you actually trust is the only reason you can walk away.” Claude Code’s /goal implements this — a separate model judges completion, not the agent that did the work.
Durable Memory — Agents are amnesiac; the filesystem isn’t. Files like progress.txt, AGENTS.md, and prd.json carry state across sessions. This is what lets a loop remember where it left off.
Verification Cost Is the Real Bottleneck
Blake Crosley’s analysis cuts to the real constraint:
“Verification cost, not loop construction, decides what you can automate.”
Every successful loop Cherny has named has machine-checkable success conditions — CI fixes, auto-rebasing, feedback clustering — not open-ended feature work.
The logic is clean:
- Verification is automatable (test suite passes, lint clean, type check clear) → loop can run indefinitely
- Verification requires human judgment (does this UI look good, is this architecture decision right) → loop degrades to “produces a pile of things for you to review”
Four conditions for a loop worth running:
- Task is repeatable — not a one-off exploration
- Verification is automatable — test suite, linter, type checker exists
- Token budget absorbs waste — loops retry, explore dead ends
- Agent has the tools it needs — no human required to operate external systems
Miss any one of these and the loop’s cost exceeds its benefit. This isn’t a limitation of Loop Engineering — it’s a sharp filter you can run over any incoming requirement.
Known Limitations
Token cost is real. Loops re-read context, retry, explore multiple paths. Osmani: “usage patterns can vary wildly if you are token rich or poor.”
Comprehension debt is subtler than technical debt. The gap between what exists in your codebase and what you actually understand. With tech debt you at least know what you owe; with comprehension debt you don’t know what you don’t know.
Cognitive surrender is the trap: “When the loop runs itself it’s very tempting to stop having an opinion and just take whatever it gives back.” A loop accelerates work you already understand. It’s poison for work you’re trying to avoid understanding.
Early exit happens when agents declare completion prematurely. This is exactly why maker-checker isn’t optional — the agent that did the work cannot be trusted to evaluate whether it’s done.
Review becomes the new bottleneck. Your throughput isn’t capped by token budget; it’s capped by how fast you can inspect output. Loop Engineering shifts the scarce resource from execution to judgment.
Three Things to Start Today
Write your conventions into CLAUDE.md / AGENTS.md. “We don’t do it this way because of what happened last time” — that knowledge written down is a skill. Without it, every agent session starts with guessing.
Run your first loop with a clear verification condition. Start small: babysit one PR, run lint check hourly. The loop size doesn’t matter. What matters is that “done” is machine-checkable — “CI passes” beats “looks good.”
Always use a separate agent to verify. Never let the agent that did the work evaluate whether it’s finished. This single rule prevents early exit and forces you to define completion criteria before the loop starts.
Bottom Line
Osmani’s closing line is worth keeping:
“Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.”
The loop does the typing. The thinking is still your job.
References
Answers come from this article only. Click any prompt below or open the chat at the bottom right.
🇺🇸 English
Boris Cherny runs hundreds of agents during the day and thousands overnight. Not because he's prompting harder — he says he's stopped manually prompting Claude at all. He designs systems that do the prompting for him. That shift has a name now: Loop Engineering.
And in the span of one week in June 2026, three people independently said essentially the same thing. Cherny described it on a podcast. Peter Steinberger tweeted it. And Addy Osmani, engineering lead at Google Chrome, gave it the cleanest definition: Loop Engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
That's the whole idea. But let's unpack why it matters.
---
Over the past few years, the core skill in AI development has jumped one abstraction level per year. In 2023, it was prompt engineering — write a precise prompt, get a good output. In 2024, it was agent orchestration — coordinate multiple agents across complex tasks. In 2025, it was harness engineering — configure the agent's environment, set up your CLAUDE.md files, wire up hooks. And now in 2026, it's Loop Engineering — design a self-running feedback loop so agents work without you watching.
Each layer doesn't replace the one below. It pushes it down into infrastructure. You still write prompts. Prompts are just a component of the loop now, not the job itself.
The practical difference between a prompt and a loop is this: a prompt is a one-shot trigger. A loop is a continuously self-driving system. Prompts consume your attention. Loops consume token budget. Attention is scarce. Tokens can be bought.
---
So what does a loop actually look like?
Think of it as a cycle: discover work, dispatch it to an agent, let the agent execute, observe the output, verify whether it's correct, record the state, decide what to do next — and repeat. That's it. That's the loop. The question is what makes one loop robust and another a disaster.
Osmani breaks a complete loop into five building blocks, plus a memory layer. And he notes that Claude Code and OpenAI Codex now ship with all five — the shape is the same across products.
First, scheduled automations. This is the loop's entry point — cron jobs, GitHub Actions webhooks, or tool-native scheduling. Real examples from inside OpenAI: daily issue triage, CI failure summaries, commit briefings, weekly bug searches. The loop needs something to wake it up.
Second, git worktrees. Each agent works in its own isolated branch of the repo, sharing git history without conflicting with other agents. This is what lets you run multiple agents in parallel — one fixing a bug, one writing tests, one refactoring — while you sleep.
Third, skills. This is project knowledge encoded in your CLAUDE.md or AGENTS.md files. Osmani's framing is sharp here: "An agent starts every session cold and will fill any hole in your intent with a confident guess." A skill is intent written down. Without it, every agent session starts with guessing, and the guesses compound.
Fourth, plugins and connectors via MCP — the Model Context Protocol. This is how agents reach GitHub, Slack, databases, monitoring systems. It defines the boundary of what an agent can sense and act on.
Fifth — and this is the most critical — sub-agents with a maker-checker split. The executor and the verifier are separate agents. The one that did the work cannot be trusted to evaluate whether it's done. Osmani is direct about why: "The loop runs while you are not watching, so a verifier you actually trust is the only reason you can walk away." Claude Code's slash-goal command implements exactly this — a separate model judges completion, not the agent that produced the output.
And finally, durable memory. Agents are amnesiac; the filesystem isn't. Files like progress.txt and your PRD carry state across sessions. This is what lets a loop remember where it left off when it wakes up tomorrow.
---
Now here's where the analysis gets genuinely useful.
Blake Crosley cuts to the real constraint: verification cost, not loop construction, decides what you can automate. And when you look at every loop Cherny has described — fixing CI failures, auto-rebasing, clustering user feedback — they all share one property: machine-checkable success conditions.
The logic is clean. If verification is automatable — test suite passes, lint is clean, type check clears — the loop can run indefinitely. If verification requires human judgment — does this UI look good, is this architecture decision right — the loop degrades into a pile of things you still have to review.
So before you build a loop, run this filter. Is the task repeatable, or is it a one-off exploration? Is "done" machine-checkable, or does it require your eyes? Can the token budget absorb retries and dead ends? Does the agent have all the tools it needs without requiring a human to operate external systems? Miss any one of these and the loop costs more than it saves.
---
There are real failure modes worth naming.
Token cost is real. Loops re-read context, retry, explore multiple paths. Usage can vary wildly.
Comprehension debt is subtler. Tech debt you at least know you owe. Comprehension debt — the gap between what exists in your codebase and what you actually understand — you don't know what you don't know. A loop running while you're not paying attention widens that gap fast.
And cognitive surrender is the trap Osmani names explicitly. When the loop runs itself, it's tempting to stop having an opinion and just take whatever it gives back. A loop accelerates work you already understand. It's poison for work you're trying to avoid understanding.
---
If you want to start today, three moves:
Write your conventions into CLAUDE.md or AGENTS.md. The "we don't do it this way because of what happened last time" knowledge — written down, that's a skill. Without it, agents guess.
Run your first loop with a clear verification condition. Start small. Babysit one PR. Run lint hourly. The loop size doesn't matter. What matters is that "done" is machine-checkable. "CI passes" beats "looks good."
Always use a separate agent to verify. Never let the agent that did the work decide if it's finished. This single rule prevents early exit and forces you to define completion criteria before the loop starts.
---
Osmani's closing line is worth keeping: "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."
The loop does the typing. The thinking is still yours.
🇹🇼 中文
Boris Cherny 白天跑數百個 agent，晚上跑數千個。他說他已經不手動 prompt Claude 了——他在設計系統，讓系統去 prompt agent。這個轉變，有個名字叫 Loop Engineering。
從 2023 到 2026，AI 開發的核心技能每年跳一個抽象層。2023 年你在學怎麼寫出好的 prompt。2024 年你在學怎麼讓多個 agent 協作。2025 年你在用 CLAUDE.md、hooks 這類設定檔配置 agent 的工作環境。2026 年，你在設計自動運行的回饋迴圈，讓 agent 自主持續工作。每一層都不取代上一層，而是把它往下壓成基礎設施。你現在還是需要寫 prompt，只是 prompt 現在是 loop 的一個零件，而不是工作本身。
這個概念是怎麼浮出來的？2026 年 6 月，三個人在同一週說了幾乎同一件事。Cherny 在訪談裡描述了他的演進：用 IDE 寫程式碼、然後提示 Claude 寫程式碼、然後同時跑 5 到 10 個 session，到了 2024 年 11 月乾脆卸載了 IDE，現在讓迴圈自動運行。Peter Steinberger 發推說，停止直接 prompt agent，改為設計 prompt agent 的迴圈系統。然後 Addy Osmani 給了最清楚的定義：「Loop engineering 是把你這個『下 prompt 的人』換掉，改用你設計的系統來做這件事。」
那一個完整的 loop 長什麼樣？可以想成一個持續自我驅動的循環：發現工作、分派給 agent、agent 執行、觀察結果、驗證正確性、記錄狀態、決定下一步、然後重複。Prompt 是一次性的觸發。Loop 是持續自我驅動的系統。這個差別在實踐上是根本的：prompt 消耗你的注意力，loop 消耗 token 預算。注意力稀缺，token 可以買。
Osmani 把一個完整 loop 拆成五個組件。
第一個是排程觸發——loop 的起點。可以是定時任務、GitHub Actions 的 push 事件，或工具內建的排程機制。他舉了 OpenAI 內部的實際用法：每日 issue triage、彙整 CI 失敗、寫 commit briefing、搜尋上週新增的 bug。觸發器決定 loop 的節奏，你選擇觸發器，等於選擇你願意花多少 token 換多少即時性。
第二個是 git worktree 隔離。每個 agent 在獨立的工作區中運行，共享 git 歷史但互不干擾。這讓多個 agent 能同時處理不同任務——一個修 bug、一個寫測試、一個做 refactor——而不產生衝突。沒有這層隔離，平行 agent 早晚踩到彼此的變更。
第三個是 skills，也就是專案知識。透過 CLAUDE.md、AGENTS.md 這類檔案，把你的專案規範、慣例、工作流程寫成 agent 可以讀的知識。有個說法叫 intent debt——「agent 每次啟動都是冷啟動，你意圖裡的任何空白，它都會用一個有信心的猜測來填補。skill 就是把意圖寫下來。」沒有 skills，agent 每次都在猜你的習慣；有了 skills，知識才會累積，agent 才會越跑越穩。
第四個是外部整合，透過 MCP 連接 GitHub、Slack、資料庫、監控系統。讓 agent 不只能讀寫程式碼，還能開 PR、留 comment、查 metrics、讀 alert。這層決定了 loop 能感知的邊界。
第五個，也是最關鍵的：maker-checker 分離。執行者和驗證者必須是不同的 agent。為什麼？因為 loop 在你不盯著的時候跑，所以一個你真正信任的驗證者，是你能走開的唯一原因。讓做事的 agent 自己判斷自己做完了，是 loop 最常見的失敗模式。
說到失敗模式——Blake Crosley 提出了一個最直接切到核心的洞見：「真正的瓶頸不是 loop 的複雜度，而是驗證成本。」
邏輯很清楚。如果驗證可以自動化——test suite 通過、lint 清潔、type check 無誤——loop 能無限運轉。如果驗證需要人類判斷——這個架構決定對不對、這個 UI 好不好看——loop 就只是「產出一堆東西等你 review」。
適合跑 loop 的任務，同時滿足四個條件：任務可重複、驗證可自動化、token 預算能承受重試和探索死路的浪費、agent 已有所需工具。缺一個，成本就會超過收益。這不是限制，這是非常清晰的適用邊界。
當然有批評。Token 成本是真實的——loop 重讀 context、重試、探索多條路徑，消耗遠超單次 prompt。更隱蔽的是「理解負債」：loop 產出的程式碼你沒寫、可能沒仔細 review、不完全理解。技術債你至少知道欠了什麼；理解負債是你連自己欠了什麼都不知道。Osmani 說得很直接：「當 loop 自己跑的時候，很誘人的事情是你停止有自己的判斷，直接接受它給你的。」用 loop 加速你深度理解的工作，它是利器；用它逃避理解，它是毒藥。
如果你今天想開始，三件事：第一，把你的隱性規範寫進 CLAUDE.md——「我們不這樣做因為上次出事了」，這種知識寫下來就是 skill。第二，從一個有清楚驗證條件的小任務開始跑第一個 loop——「CI 通過」比「程式碼看起來不錯」好得多。第三，永遠讓不同的 agent 來做驗證，不讓同一個 agent 自己評估自己的產出。
最後，Osmani 有句話值得留下來：「打造這個 loop，但要像一個打算繼續當工程師的人去打造它，而不是只負責按下 go 的人。」
三個核心要點帶走：Loop Engineering 的本質是把你的工程判斷力轉化為自動執行的系統，而不是讓你從工程師變成旁觀者。驗證成本才是真正的瓶頸，能自動驗證的任務才適合跑 loop。Maker-checker 分離不是選項，是必要條件——你不在場的時候，驗證者是唯一的品質防線。
Loop 會做打字的工作。思考還是你的工作。
Tags
Related Articles
Harness Engineering (2): Five Engineering Answers from OpenAI's Million-Line Experiment
Three OpenAI engineers, five months, one million lines of AI-generated code, zero hand-written. The real value of this experiment isn't the numbers — it's the proof that Harness design can be engineered. Five concrete practices: making the app legible to agents, treating the repo as the source of truth, mechanizing architectural constraints, rewriting merge philosophy, and background entropy management.
Harness Engineering (3): Industry Consensus, Four Pillars, and a Three-Phase Rollout
Distilling Harness Engineering from concept and benchmark case into something you can start executing today: the four fixed failure modes of Agents, the 40% context sweet spot, the four-pillar framework the industry has converged on, and a three-phase roadmap from 'this afternoon' to 'fully automated in two weeks' — closing with six industry consensus points and three still-unsolved problems.
Headroom: The Local Layer That Strips 90% of Your Context Before It Hits the LLM
Headroom compresses tool outputs, logs, and RAG chunks by 60–95% locally, before the request reaches your provider. The part worth stealing isn't the ratio — it's how it decides whether to compress at all using 'mask extraction + cache-mutation economics' — plus a reminder that its docs run ahead of its code.