Your engineers have their AI licenses. They prompt, read what comes back, fix it, and prompt again. The dashboard is green and everyone agrees the tools help. Here is the part that should worry you: you have automated the typing and kept the slowest, most expensive component inside every cycle. A person, deciding each next step by hand.
That ceiling does not move with more licenses, because it is built into how you use AI, and there is now a name for the skill that removes it. Loop engineering
You stop being the person who prompts the agent and design the system that does it instead.
Which parts of your delivery system will you run as machine-checked loops, and what will you fund to make the checks trustworthy? Decide deliberately, or your AI gains keep scaling with human attention while a competitor's start to compound.
The leverage point moved
The first time we let an agent run unattended inside the AI-DLC harness at Betsson, it came back reporting success. It had quietly weakened a failing test until it passed. That single incident taught me more about where the leverage in AI delivery sits than any benchmark, and it is why I read the loop-engineering wave as a real shift rather than a slogan. I have seen enough delivery shifts arrive disguised as tooling upgrades to recognize the pattern: the tool is the least interesting part.
Two engineers from rival camps said the same thing within a day of each other. Peter Steinberger posted: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
Boris Cherny, who leads Claude Code at Anthropic, said much the same the next day, in a remark that circulated widely afterward: "I don't prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops."
Strip the vocabulary away and the concept is simple. A prompt is an instruction: one answer, then the agent waits for you. A loop is a goal, a way to check progress against it, and a rule for when to stop.
In a Loop, the system discovers the work, plans, executes, verifies, and iterates until the check passes or the stop rule fires.
The test that separates a real loop from a scheduled prompt is discovery: a loop never says "go fix X." It teaches the agent how to find the work, gives it the tools to validate what it finds, and reserves your judgment for the result.
What changed this year is that this stopped being a scripting project. Addy Osmani describes a working loop as five building blocks:
- scheduled automations
- isolated workspaces
- written-down project knowledge
- connectors so the loop opens the pull request itself
- sub-agents so the writer is never the checker All of it, held together by a memory, a markdown file or ticket board outside the conversation.
Every piece now ships inside both Claude Code, Cursor and Codex, which makes this an operating-model decision, not a tooling backlog item. It is the continuous intelligence loop from Redefining the Software Lifecycle, now with a heartbeat, a gate, and a memory.
The gate is the product
Here is the claim worth arguing with me about: the loop is now a more valuable engineering artifact than the code it produces.
Code is becoming the byproduct. The loop is the asset.
Everything in a loop lives or dies on the gate, the check that can automatically fail the work. Without it you do not have a loop; you have an agent agreeing with itself on repeat, because the model that wrote the code is far too generous grading its own homework.
Code Writer agents generate within guardrails, separate Reviewer and Test Writer agents validate against the spec, humans approve at defined gates, and production incidents feed back so the same failure cannot ship twice.
What a production loop looks like
The most instructive loop I have seen outside our own harness runs on a normal budget. Fabio Quintanilha mentioned on one of his recent videos he runs a daily "backlog scout" in Codex: it scans the board for exactly one small, self-contained, unassigned ticket, checks the affected code and tests before proposing, and carries a hard exclusion list: mobile, auth, payments, database migrations, anything backend. It remembers rejected suggestions so a "no" is not re-proposed tomorrow, and one standing rule says "nothing safe today" is an acceptable answer. When he approves a candidate, it implements in an isolated worktree and opens a draft pull request. He signs off at the end; he never tells it what to fix.
Notice what carries that loop: the exclusion list, the memory of rejections, the permission to find nothing, the draft PR as the gate. All design decisions, none of them prompts. His cost caveat is worth repeating: Steinberger and Cherny have effectively unlimited tokens, so their loops wake every five minutes; most teams should pick the cadence their budget survives, and the loop works the same.
Where the concept breaks
Not everything deserves a loop. The best filter I have seen, from Anatoli Kopadze's write-up on loops, is four conditions that must all hold:
- the task repeats at least weekly
- something can automatically reject bad output
- the agent can do the work end to end
- "done" is objective rather than a matter of taste
Miss one and a good prompt is still the better tool.
Loops also fail quietly: an agent declares victory early, and the loop keeps running and billing with nothing to show. Every serious loop needs two exits, verified success and a hard cap that stops and reports. And the cost compounds in a shape budgets do not expect: every pass re-reads a growing context, and the maker-checker split doubles the reads. The full economics of metered tokens get their own episode in Token Economics.
The sharpest risk is human, and it is why loop design is harder than prompt engineering, not easier. The faster a loop ships code you did not write, the faster the gap grows between what exists and what you understand. Osmani calls the failure shapes comprehension debt and cognitive surrender. Two people can run the identical loop and get opposite outcomes: one moves faster on work they understand deeply, the other uses the loop to avoid understanding it at all. The loop cannot tell the difference. That is The Velocity Trap running unattended, on a schedule.
This is not a contradiction with Continuous Fluid Flow, where I argued AI-native delivery needs more synchronous human collaboration: humans design the loops, the specs, gates, and guardrails together. Only then the loops should run unattended. You are not removing judgment, you are concentrating it where it compounds.
Engineering your first loop
Five steps, in an order that survives production.
1. Select loop-eligible work with the four-condition test. Keep only work that passes all four conditions, and start where verification is free: nightly CI failure triage, dependency updates, flaky-test hunts, documentation drift. Or copy the backlog scout above, exclusion list and all. Signal: for every selected task, you can name the exact command that rejects bad output.
2. Prove one manual run, then write it down. The order is manual run, then skill, then loop, then schedule. Run the task by hand with the agent until it works, then capture what made it work in a SKILL.md file: conventions, build steps, the never-touch list, the "we do not do it that way because of that incident" knowledge. Pitfall: scheduling something you never made reliable by hand, which is how loops blow up overnight. Signal: two clean runs in a row driven by the written skill alone.
3. Engineer the gate before the loop. Define machine-checkable success and a hard stop before the first unattended run. Write a loop spec. GOAL: all tests in /tests/auth pass, lint clean, zero type errors. EACH PASS: fix the single highest-impact failure. STOP: when verification passes, or after 8 iterations, then summarize what changed and what still fails. Assign verification to a separate checker agent, ideally a different model. Inside the Betsson harness, our checkers carried one standing instruction the writers never got: treat the change as wrong until the spec and the existing tests prove otherwise, and never edit a test to make it pass. Signal: the checker rejects some share of drafts every week.
4. Put state on disk, not in the context window. The loop's memory must outlive the session. Keep a state file or ticket board with four fields per item: tried, result, still open, next. Tomorrow's run resumes instead of rediscovering the repo from zero. Pitfall: trusting the context window as memory; the agent forgets, the repo does not.
5. Track cost per accepted change, weekly. Log every run with tokens consumed, changes proposed, and changes accepted by the human gatekeeper. Counting loops run and tokens burned measures activity, not value.
What this costs, and what to fund first
The loop tooling itself is nearly free; it ships inside products you already license. The honest costs are the test suites trustworthy enough to serve as gates, CI signal quality, and review capacity for what loops produce. Fund first: verification infrastructure and one contained pilot loop. Fund later: parallel fleets. The kill metric: within one quarter, the pilot's cost per accepted change should be flat or falling with acceptance above 50%; below roughly half of proposals accepted, a loop costs more than it returns. If it is not, fix the gates or kill the loop. Do not fix the prompts.
Start, Stop, Continue
Executives
Start: funding gates as strategic infrastructure; requiring the four-condition test before any workflow is automated; putting cost per accepted change on the engineering dashboard.
Stop: counting licenses, prompts, or tokens as progress; approving unattended loops with no iteration cap or token budget.
Continue: holding a named human accountable for every change a loop merges.
Engineers
Start: converting your most repeated manual workflow into a skill file this week; splitting maker from checker on anything that runs unattended; giving every loop an exclusion list and permission to find nothing.
Stop: re-prompting the same triage every morning; letting any agent verify its own work; scheduling anything you have not run reliably by hand.
Continue: reading what the loop ships. Your comprehension is the gate behind the gate.
Strategic takeaway
Loops with real gates compound: every cycle updates the skills, the guardrails, and the state, so the next run starts smarter. Prompting plateaus: it scales only as fast as human attention, no matter how good the model gets. That gap is small this quarter and brutal in four. The teams that win the next phase will not have the best prompt libraries; they will have the best-engineered gates, because the gate is what turns AI activity into delivered value, and it is the one artifact a competitor cannot copy from a screenshot.
So here is the question for your next leadership meeting:
Which workflow in your organization would you trust to run overnight with no human watching?
If the answer is none, is that because your work is impossible to verify automatically, or because nobody has built the gate yet?
Top comments (0)