{"slug": "stop-prompting-start-looping", "title": "Stop Prompting, Start Looping", "summary": "Loop engineering, a term coined by Addy Osmani in June 2026, is replacing prompt engineering as the dominant paradigm for coding agents, shifting focus from prompting models to designing autonomous loops that prompt models. Boris Cherny of Anthropic's Claude Code confirmed he no longer prompts Claude directly but uses loops, while a June 2026 paper, The Verification Horizon, argues that verifying solutions has become harder than producing them. The practice centers on five components: a skill definition, a verifier, state, a guardrail, and a human-in-the-loop, with verification and context management identified as the hardest challenges.", "body_md": "The way people talk about coding agents changed this summer. In June 2026, Addy Osmani gave\nthe shift a name: **loop engineering**.\n\nLoop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.\n\nHe was not alone. Boris Cherny, who leads Claude Code at Anthropic, said the quiet part out loud: \"I don't prompt Claude anymore. I have loops running that prompt Claude.\" Peter Steinberger framed it as advice: stop prompting coding agents, start designing the loops that prompt them.\n\nPrompt engineering got us a good first turn. Loop engineering is about the tenth turn, and the hundredth, without the whole thing drifting off course. Here is what the practice actually involves.\n\n## An agent is a loop\n\nThe agent is not the model. It is the loop around the model: watch the state, take an action, check the result, repeat, until the goal is met or a human is needed. Put plainly, a loop finds work, hands it to the model, checks the result against a real signal, and decides whether to go again, without you in the chair for each step. That shape is not new. What changed in 2026 is that the loop, not the prompt, became the unit of work you design.\n\nTwo things decide whether a loop survives a long run: whether it can tell done from not-done, and whether it can stay oriented over many turns. Get those right and the rest is a parts list.\n\n## Verification is the hard part\n\nThe old assumption was that checking an answer is easier than producing one. For coding\nagents, that has flipped. A June 2026 paper, *The Verification Horizon*, argues that \"reliably\nverifying [solutions] has become the harder problem,\" and that verification has to co-evolve\nwith the model writing the code. Osmani says it plainer: \"The model that wrote the code is way\ntoo nice grading its own homework.\"\n\nSo a loop needs a source of truth that is not the model's own opinion: a diff, a passing test suite, or a second agent whose only job is to review the first. Cherny's bar for \"done\" is not a green unit test, it is \"can the agent run the thing?\" Whatever you build on, get this part right first. A board like Lanes, for instance, can start a second session purely to review the first one's diff, but the principle holds anywhere.\n\nThe verifier is the whole game. Skip it and you do not have a loop, you have an agent agreeing with itself on repeat. It also sets how much rope to give the loop: when the model judges its own \"done\", as a self-paced loop does, keep the stakes low and the signal objective; when a wrong \"done\" is expensive, gate on an independent check, a separate evaluator or a second agent that never saw the first one's reasoning.\n\n## Context is the other hard part\n\nA loop that runs for an hour fills the model's window with its own history and slowly forgets what it was doing. Cat Wu, who leads product for Claude Code, calls herself \"a context minimalist\": tell the model only what it needs. In practice that means giving each unit of work a clean, separate context instead of one ever-growing conversation, and keeping whatever runs the loop lean. Isolated worktrees, or a fresh session per task, are how you buy that.\n\n## The anatomy of a loop\n\nOsmani's parts list resolves to five moving pieces. The first three are what a loop is; the last two are what keep it from hurting you.\n\n**A skill, the definition.** The instructions the loop runs each pass, written down so they persist and improve instead of living in your head: a prompt template or a`SKILL.md`\n\n. In Lanes this is the loop prompt you paste, or the`lanes-sessions`\n\nskill that teaches the tool surface once.**A verifier, the whole game.** A check the model cannot talk its way past: a diff, a passing test suite, a build, a linter, or a second agent whose only job is to review. Everything else hangs on this one. In Lanes it is the per-issue diff from`lanes_get_issue_changes`\n\nplus a real test run, or a second session that reviews the first.**State, the loop's memory.** Data that survives between iterations so progress compounds instead of starting cold, kept in durable storage rather than a chat window. In Lanes the board is that shared state: issues and columns any run can read and advance, with each issue's worktree keeping its slice of the work isolated.**Guardrails.** The allowed and disallowed tools that bound what the agent may touch, and a human sign-off on anything irreversible. In Lanes the local MCP server is the connector that wires in exactly those tools, and the`review`\n\ncolumn is where a person signs off before anything ships.**Hard stops.** A max-iteration cap, a budget, and a wall-clock timeout, with a terminal status as the natural third brake. Never write a loop whose only exit is success.\n\nWiring those together by hand is real work, and state is the piece most people skip. Some tools bundle it: in Lanes the board is the state, each issue runs in its own worktree, and the MCP server is the connector, which is why the examples below use it. The five parts are the same whatever you assemble.\n\n## What it looks like in practice\n\nHere are four loops, each one prompt away. They drive Lanes over its MCP server, but the moves translate to any harness that can start a task and report its status.\n\nThe whole thing hangs on one signal: a task's status. The rule is short. A run is done, or needs you, when it is waiting on input, has exited, or has stopped. Anything else means keep waiting. Watch that cheap status signal, not the raw terminal in a tight loop.\n\n**Wait until done.** The basic block.\n\n```\nStart a session on Lanes issue 12, keep an eye on it, and ping me the moment it needs input\nor finishes.\n```\n\n**The babysitter.** Watch a whole fleet on a cadence.\n\n```\n/loop 5m Check my running Lanes sessions. For any waiting on input or errored, tell me in one\nline what it needs. Stop when nothing is left running.\n```\n\n**Fix until green.** Loop against a real signal, capped so it cannot spin.\n\n```\nWork Lanes issue 20 until the tests pass. When the session goes idle, run the suite; if it is\nred, feed the failures back and let it try again, up to three times.\n```\n\n**Run the whole backlog.** The loop that earns the name: one session per issue, one PR each.\n\n```\nGo through every issue in my Lanes backlog. Give each one its own worktree, start a session\nto implement it, and wait for it to finish before starting the next. Have each session open a\npull request when it is done, move that issue to review, and give me the list of PRs at the\nend.\n```\n\n## A feature, one Linear issue at a time\n\nThe backlog drain above is the shape. Here it is end to end, with the verification step and\nthe three ways a run can end made explicit. You have split a feature into a handful of Linear\nissues and tagged them `ready-for-agent`\n\n; the Linear integration mirrors them onto the board.\nFrom there the loop runs without you.\n\nIt takes the top ready issue, gives it its own worktree, and starts a session with the\nfeature's instructions. It watches the status, and the moment the session goes idle it\nverifies: it reads the diff and runs the tests. Red, and it feeds the failures back and lets\nthe session try again, up to a cap. Green, with a real diff, and it opens a pull request and\nmoves the issue to `review`\n\n, then picks up the next one. The board is what makes this compound:\nit holds what is done and what is left, so the loop never repeats itself or loses its place.\n\nEvery run ends one of three ways, and the loop treats each differently: ready for review when\nthe conditions are met, needs a human when the session is `awaiting_input`\n\n, or a hard stop when\nit hits the iteration cap or the budget. Only the first advances on its own. When every issue\nin the feature is sitting in `review`\n\nwith green checks and an open PR, the loop's success\ncondition is met: it stops and hands the batch back to you. You review and merge, and a\nseparate release loop takes it from there, promoting merged work to production once the release\nchecks pass.\n\n```\nWork my Linear feature: take each issue tagged ready-for-agent in order, give it its own\nworktree, and start a session to implement it. When a session goes idle, read\nlanes_get_issue_changes and run the tests. If they fail, resume the session with the failures\npasted in, up to three times. When they pass with a real diff, open a PR and move the issue to\nreview. Do not merge anything. Stop after 45 minutes or once every issue is in review, then\ngive me the list of PRs.\n```\n\nThe diagram is that loop end to end: the implementation loop draining the backlog, the human gate in the middle, and the release loop that ships what you approve.\n\n## Guardrails in practice\n\nEveryone who wrote about loop engineering spent as much time on stopping as on running. Osmani's line is the one to keep in view: \"A loop running unattended is also a loop making mistakes unattended.\" The anatomy above names the brakes; here is how to set them.\n\n**Match the brakes to where it runs.** A loop you babysit at the keyboard can lean on a short interval and your own eyes. A loop you leave closer to unattended needs a hard budget and a wall-clock timeout before you walk away, because nobody else is watching the spend or the blast radius.**Verify before you advance,** ideally with a second agent as the checker. Gate progress on a diff and a real test run, not on the model declaring victory.**Keep the human checkpoint honest.** The reason control comes back at`awaiting_input`\n\n, and the reason the`review`\n\ncolumn exists, is that the agent that wrote the code is the wrong one to decide it is safe to ship. Leave that call to a person.\n\n## The takeaway\n\nPrompt engineering was about the words you send. Loop engineering is about the system that sends them, checks the result, and decides what to do next. Get verification and context right, give the loop a memory it can build on, and you can point it at a backlog overnight and read the results in the morning.\n\nIf you want to see the parts assembled, that is what Lanes is built for: it puts every agent\nsession on a board and exposes it over a [local MCP server](/docs/desktop/local-mcp), so a\nloop has real state to read and advance. The docs have a\n[step-by-step version of the loops above](/docs/desktop/loops).\n\n## References\n\n- Addy Osmani,\n*Loop Engineering*(Jun 7, 2026):[addyosmani.com/blog/loop-engineering](https://addyosmani.com/blog/loop-engineering/), also on[O'Reilly Radar](https://www.oreilly.com/radar/loop-engineering/)(Jun 22, 2026) - The Neuron,\n*Claude Code's Creators (Boris Cherny & Cat Wu) Explain Agent Loops*(Jun 9, 2026):[theneuron.ai](https://www.theneuron.ai/explainer-articles/claude-code-creators-boris-cherny-and-cat-wu-explain-how-to-use-agent-loops/) - Wang et al.,\n*The Verification Horizon: No Silver Bullet for Coding Agent Rewards*, arXiv (Jun 24, 2026):[arxiv.org/abs/2606.26300](https://arxiv.org/abs/2606.26300) - ADTmag,\n*Loop Engineering Emerges as Developers Put AI Coding Agents on Repeat*(Jul 1, 2026):[adtmag.com](https://adtmag.com/articles/2026/07/01/loop-engineering-emerges-as-developers-put-ai-coding-agents-on-repeat.aspx) - VibeReady,\n*Loop Engineering in Claude Code*(2026):[vibeready.sh](https://vibeready.sh/blog/loop-engineering-claude-code/)", "url": "https://wpnews.pro/news/stop-prompting-start-looping", "canonical_source": "https://lanes.sh/blog/loop-engineering-with-lanes", "published_at": "2026-07-23 16:07:27+00:00", "updated_at": "2026-07-23 16:22:46.598001+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-research", "developer-tools"], "entities": ["Addy Osmani", "Boris Cherny", "Anthropic", "Claude Code", "Peter Steinberger", "Cat Wu", "Lanes", "The Verification Horizon"], "alternates": {"html": "https://wpnews.pro/news/stop-prompting-start-looping", "markdown": "https://wpnews.pro/news/stop-prompting-start-looping.md", "text": "https://wpnews.pro/news/stop-prompting-start-looping.txt", "jsonld": "https://wpnews.pro/news/stop-prompting-start-looping.jsonld"}}