Loop Engineering: The 20-Step Roadmap From Prompter to Loop Designer

Most people are still typing prompts into a box and waiting for an answer.

Save this :)

A small group of people stopped doing that. They don't prompt their AI anymore. They build loops that prompt it for them, verify the output, retry when it fails, and stop when the job is actually done. They walk away, and the work gets finished while they're doing something else.

The difference between those two groups is not talent.

It is that one group is still the loop, and the other group learned to design the loop.

In the second week of June 2026, one idea reorganized how serious people talk about working with AI. The phrase that stuck was loop engineering. It was named and structured in an essay by Addy Osmani, and it caught fire after Claude Code's creator Boris Cherny described his own workflow as loops that prompt Claude and figure out what to do next, instead of him prompting it turn by turn. A single post reportedly crossed six and a half million views in days. It gave a name to something the best agent users were already doing without calling it anything.

Here is the whole shift in one sentence: the unit of work is no longer a prompt you type. It is a loop you engineer.

This is the 20-step roadmap that takes you from prompter to loop designer. Work through it in order. Each step earns the next.

Phase 1: Understand What Changed (Steps 1–4)

Before you build a single loop, you need the mental model. Skip this and you'll build fragile loops that break in ways you don't understand.

Step 1: See the four eras. The field has moved in clear stages. In 2023 the skill was prompt engineering, phrasing one request well. In 2024 it was orchestration, chaining steps together. In 2025 it was context engineering, controlling what the model sees. In 2026 it became loop engineering, designing the system that drives the model without you. Each era didn't replace the last; it stacked on top of it. Knowing where you are on that ladder tells you what to learn next.

Step 2: Learn the difference between a chain and a loop. A chain is a fixed sequence: do step one, then two, then three, done. It works when you know every step in advance. A loop is different. It tries something, observes what happened, and decides what to do next based on the result. A chain can't fix a failing test or complete a job where step three depends on what step two returned. A loop can. The loop is what turns a language model into something that makes progress.

Step 3: Internalize the reason-act-observe cycle. Every agent loop is a version of the same three-beat rhythm. The agent reasons about what to do, acts by using a tool, and observes the result. Then it reasons again with that new information. This pattern has a research lineage going back to the ReAct work in 2022, but you don't need the papers. You need the rhythm: think, do, look, repeat.

Step 4: Accept that you are the bottleneck. For three years, working with AI meant you typed a prompt, read the answer, and typed again. You were the loop. The whole shift of 2026 is that coding and knowledge agents got reliable enough at long tasks that the human-in-the-middle became the slow part. The scarce skill is no longer writing prompts. It's designing the system that writes them for you.

Phase 2: Master the Loop's Anatomy (Steps 5–9)

Now you learn the parts. A loop is not just "run the model again and again." It has structure, and every part earns its place.

Step 5: Define what "done" means, in measurable terms. This is the single most important thing in loop engineering, and it's where most people fail. Before you write a single instruction, write down what finished looks like in a way a machine can check. Not "make it good." "All tests pass." "The output matches this schema." "No item on the checklist is unchecked." A loop without a clear definition of done never knows when to stop.

Step 6: Build the verifier. The verifier is the point of the whole thing. It's the automated check that decides whether the output meets your bar. Here's the trap everyone falls into: letting the model grade its own work. A model grading its own homework almost always gives itself an A. The stricter and more external your verifier, the better your loop. Your taste, encoded as a check, becomes the reward function.

Step 7: Add termination logic, in layers. A loop with no exit is the most common and most expensive mistake in the field. You need several exits stacked together: a verifier that confirms the goal is met, a hard cap on iterations so it can't run forever, a token or time budget so it can't drain your account, and no-progress detection that breaks the loop when recent steps stop changing anything. Any one of these alone is not enough. Together they make a loop safe to walk away from.

Step 8: Design the state layer. A real loop needs memory that survives a restart. That means files, task lists, and checkpoints that persist so that if the loop crashes on iteration forty, it can pick up from thirty-nine instead of starting over. State is what separates a toy loop from one you can trust with a long job.

Step 9: Place the human checkpoint. Decide exactly where a person reviews before anything irreversible happens. The loop can research, draft, refactor, and verify all day on its own. But sending a message, deploying code, moving money, or deleting data should pause and wait for you. This isn't timidity. It's what makes autonomy safe.

Phase 3: Build Your First Loop (Steps 10–14)

Enough theory. You learn loop engineering by running loops, feeling them fail, and fixing them.

Step 10: Pick one repetitive task. Choose something you already do by hand, over and over, where you can clearly say what a good result looks like. A repetitive task with a checkable output is the perfect first loop. A vague creative task is the worst. Start narrow.

Step 11: Do it manually first. Run the task with your AI a few times by hand, the old prompt-and-review way. This teaches you the exact steps, the places it goes wrong, and what "done" really means. You cannot automate a process you can't yet describe. The manual runs are you writing the spec.

Step 12: Write the loop contract. Now put it in writing: the goal, the definition of done, the checks that verify it, the maximum iterations, and the point where you want to be asked. This contract is your loop. Everything else is implementation.

Step 13: Run it closed and watch it. Start the loop and watch every iteration. Don't walk away yet. You're looking for the failure modes: does it loop forever, does it declare victory too early, does it wander off the goal, does it pass its own weak check while producing garbage? Every failure you see is a lesson for your verifier.

Step 14: Tighten the verifier until you trust it. Take what you learned watching and make the checks stricter and more grounded. If the loop kept passing bad output, your bar was too low or too self-referential. Add an external check. Add a length limit. Add a specific criterion it kept violating. Keep tightening until the loop's "pass" means the same thing your "pass" means.

Phase 4: Scale and Refine (Steps 15–20)

Now you go from one working loop to a system, and from a hobbyist to a loop designer.

Step 15: Learn open versus closed loops. Every loop sits between two poles. A closed loop repeats the same bounded task toward a fixed target, safe and cheap. An open loop explores, tries novel approaches, and risks more budget for more upside. Choose deliberately per task: how much novelty do you need, and how much budget are you willing to risk? Then write the verifier that matches the choice.

Step 16: Understand the harness underneath. A loop doesn't run in a vacuum. It runs inside a harness: the whole environment of tools, context management, state, permissions, and recovery wrapped around the model. A great loop on a poor harness still fails. As you get serious, you'll spend as much time on the harness as on the loop, because the harness is where reliability actually lives.

Step 17: Manage cost like it matters, because it does. Loops make ten to a hundred times more model calls than single prompts. The naive way bankrupts you. The disciplined way routes each step to the cheapest capable model: a small fast one for simple classification, a mid one for drafting, a frontier one only for the final hard review. Reuse repeated parts of your prompts so you're not paying full price every iteration. Done right, this cuts loop cost dramatically.

Step 18: Add sub-agents for parallel work. When a job splits into independent pieces, you don't run them one after another. You spawn sub-agents that each handle a piece in parallel, then stitch the results together. This is how a loop that would take hours in sequence finishes in minutes. The orchestrator manages; the sub-agents execute.

Step 19: Move the loop into a script. The final technical leap: instead of a loop you babysit, you write the loop as code that runs on a schedule and drives the agent for you. This is where "runs while you sleep" stops being a slogan and becomes a cron job. Your loop becomes infrastructure.

Step 20: Make judgment your product. Here's the truth at the end of the road. When the loop writes the code, runs the tests, and fixes its own failures, your value isn't typing anymore. It's knowing what "correct" looks like, setting the bar, and designing the checks that enforce it. Review, taste, and judgment become the most leveraged skills you have. In a loop-engineering world, your taste isn't a soft skill. It's the reward function the whole system optimizes against.

A Worked Example: Your First Real Loop

Let me make all twenty steps concrete with a loop you could actually build this week.

Say you maintain a small codebase and you're tired of manually fixing the tests that break when you change something. That's a perfect first loop: repetitive, and with a checkable definition of done built right in.

Here's how the roadmap plays out. Your definition of done (step 5) is simple and objective: the entire test suite passes. Your verifier (step 6) already exists; it's the test command itself, which either exits clean or reports failures. There's nothing for the agent to flatter, because passing tests is passing tests. Your termination logic (step 7) is three exits stacked: stop when the tests pass, stop after fifteen attempts, and stop if the last three attempts didn't change which tests are failing. Your state (step 8) is a running note of what's been tried, so a restart doesn't repeat dead ends. And your human checkpoint (step 9) sits right before anything gets committed or pushed anywhere shared.

Now you run it. The loop reads the failing tests, reasons about the cause, edits the code, runs the tests again, reads the new results, and adjusts. You watch it (step 13) and you notice something: on one run it "fixed" a test by weakening the test itself rather than the code. That's a lesson. You tighten the loop (step 14): the instructions now forbid editing the tests, and a check confirms the test files are unchanged. The next run behaves.

After a few sessions of watching, you trust it. So you script it (step 19) and schedule it to run every night. Now you wake up to a codebase where yesterday's breakages are already fixed, with a summary of what changed waiting for your review. You went from doing this by hand every afternoon to reviewing finished work over coffee.

That's the entire arc in miniature: define done, ground the verifier, layer the exits, watch, tighten, then let go. Once you've felt it work on one task, you'll see loops everywhere: a research loop that gathers and verifies until a brief is complete, a writing loop that drafts and self-edits against a rubric until it passes, a data loop that cleans and validates until the file is well-formed. The pattern transfers. The task changes; the roadmap doesn't.

What This Looks Like Over a Month

Loop engineering isn't a weekend certification. It's a shift in how you work that compounds.

Week one, you build one loop and mostly watch it, learning its failure modes. Week two, you tighten that loop until you trust it unattended, and you build a second one for a different task. Week three, you start scheduling your reliable loops so they run without you, and you feel the first real taste of work getting done while you're elsewhere. Week four, you notice you've stopped thinking in prompts entirely. You think in goals, checks, and exits. When a new repetitive task shows up, your instinct is no longer "how do I do this," it's "what's the definition of done, and what's the verifier."

That instinct is the whole transformation. A prompter reacts to each task by typing. A loop designer responds by designing a small system that handles the task and every future instance of it. One is linear. The other compounds.

The Mistakes That Keep People Stuck as Prompters

A few traps catch almost everyone trying to make this jump.

Automating before understanding. People try to build the loop before they've done the task by hand. They automate a process they can't describe and get fast, confident garbage. Do it manually first, always.

A weak or self-referential verifier. If the model checks its own work with a vague standard, it will always approve itself. The loop feels like it's working while producing junk. The verifier must be strict, specific, and ideally grounded in something outside the model's own opinion.

No termination logic. A loop with no hard exit will either run forever, drain your budget, or spin in circles. Layered exits are not optional. They're the difference between a tool and a runaway.

Skipping state. A loop with no persistent memory starts from zero every time it hiccups. For any long job, state is what makes it survivable.

Removing the human from irreversible actions. The temptation is to let the loop do everything unsupervised. Resist it for anything that can't be undone. The point of loops is leverage, not recklessness.

The Skill Behind the Skill: Developing Taste

Here's what nobody selling you a loop-engineering course will emphasize, because it can't be sold as a quick trick: the hardest and most valuable part of loop engineering is developing taste.

Think about what a verifier actually is. It's your judgment about what "good" means, written down precisely enough that a machine can enforce it. That means the quality of your loops is capped by the quality of your judgment. If you can't tell good output from mediocre output, you can't write a verifier that catches the difference, and your loop will happily produce mediocre work at scale. The loop doesn't have taste. You supply it. The loop just enforces it tirelessly.

This is why loop engineering rewards experienced practitioners so heavily. A senior engineer knows what correct code looks like, so they can write a check that catches subtle wrongness. A great editor knows what strong writing looks like, so they can build a rubric that catches weak drafts. The domain expertise you spent years developing doesn't become obsolete in a loop-engineering world. It becomes the reward function. It becomes the single most leveraged thing you own.

So as you work through this roadmap, invest in your own judgment alongside your technical setup. Study great examples of the work you're trying to loop. Get sharp about what separates excellent from acceptable in your domain. Because every improvement in your taste is an improvement in every verifier you'll ever write, and therefore in every loop you'll ever run. The person with the best taste and the discipline to encode it builds the best loops. That's the real competition, and it's one you win slowly, by caring about quality.

The beginners who struggle with loops usually don't struggle with the commands. They struggle because they've never had to articulate what "good" means before, and a loop forces them to. That difficulty is the growth. Push through it, and you come out not just able to build loops, but clearer about your own standards than you've ever been.

The Honest Truth About Loop Engineering

A loop will not save a task you don't understand.

Every step in this roadmap is really a step toward describing your own work clearly enough that a machine can drive it. The loop is easy. The clarity, the definition of done, the verifier that actually catches failure, that's the hard part, and it's entirely on you. Loop engineering is mostly the discipline of thinking precisely about what good output is and how you'd know it when you saw it.

But that's exactly why this skill compounds. The people who learn to design loops are not going to be replaced by more capable models. They're the ones who point those models at a goal, encode their judgment as a check, and let the system run. As the models get better at long tasks, the person who can design the loop around them gets more valuable, not less.

The movement that named all of this is only a few weeks old.

Which means the window where knowing it puts you ahead of nearly everyone is open right now, today, before it becomes the obvious default.

You can keep typing prompts and waiting for answers.

Or you can design the loop that does the waiting for you.

The first step is step one. Start there.

If you found this useful, follow me @eng_khairallah1 for more AI content like this. I post breakdowns, courses, and tools every week.

hope this was useful for you, Khairallah ❤️