Every few months the AI building world agrees on a new thing you are supposed to be doing, and this month it is loop engineering. The pitch is clean: you do not prompt your coding agent one step at a time anymore. You design the loop that prompts it for you, point it at a goal, and walk away.
It is a real shift, and it is worth understanding. But the part the loop tweets leave out is the interesting part. The loop takes prompting off your plate and hands you back a harder job, one you cannot automate your way out of. Knowing what that job is tells you exactly where to put your effort.
What loop engineering actually means
Loop engineering is the practice of designing a system that prompts and orchestrates an AI coding agent on a schedule, instead of you typing each prompt by hand. Addy Osmani, whose explainer became the reference for the term, defines it plainly:
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
A loop is roughly five pieces plus one. Automations that fire on a schedule and find work. Worktrees so two agents do not collide. Skills that write down project knowledge the agent would otherwise guess. Connectors that plug the agent into your real tools. Sub-agents, so the one that writes the code is not the one that grades it. And the sixth piece, the one that makes the whole thing hold together: a memory that lives outside any single run and remembers what is done and what is next.
The wave started with two sentences from people who would know. Peter Steinberger, who built the open-source agent gateway OpenClaw and now works at OpenAI, put it as a standing reminder:
Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.
Days earlier, Boris Cherny, who leads Claude Code at Anthropic, described on stage where his own job had gone:
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.
Boris Cherny, head of Claude Code at Anthropic
Steinberger's post hit 6.5 million views in a week. It landed because the pieces ship inside the products now: /goal in Claude Code defines a testable end state and keeps working until it is true, with a separate model grading whether it is done. The leverage point moved, and everyone felt it at once.
The job the loop hands back
Here is the contradiction at the center of the hype. A loop running unattended is also a loop failing unattended. Take prompting off your plate and you have not removed the work, you have moved it somewhere worse: into runs you were never watching, with far too much output to read by hand. Akshay Pachaar said it sharply this week:
Loop engineering takes you off prompting. It takes you off curating context. It takes you off babysitting a single run. It does not take you off debugging. It just moves the debugging somewhere worse, into runs you were never watching.
Stack the layers up, prompt to context to harness to loop, and one job survives all of them. Closing the loop on failure. You can only walk away from a loop if you trust the thing checking it, and a checker you do not trust drops you right back into reading every output by hand, which is the exact work the loop was supposed to take off you.
So the real question loop engineering raises is not "how do I build the loop." Both Claude Code and Codex ship the loop. The real question is "what does my checker check against." A loop with no definition of done is just a faster way to generate work you still have to inspect line by line.
Why this moves the work upstream, not away
Watch what happens to the human as each layer of automation arrives. Prompt engineering asked you to write a good message. Context engineering asked you to curate what the model sees. Loop engineering asks you to design the system that does both on a schedule. At every step the manual labor shrinks and the judgment concentrates. The thing you cannot hand off is deciding what you actually want and stating it precisely enough that a machine can check the result.
That is a spec. Not a vague ticket, not a paragraph in Slack, but a requirement with testable acceptance criteria: the agent built this, here is how we know it is right. The sub-agent that "verifies against the spec," in Osmani's words, needs a spec to verify against. The loop's memory, the file that survives between runs, has to hold something worth remembering. Both of those are the same artifact, and writing it is the work that does not disappear.
Consider the before and after. Before: you babysit a single run, catch the drift in real time, correct it prompt by prompt. After: the loop runs ten times overnight and you wake up to ten pull requests, half of them subtly wrong in ways no human would have written, and no clear standard to grade them against. The loop made you faster at producing work and slower at trusting it. The fix is not a better loop. It is a definition of done the checker can actually use.
Where BrainGrid fits in a loop
This is the gap BrainGrid was built for. BrainGrid is a product factory that runs the loop Plan, Build, Verify, Repeat, and it owns the two pieces a loop cannot generate for itself: the plan and the standard.
You describe a feature in plain language. The Planning Agent asks the clarifying questions a senior engineer would, surfaces the edge cases, and writes an engineering-grade requirement with acceptance criteria. That requirement is the spec your loop's verifier checks against. It is also the memory: it persists outside any single run, so when tomorrow's automation fires, the context is already there. The agent forgets between sessions. BrainGrid does not.
From there the loop runs either way. Load the scoped tasks into Claude Code, Cursor, or Codex over MCP and let your own harness drive them, or let BrainGrid's Builder Agent build the requirement in a managed sandbox and open a pull request, with AI code review checking the result against the acceptance criteria item by item. Verification stops being a thing you hope the loop got right and becomes a thing the loop can prove. That is what makes walking away safe. This is the same discipline we cover in agentic engineering, and the full five-stage version lives in The BrainGrid Loop.
So is it real, or just another buzzword
Both, the way most of these are. The mechanics are real and genuinely useful: scheduled, self-checking agent runs are a meaningful jump in capability, and if you have not tried /goal in Claude Code you should. The buzzword part is the implication that designing the loop is the whole job. It is not. It is the part that got automated. The part that did not, defining what done means and giving the checker something real to check, is where the work went. Put your effort there, and the loop pays off. Skip it, and the loop is just a faster way to dig the hole we wrote about in I built a vibe-coding mess. The loop-as-a-running-joke version is our take on the Ralph Wiggum plugin.
FAQ
What is loop engineering?
Loop engineering is the practice of designing a system that prompts and orchestrates an AI coding agent automatically, on a schedule, instead of typing each prompt yourself. A loop typically combines scheduled automations, isolated worktrees, project skills, tool connectors, and sub-agents that check each other's work, plus a memory that persists between runs. The goal is to move from holding the agent's hand through every step to designing the system that runs it for you.
Is loop engineering real or just another AI buzzword?
It is both. The underlying mechanics are real and shipping today in Claude Code and Codex, and scheduled self-checking agent runs are a genuine step up. The buzzword part is the suggestion that building the loop is the whole job. The loop automates the prompting, but it hands back the harder work: defining what "done" means so the loop's checker has a standard to verify against. Designing the loop is the easy half. Closing the loop on failure is the half that survives.
What is the difference between loop engineering and prompt engineering?
Prompt engineering optimizes a single message you send by hand. Loop engineering designs the system that sends those messages for you, on a cadence, and checks the results. Prompt engineering is one turn; loop engineering is the machine that runs many turns unattended. The skill moves from wording a request to specifying a goal precisely enough that an automated checker can confirm it was met.
Does Claude Code support loop engineering?
Yes. Claude Code ships the core pieces: /loop re-runs a prompt on a cadence, /goal keeps working until a condition you defined is true with a separate model grading whether it is done, and hooks plus scheduled tasks let you run autonomous work on an interval. Codex offers the same primitives through its Automations tab. The pieces are in the products now, which is why the term took off.
What does loop engineering not solve?
Verification and your own understanding. A loop running unattended is also a loop making mistakes unattended, and the more code it ships that you did not write, the larger the gap between what exists and what you actually understand. The loop can take you off prompting, context curation, and babysitting a single run. It cannot take you off deciding what you want and confirming the result matches. That is why a clear spec with acceptance criteria, which is what BrainGrid produces, is the piece that makes a loop trustworthy enough to walk away from.
BrainGrid is the AI Product Planner that gives your agent loops the one thing they cannot generate for themselves: a spec with acceptance criteria the verifier can check against. Try it at braingrid.ai.
Originally published on the BrainGrid blog.
Top comments (0)