Boris Cherny, the person who built Claude Code, said something recently that stuck with me: he does not really prompt the AI anymore. His job now is to write loops. Other people who build these tools, like Addy Osmani, have been saying the same thing. Stop prompting the agent. Start designing the loop that prompts the agent for you.
When I read that, I had two reactions. The first was the usual eye-roll at yet another new AI term in a year that has had too many. The second, once I actually looked into it, was quieter: I had been building a clumsy version of this for weeks without knowing it had a name. So here is the honest version for a solo developer. What loop engineering actually is, the parts that make a loop work, and where my own setup was already halfway there and where it very much was not.
What is loop engineering?
Loop engineering is designing a system that prompts an AI agent repeatedly until a goal is done, instead of you typing prompts one at a time. A normal prompt runs once and stops. A loop is a prompt that runs over and over, checking its own progress, until a specific goal is complete.
The shift is subtle but real. With prompting, you are the engine. You type, read the result, type again, a hundred times to finish a task. With a loop, you describe the goal and the rules once, and the loop does the prompting. Your job moves up a level: from doing the steps to designing the system that does the steps.
That is the whole idea. The hype around it is loud, but the core is simple, and most of the complexity people pile on top is optional.
How is loop engineering different from prompt engineering?
Prompt engineering is about writing the single best instruction. Loop engineering is about designing the system that issues instructions for you, over and over, until a goal is met. One is a better sentence; the other is a better machine.
The skills barely overlap. A great prompt is a writing problem: clear wording, good examples, the right framing. A great loop is a systems problem: what triggers it, how it checks its own work, where it stores what it learned, and when it stops. You can be excellent at one and a beginner at the other.
This is also why loop engineering is being called the next step rather than a replacement. You still need good prompts inside the loop, the same way you still need good sentences inside a program. The loop just decides when those prompts run, what they run against, and whether the result was good enough to move on. The unit of work moves from the message to the system around it.
When does a task actually deserve a loop?
Not everything should be a loop. The test I have settled on, borrowed from people doing this longer than me, is four questions.
Does the task repeat? If it is a one-off, just prompt it. Loops are for things you do again and again. Is there a clear definition of done? A loop needs to know when to stop, so a fuzzy goal with no finish line is a bad candidate. Can you afford the tokens? A loop prompts itself until it is satisfied, which can burn through a lot, so be deliberate if you are cost-sensitive. And does the loop have the tools to both do the work and check it? If it cannot verify its own result, it cannot close the loop.
If a task passes all four, it is a real candidate. If it fails one, a plain prompt is still the right tool. Most of my work is still plain prompts, and that is fine.
What does every working loop need?
From everything I have read and tried, a loop that actually works has four parts.
A trigger, the thing that kicks it off. That can be a schedule, an event, or a single command you run. Execution skills, the battle-tested instructions that do the actual work. The rule I like here is simple: do not build a loop on top of a skill you have not already proven by hand. A goal and a verification, tied together, because a goal you cannot check is a goal the loop cannot finish. The clever trick is bridging fuzzy goals to something checkable, like a review step that returns approved or not approved. And output plus memory, because a loop that forgets what it did last time just repeats the same mistakes and wastes tokens. One line from the research stuck with me: the agent forgets, the repo does not. So you give it a plain file to write its notes in.
Trigger, skills, goal and verification, memory. That is the skeleton. Everything fancy is built on those four bones.
How was my AIOS already halfway there?
This is the part that surprised me. I have been building an AI operating system for softDev23, and when I lined it up against those four parts, most of them were already there in rough form.
My skills and systems are the execution skills. My n8n schedules are triggers. My daily logs are the memory file, the place where what happened gets written down so the next session is not starting blind. And the agentic operating system I have been building, the layer that lets my agents actually take actions, is exactly the substrate a loop runs on top of. I had the ingredients. I just had not connected them into something that prompts itself.
What I did not have was the autonomous part. My agents still wait for me to start them. A true loop wakes itself up, does a chunk of work, verifies it, logs it, and goes back to sleep, all without me typing go. That gap, between a setup I drive and a setup that drives itself, is the actual work of loop engineering. It turns out the hard part was never the loop. It was having battle-tested skills and durable memory for the loop to stand on, and I had been building those the whole time.
What is the honest catch?
Here is the part the excited videos skip. A loop that can act on its own can also be wrong on its own, faster and more times than you would ever do by hand.
So the guardrails are not optional, they are the whole game. The advice I trust most is to run any new loop in a kind of training mode first, where it pauses at each step and asks before it continues, so you can watch what it actually does before you let it run free. The other rule is to never let an agent be the only judge of its own work, because they are generous graders of themselves. A separate check, ideally a different agent, catches what the first one misses.
I learned the underlying lesson the hard way, which is why I am careful here. An AI tool once wiped two days of my work in a single move. The agent was not malicious, just fallible, the way all of them are. A loop is that same fallibility running unattended on a timer. That is exactly why my whole setup is built so agents draft everything and publish almost nothing without my yes. Autonomy without verification is not leverage, it is just risk on a schedule.
Where am I starting?
Small, and on purpose. The advice that makes sense to me is to pick the smallest thing you have already proven works by hand, and wrap just that in a loop, with a checkpoint you have to approve.
For me that is something like a research-and-draft loop: a skill I already trust, given a clear goal, a verification step, and a memory file, running on a schedule but pausing for my review before anything goes live. Not a fleet of autonomous agents running my business while I sleep. One small, well-guarded loop that does a single boring job reliably, that I can actually trust, and that I can turn off the moment it misbehaves.
The bigger point
Loop engineering is a real shift, and the people calling it the next step after prompt engineering are probably right. But for a solo developer, the takeaway is the same one that has been true the whole time. The unlock is not a smarter model. It is structure: good skills, clear goals, real verification, and durable memory, with you keeping control of the decisions that matter.
If you have been building any kind of system around your AI tools, you may be closer to this than you think. The loop is just the last piece, the part that makes the machine run itself. The pieces worth trusting are the ones you put underneath it.
