There is a word going around lately: loop engineering.
The idea is simple to state. Going forward, you should stop hand-prompting your coding agent. Instead, you design a system that prompts the agent, drives it, and runs the whole process for you.
It sounds buzzy. But honestly, my first reaction was not “new.” It was “familiar.”
Because over the past year of building MewDesign, I have been doing exactly this — I just never had a name for it. The term finally caught up to what I was already doing every day.
No hype in this post. I will unpack loop engineering, end to end, using a year of real MewDesign experience.
01 - First, translate it into plain English
For the past two years, the way we used coding agents was basically fixed. You write a good prompt, give enough context, and go back and forth. You type something, it replies; you read the result, you type the next thing.
Through all of that, you are “holding” the agent. It is a tool, and you are the hand holding it — one turn after another.
Loop engineering says: that part is ending.
Peter Steinberger put it bluntly — you should not be prompting coding agents anymore. You should be designing loops that prompt them. Boris Cherny, who leads Claude Code at Anthropic, said the same thing even more directly. He does not prompt Claude anymore. He has loops running that do it. His job, in his words, is to write loops.
In plain English: you are not the hand that keeps pressing the button anymore. You are the person building the machine that presses it automatically.
That sounds like slacking off. It is the opposite. I will come back to that.
02 - A loop is not a cron job — the difference is one thing
At this point, the sharpest objection shows up.
If a loop just means “run the same prompt on a schedule,” is that not just a cron job? Scheduled tasks are older than most of us.
Good question. The difference is one thing, and it matters enough to get its own section.
A cron job runs a fixed script. You hardcode what it does; it fires on time and stops. It does not think, and it does not change approach because the last result was wrong.
A loop runs an agent. It looks at the current state, decides the next step itself, checks the result, and then decides: continue, retry, roll back, or stop.
One runs a dead script. The other makes its own decisions. That is the whole difference.
But that one sliver of difference is exactly where AI actually moved this year. Models got good enough to make decisions inside a loop — the decision-making power moved out of your hand and into the loop.
Everything else called “loop engineering” grows out of that one shift.
03 - Five things a loop needs to stand up
So what does designing a loop actually involve? Boris’s line — “my job is to write loops” — sounds cool, but what does it look like in practice?
Pull it apart and it is basically five things, plus one more for remembering.
Automations — this is the loop’s heartbeat. It finds work and triages it on a schedule, instead of waiting for you to remember. Every day it might scan new issues, summarize where CI failed overnight, or find bugs someone introduced last week. Without this, your “loop” is just something you ran once.
Worktrees — the moment you let more than one agent work at the same time, they start colliding on files. Two agents editing the same file is the exact same headache as two engineers committing to the same lines. A worktree gives each agent its own working directory; they edit their own copies and physically cannot step on each other.
Skills — this is the one I know best and spend the most time on. Put simply, you write the project knowledge down so the agent does not have to guess like an amnesiac every time. Code style, design preferences, what counts as shippable, which traps to avoid — you freeze these into a skill, the agent pulls it when it needs it, and you stop re-explaining every session.
Plugins and connectors — plug the agent into the tools you already use: the repo, the task board, the database, the design files. If a loop is going to run things for you, it first has to reach the things you work with.
Sub-agents — one agent has the idea, another verifies it. This matters: the agent that wrote the code cannot also be the one grading it. Grading your own work basically is not grading.
The sixth thing is memory — it sounds the least important, but it is the foundation. Agents forget between conversations, so “what is done” and “what is next” have to live on disk, on a board, in a database, anywhere outside a single conversation.
There is a line I really like: the agent forgets, but the repo does not. Every piece of state that has to survive across turns has to leave the chat and move onto the hard drive.
04 - What these look like inside MewDesign
At this point you might think — those five things are a lot. How many has MewDesign actually adopted?
Honestly, some I lean on heavily, and some I am still filling in. But my point is not “I use all of them.” It is this: the moment you decide to hand decision-making to the agent, you naturally need these things to backstop it.
Take skills. Since I started MewDesign, the thing I write the most is not code — it is rules. What counts as a usable design: the text has to be preserved exactly, the logo and QR code have to go in, it has to be printable, you can change the mood without breaking the layout. All of this has to be written down, line by line, and handed to the agent. I have always insisted on not letting users pick the model by default, because I do not think a bad result should be blamed on “you picked the wrong model.” That is exactly what a skill does: freeze the definition of “good,” and let the agent backstop the user.
Take sub-agents. MewDesign is built with my co-founder. She owns product tone and aesthetic judgment; I own the AI agent and the tech. That split is itself “one generates, one verifies” — a product cannot grade itself. Later I moved the same logic into the system: the generation step and the inspection step have to be separate.
Take memory. We never let an agent keep going by “remembering the context,” because models really do forget. State always lands in the repo, the database, or the board. You only truly believe this after it bites you.
As for automations and worktrees, I have not rolled those out fully yet. Here I want to admit a stubbornness of mine: I do not over-build ahead of the model — only when a frontier model’s capability genuinely jumps do I go refactor the matching module into loop form. Building ahead of the model is mostly wasted money. Your pace has to follow the model’s cadence.
So the five pieces are not a to-do list you tick off. They are more like: however much decision-making you hand over, that is how much backstop you need.
05 - Without a verifiable goal, a loop is just a token furnace
Last section — the thing most easily buried under the buzzword, but the one that matters most.
For a loop to hold together, the five pieces above are not enough. It needs, at the bare minimum, one more thing: a check that tells it when the work is done.
That check can be hard — all tests pass, CI is green. It can be softer — a separate model checks whether the UI matches the spec. But soft or hard, the check has to exist.
Why? I will borrow a line someone put harshly. If you build a loop with no verifiable goal, what you have built is not a loop. It is a very confident token furnace — confidently, ceaselessly burning your tokens, never stopping, because it has no idea it should stop.
That line hits me hard.
Anyone building an AI product knows the feeling. AI products are not like traditional products — every user who walks in can bring token cost, generation cost, retry cost. The more users, the more those costs scale linearly. That is why I keep saying: for an AI product, a non-converting user is not an asset. It is a liability.
A loop is exactly the same. It runs for you, but it burns your money. It needs something to tell it: enough, you can stop. Otherwise it is not helping you — it is ceaselessly, automatically, burning money on your behalf.
Loop engineering is something you have to cost out on two ledgers: how much work it saves you, and how much money it might burn for you. Only count the first one, and you will talk yourself into going broke.
06 - Finally
Back to the original question: is loop engineering just another buzzword?
The name is new, for sure. We have watched the words roll out one after another these past two years — prompt engineering, context engineering, harness, and now loop engineering.
But line them up and you will see they are all about one thing: how to steer the model as well as possible. The model gets stronger, and our steering upgrades with it.
The thing that has actually changed, from start to finish, is one thing: decision-making power moved from the human into the loop. Once it moves, the human rises one level — from the person pressing the button each time, to the person designing the button-pressing system.
That is the real meaning of Boris’s “my job is to write loops.” Not slacking. Leveling up.
If I had to compress loop engineering into one line, I would use the one I believed most this past year:
AI does the execution; humans do the judgment — loop engineering is just a more accurate new name for an old thing.