Loop engineering vs prompt engineering comes down to one thing: what you’re optimizing. Prompt engineering is about writing a single, well-crafted instruction to get a good response from an AI model. Loop engineering is about designing a self-running system where an AI agent acts, checks its own work, and repeats until it hits a defined stopping condition — with little to no manual prompting in between.
Loop engineering = designing a self-running system where an AI agent acts, checks its own work, and repeats until it hits a defined stopping condition — with little to no manual prompting in between
Prompt engineering = writing a single, well-crafted instruction to get a good response from an AI model
Why this comparison exists?
A few months ago, “loop engineering” wasn’t a term anyone used. Then Boris Cherny, who leads Claude Code at Anthropic, said something that spread fast through developer circles: he doesn’t write prompts for Claude directly anymore. His job, he said, is to write loops.
That’s a strange thing to hear from the person who built one of the most-used AI coding tools around. It’s also the reason this comparison is worth writing. If the person closest to how Claude actually gets used day to day has stopped prompting and started looping, it’s worth understanding what changed and whether the same shift applies to how you work with AI.
Short version: it doesn’t replace prompting. It changes what you’re optimizing.
What is prompt engineering?
Prompt engineering is instruction design for a single exchange. You write a prompt, the model responds, and if the response isn’t right, you rewrite the prompt and try again. The skill lives in the wording, structure, examples, and context you pack into that one message — techniques like few-shot examples, chain-of-thought instructions, and role framing all live here.
It works well when a task fits inside one response: draft this email, summarize this document, classify this ticket. The human stays in the loop at every step, reviewing and adjusting.
What is loop engineering?
Loop engineering is designing the system around repeated model calls, not the wording of any single call. Instead of you manually re-prompting after each output, you build a loop: the agent takes an action, checks the result against some condition, and either stops or tries again — on its own, sometimes for hours or days without a human checking in on every step.
The pattern has a name because Anthropic made it an official product feature. In June 2026, Claude Code shipped native /loop and /goal commands, turning what developers had been hand-rolling with bash scripts into a supported capability with proper stopping conditions and tool integration built in. /goal lets a developer specify a desired outcome and let the agent run in a loop until it actually reaches that outcome, rather than stopping after one pass.
Anthropic’s own description of the pattern breaks a loop into a repeating cycle: gather only the context the next step needs, take an action, check the result against a verification gate, and repeat — inside a sandbox that limits how much damage a bad iteration can cause while nobody’s watching.
Why loops work better now than they did a year earlier
Loop-style agent patterns aren’t new — a rough version of this, sometimes nicknamed the “Ralph” loop, showed up in developer workflows back in 2025. Back then, models often needed many iterations to stumble toward a correct answer, so looping mostly compensated for unreliable single-pass output. By mid-2026, stronger models frequently get most of the way to a correct answer in one well-scoped pass. That shifted the hard part of the job: it’s no longer “get the model to produce something reasonable,” it’s “verify that what it produced is actually correct before letting it move on.” Most current loop-engineering practice is really verification-gate design wearing a new name.
Loop engineering vs prompt engineering: side-by-side
| Prompt engineering | Loop engineering | |
| What you design | A single instruction | A repeating system of actions and checks |
| Human involvement | Reviews and edits after every response | Sets it running, checks in at defined gates |
| Unit of optimization | Wording, examples, structure of one prompt | Stopping conditions, verification gates, context passed between steps |
| Best for | One-off tasks: drafting, summarizing, classifying | Multi-step, long-running work: refactors, research, bulk content generation |
| Failure mode | A vague or ambiguous prompt produces a vague answer | A loop without a good stopping condition burns time and tokens without ever finishing |
| Core skill | Instruction clarity | Systems design and verification |
| Example tool | Any chat interface | Claude Code /loop, /goal |
A concrete example
Prompt engineering approach: You ask Claude to fix a failing test, read the output, notice it missed an edge case, and ask it to fix that too. You’re driving every step.
Loop engineering approach: You set a goal — “make this test suite pass” — with a verification gate (the tests actually running green) and a sandbox that limits what the agent can touch. The agent runs the tests, sees what fails, fixes it, reruns the tests, and repeats until the gate passes or it hits a limit you set. You check in once the loop finishes, not after every attempt.
The second approach only works because the verification gate is solid — “tests pass” is unambiguous. Loop engineering tends to fail quietly when the stopping condition is fuzzy (“make the code good”), because a model looping against a vague target will happily convince itself it’s done.
When to use ?
Reach for prompt engineering when:
- The task fits in one exchange and you want to review the result yourself
- The stakes are high enough that you want a human checking every step
- You’re exploring or drafting something where “good enough” is a judgment call, not a testable condition
Reach for loop engineering when:
- The task is repetitive or long-running — a multi-file refactor, a research pass across dozens of sources, generating variations at scale
- You can define a clear, checkable stopping condition (tests pass, a schema validates, a word count is hit)
- You’re willing to trade step-by-step control for throughput, inside a sandbox that limits the blast radius if something goes wrong
In practice, most real workflows use both. You still write clear prompts inside each step of a loop — loop engineering doesn’t remove the need for good instructions, it just moves most of the re-prompting from you to the system itself.
What loop engineering doesn’t change
It’s worth being direct about this: loop engineering hasn’t made prompt engineering obsolete, and treating it that way is the most common mistake showing up in early adoption. A loop is only as good as the instructions running inside each cycle of it. A sloppy prompt run in a tight loop just produces sloppy output faster and with less oversight. The skill of writing clear, specific, well-scoped instructions is still the foundation — loop engineering adds a layer of system design on top of it, it doesn’t substitute for it.
FAQs
Is loop engineering replacing prompt engineering?
No. Loop engineering is built on top of prompt engineering, not instead of it. Every step inside a loop is still a prompt — loop engineering just automates the cycle of running, checking, and re-running that a human used to do by hand.
What is the /loop command in Claude Code?
It’s a native feature Anthropic shipped in June 2026 that lets an agent run a repeating cycle of action and verification automatically, instead of a developer manually re-prompting after each result. A related command, /goal, lets you specify an outcome and have the agent keep working until that outcome is verifiably reached.
Do I need to know how to code to do loop engineering?
Mostly, yes, at least right now. Loop engineering involves setting up verification conditions, sandboxing, and often scripting how an agent’s output gets checked — that’s more of a systems-design skill than the conversational prompting most non-developers use. Prompt engineering fundamentals remain accessible without coding.
Why did loop engineering suddenly become a big topic in 2026?
Because Anthropic made it official. Boris Cherny, who leads Claude Code, said publicly that he’d stopped prompting manually and started designing loops instead. Shortly after, the pattern got a name, and Anthropic shipped native /loop and /goal support in Claude Code, turning a developer workaround into a supported feature.
What’s the biggest risk with loop engineering?
A poorly defined stopping condition. If the verification gate is vague, a looping agent can run for a long time without actually finishing the task correctly, burning tokens and, in coding contexts, potentially making unwanted changes across a codebase before anyone checks in. That’s why sandboxing and clear, testable gates matter more in loop engineering than in single-prompt work.
Which skill should I learn first?
Prompt engineering. Loop engineering depends on being able to write a clear, well-scoped instruction — you’re just running that instruction inside a system instead of typing it fresh every time. Skipping straight to loops without solid prompting fundamentals tends to produce loops that fail in confusing ways.
Conclusion
The two skills aren’t competing for the same job. Prompt engineering gets one instruction right. Loop engineering gets a whole system of instructions to keep correcting itself without you standing over it. Anthropic didn’t retire prompting when it shipped /loop and /goal — it built loop tooling on top of the same instruction-writing discipline that’s been there since GPT-3, because a loop full of vague prompts just fails faster and with less supervision.
If you’re deciding where to spend your time: get comfortable writing clear, specific prompts first. That’s still the foundation, and it’s the part that transfers everywhere — chat interfaces, agent loops, RAG pipelines, all of it. Once that’s solid, loop engineering is less a new skill to learn from scratch and more a question of systems design: what’s the stopping condition, what’s the sandbox, what happens when the agent is wrong three iterations in. Anthropic making /loop a native command doesn’t mean every task needs one. Plenty of work is still better done one prompt at a time, with a human actually reading the output before it ships.
