The way people talk about coding agents changed this summer. In June 2026, Addy Osmani gave the shift a name: loop engineering.
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
He 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.
Prompt 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.
An agent is a loop #
The 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.
Two 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.
Verification is the hard part #
The old assumption was that checking an answer is easier than producing one. For coding agents, that has flipped. A June 2026 paper, The Verification Horizon, argues that "reliably verifying [solutions] has become the harder problem," and that verification has to co-evolve with the model writing the code. Osmani says it plainer: "The model that wrote the code is way too nice grading its own homework."
So 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.
The 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.
Context is the other hard part #
A 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.
The anatomy of a loop #
Osmani'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.
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 aSKILL.md
. In Lanes this is the loop prompt you paste, or thelanes-sessions
skill 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 fromlanes_get_issue_changes
plus 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 thereview
column 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.
Wiring 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.
What it looks like in practice #
Here 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.
The 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.
Wait until done. The basic block.
Start a session on Lanes issue 12, keep an eye on it, and ping me the moment it needs input
or finishes.
The babysitter. Watch a whole fleet on a cadence.
/loop 5m Check my running Lanes sessions. For any waiting on input or errored, tell me in one
line what it needs. Stop when nothing is left running.
Fix until green. Loop against a real signal, capped so it cannot spin.
Work Lanes issue 20 until the tests pass. When the session goes idle, run the suite; if it is
red, feed the failures back and let it try again, up to three times.
Run the whole backlog. The loop that earns the name: one session per issue, one PR each.
Go through every issue in my Lanes backlog. Give each one its own worktree, start a session
to implement it, and wait for it to finish before starting the next. Have each session open a
pull request when it is done, move that issue to review, and give me the list of PRs at the
end.
A feature, one Linear issue at a time #
The backlog drain above is the shape. Here it is end to end, with the verification step and
the three ways a run can end made explicit. You have split a feature into a handful of Linear
issues and tagged them ready-for-agent
; the Linear integration mirrors them onto the board. From there the loop runs without you.
It takes the top ready issue, gives it its own worktree, and starts a session with the
feature's instructions. It watches the status, and the moment the session goes idle it
verifies: it reads the diff and runs the tests. Red, and it feeds the failures back and lets
the session try again, up to a cap. Green, with a real diff, and it opens a pull request and
moves the issue to review
, then picks up the next one. The board is what makes this compound: it holds what is done and what is left, so the loop never repeats itself or loses its place.
Every run ends one of three ways, and the loop treats each differently: ready for review when
the conditions are met, needs a human when the session is awaiting_input
, or a hard stop when
it hits the iteration cap or the budget. Only the first advances on its own. When every issue
in the feature is sitting in review
with green checks and an open PR, the loop's success condition is met: it stops and hands the batch back to you. You review and merge, and a separate release loop takes it from there, promoting merged work to production once the release checks pass.
Work my Linear feature: take each issue tagged ready-for-agent in order, give it its own
worktree, and start a session to implement it. When a session goes idle, read
lanes_get_issue_changes and run the tests. If they fail, resume the session with the failures
pasted in, up to three times. When they pass with a real diff, open a PR and move the issue to
review. Do not merge anything. Stop after 45 minutes or once every issue is in review, then
give me the list of PRs.
The 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.
Guardrails in practice #
Everyone 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.
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 atawaiting_input
, and the reason thereview
column 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.
The takeaway #
Prompt 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.
If you want to see the parts assembled, that is what Lanes is built for: it puts every agent session on a board and exposes it over a local MCP server, so a loop has real state to read and advance. The docs have a step-by-step version of the loops above.
References #
- Addy Osmani, Loop Engineering(Jun 7, 2026):addyosmani.com/blog/loop-engineering, also onO'Reilly Radar(Jun 22, 2026) - The Neuron, Claude Code's Creators (Boris Cherny & Cat Wu) Explain Agent Loops(Jun 9, 2026):theneuron.ai - Wang et al., The Verification Horizon: No Silver Bullet for Coding Agent Rewards, arXiv (Jun 24, 2026):arxiv.org/abs/2606.26300 - ADTmag, Loop Engineering Emerges as Developers Put AI Coding Agents on Repeat(Jul 1, 2026):adtmag.com - VibeReady, Loop Engineering in Claude Code(2026):vibeready.sh