The head of Claude Code at Anthropic recently said, in plain words, that he no longer really writes prompts. His actual job now is writing loops. That phrasing is worth slowing down for, because it captures a shift that has been building quietly across the agentic AI ecosystem for the better part of a year, and that most users have not yet caught up to.
For two years, the dominant AI skill was prompt engineering. Frame the question well, structure the context, give the model good examples, and you got good answers. The skill mattered because the interaction model was conversational. You typed, the model responded, you typed again. The quality of the back-and-forth was bounded by how well you could phrase the front of it.
The trap inside that skill became obvious as soon as you tried to do anything substantial with it. You stayed glued to the screen. You held the model’s hand at every step. You watched it work. You corrected it. You re-prompted. The output was real, but the time you saved was less than advertised, because you were still the rate-limiting step.
Loop engineering is the answer to that trap. A loop is a system that sends prompts on your behalf. You define the objective once. The system finds the work, does it, verifies it, remembers what it completed, picks up the next piece, and continues. You return at the end to a finished result, not a chat history.
What a loop actually is
The cleanest definition: a loop is a self-running execution structure built around a goal rather than a turn. It contains a way to discover what needs doing, a way to actually do it, a way to check whether the result is good, a memory of what has already been done, and a stopping condition.
The shift from prompts to loops is the shift from “ask the model a question” to “give the model a job.” A prompt finishes at the end of its response. A loop finishes when the job is done.
This is not a theoretical construction. It is what a growing share of real production work with frontier models already looks like, especially in code-heavy and research-heavy workflows. The Claude Code team has been building this pattern into the product. The same primitives are now available to anyone using it.
The economic point is sharper than the technical one. A prompt-engineered workflow scales with your attention. A loop-engineered workflow scales with your compute budget. The first is bounded by you. The second is not.
The five primitives that make a loop work
A workable loop comes together from five components. Each one is available in Claude Code today. Configured together, they produce a system that runs on its own.
1. Automation
The first primitive is the thing that makes a loop a loop: it runs without you starting it. Scheduled triggers, file-watcher triggers, webhook triggers, queue-driven triggers. The mechanism matters less than the principle. If you have to type “go” every morning, you have not built a loop. You have built a slightly fancier prompt.
For most people, the entry point is scheduled execution. A task that fires every morning, every hour, or every time a file changes is enough to break the dependency on your attention.
2. Worktrees
The second primitive is parallelism without collision. Two agents working on the same project in the same workspace will overwrite each other’s changes. Worktrees solve this. Each agent gets its own isolated copy of the project state, makes its changes there, and merges back deliberately.
Worktrees are what turn “one agent doing one thing” into “several agents doing several things at once.” The productivity gain compounds with the size of the project. A loop that can fan out across worktrees finishes work in clock-hours that would have taken person-days serially.
3. Skills
The third primitive is project memory. Skills are the part of the loop that stops the agent from asking the same questions about your project on every single run. Stack, conventions, deployment patterns, naming rules, the names of the people whose code review you trust. Once these are encoded as skills, they load automatically on every invocation. The agent stops being a new colleague every morning.
The deeper value of skills is compounding. As you correct the agent over time and those corrections feed back into the skill set, the agent becomes more accurate at your specific work. The loop that runs on month three is materially better than the loop that ran on day one, without any model changing underneath.
4. Connectors
The fourth primitive is access to the actual tools you use. A loop is only as useful as what it can touch. Connectors give the agent reach into the systems where your work actually happens: your repo, your issue tracker, your design files, your documentation, your CRM, your deployment pipeline.
The shift here is from “the agent answers questions about my work” to “the agent does my work.” That sentence rests entirely on having connectors wired up. Without them, you are back to copy-paste.
5. Sub-agents
The fifth primitive is separation of roles. The agent that writes the code is not the same agent that reviews it. The agent that drafts the post is not the same one that fact-checks it. Sub-agents create internal verification by design.
This is the primitive that most users skip on the first attempt at building a loop, and most loops fall over for the same reason. A single agent producing and validating its own work is structurally biased toward declaring the work done. A separate verifier, with its own prompt and its own constraints, is the difference between a loop that ships clean output and a loop that ships confident hallucinations.
Of the five primitives, sub-agents are the highest leverage and the most under-used. Splitting “produce” from “verify” is a small architectural choice with an outsized effect on the reliability of everything downstream. If you build only one of the five well, build this one.
The progression that takes you from prompts to loops
Most people who hear “loop engineering” assume they need to rebuild their workflow from scratch. They do not. The right path is incremental.
Start with a single workflow you do repeatedly. The weekly report. The morning content brief. The recurring code review pass. The task you instinctively reach for as soon as the workday begins. This is the workflow that justifies the time investment in setting up a loop.
Encode the project context as a skill. The agent needs to know what it is working on. Stack, conventions, target audience, anything you find yourself re-explaining. Put it in a skill and stop re-explaining.
Wire up the connectors that workflow needs. If the work involves a repository, connect it. If it involves an email or a chat channel, connect it. If it involves a third-party tool, connect that. A loop that has to bother you for access is a loop that has not actually offloaded the work.
Add a verifier sub-agent. One prompt produces the work. A separate prompt checks it. The verifier’s constraints should be different from the producer’s. If the producer is told “write a useful summary,” the verifier should be told something like “check whether anything important was omitted.”
Automate the trigger. The last step is the one that finally turns the workflow into a loop. Schedule it. Wire it to a webhook. Tie it to a file change. Whatever the trigger, the test is that the loop runs without you starting it.
Five steps, in this order, applied to one workflow at a time. The pattern is repeatable across as many workflows as you have the budget to support.
What loop engineering changes about your role
The interesting consequence of building loops well is what it does to your job description.
The role shifts from operator to designer. You stop typing prompts and start designing systems that type prompts. You stop watching the model work and start watching the loops run. You stop being the rate-limiting step and start being the architect of how many loops can run at once.
This is not a soft change. It is the difference between a knowledge worker who has integrated AI as a faster typing aid and a knowledge worker whose output scales with their compute budget. The first kind of worker is still bounded by hours in the day. The second is not.
Prompt engineering produced people who use AI well. Loop engineering produces people whose AI works while they sleep. The two are not in conflict. The second is the next layer up.
The honest caveats
None of this is free of failure modes, and the loop-engineering approach has a specific set of them worth knowing about before you commit to the path.
Loops fail silently more easily than chats do. A bad answer in a conversation gets corrected on the next turn. A bad output from an unattended loop is the output. If your verifier is weak or your stopping criterion is loose, you get back a confidently completed bad result and no signal that anything went wrong.
Loops cost more than chats. Token consumption goes up linearly with how long the loop runs and how many sub-agents are involved. The economic case is still strong, but the failure mode of an underspecified loop is a large bill for an unsatisfying output. Stopping criteria are not optional.
Loops compound your design choices, including the bad ones. If a skill encodes an incorrect convention, every loop that uses that skill will perpetuate the error at scale. The auditing discipline that used to apply to individual outputs now applies to the loop’s standing infrastructure: the skills, the connectors, the verifiers.
Where to start this week
If the case for loop engineering is convincing and the practical path is unclear, the smallest possible starting move is this. Pick one task you do every week. Encode its context as a skill in Claude Code. Add a verifier sub-agent. Schedule it to run on its own. Watch what happens. Adjust the skill and the verifier based on what you find.
You are not building an empire of autonomous agents. You are removing one task from your weekly attention budget and replacing it with a system that handles it. Repeat the move on the next task. Then the next. The accumulation is where the leverage lives.
The shift from prompt engineering to loop engineering is, in a sense, just the natural continuation of what prompt engineering started. The goal has always been to make the model do useful work with less of your attention. Loops are simply the version of that goal that takes attention out of the loop entirely.
Frequently Asked Questions
What is loop engineering?
Loop engineering is the practice of designing self-running execution systems that complete tasks autonomously, rather than writing individual prompts that require your attention turn by turn. A loop combines automation, parallelism, persistent context, tool access, and verification into a system that operates against a goal rather than a single prompt.
How is loop engineering different from prompt engineering?
Prompt engineering optimizes the conversation between you and the model, one turn at a time. Loop engineering builds systems that hold the conversation on your behalf, running until the work is done. Prompt engineering scales with your attention. Loop engineering scales with your compute budget.
What are the five primitives of a working loop?
Automation (the loop runs without you starting it), worktrees (multiple agents work in parallel without collision), skills (project context loads automatically rather than being re-explained), connectors (access to the actual tools where your work lives), and sub-agents (separation between the agent that produces work and the agent that verifies it).
Why are sub-agents the highest-leverage primitive?
Because a single agent producing and validating its own work is structurally biased toward declaring the work done. Splitting the producer from the verifier is the difference between a loop that ships clean output and a loop that ships confident hallucinations. If you build only one of the five primitives carefully, build this one.
What is the smallest practical starting move?
Pick one task you do every week. Encode its context as a skill. Add a verifier sub-agent. Schedule it to run on its own. Iterate on the skill and verifier based on the results. Repeat with the next task. The accumulation, not the first attempt, is where the leverage lives.
What are the failure modes of loop engineering?
Loops fail more silently than chats do; a bad result without a human in the turn is just the result. Loops cost more, so an underspecified stopping criterion can run up a large bill for unsatisfying output. And loops compound design errors at scale, which means the auditing discipline that used to apply to individual outputs now applies to your skills, connectors, and verifier prompts.
