Stop Prompting AI. Start Engineering Loops.
Why AI coding is moving from better prompts to better loops.
There is a new phrase floating around the AI coding world, and it sounds just irritating enough to become important.
Loop engineering.
Naturally, it has arrived with the usual smell of fresh terminology, LinkedIn smoke, and people who discovered a while-loop last Tuesday and are now calling themselves architects of autonomous cognition. But underneath the nonsense, there is a real shift happening.
Peter Steinberger, the creator of OpenClaw and now at OpenAI, has been talking about coding through agent loops. Boris Cherny, the creator of Claude Code, has said roughly the same thing: the interesting work is no longer writing prompts by hand. It is designing loops that prompt, test, revise, delegate, and continue until the target is reached. This sounds glamorous. It is not. It is mostly project management, testing discipline, context hygiene, branch isolation, and the terrifying discovery that your AI agent can spend money faster than a footballer in Monaco. Still, it matters. Because this is where AI-assisted development starts moving beyond “vibe coding.”
Vibe coding is you sitting in front of Claude or Codex saying, “Make the button less ugly,” then watching the machine change twelve files, break the login flow, and proudly announce that the user experience has been improved.
Loop engineering is different.
Loop engineering says: define the goal, give the agent tools, make it plan, make it execute, make it verify, make it log what happened, and make it repeat until the goal is actually satisfied.
In other words, stop treating the model like a magic text box.
Start treating it like a very fast junior team that needs objectives, constraints, tests, supervision, and a place where it is allowed to make a mess without destroying the main branch.
What Is an Agent Loop?
At the simplest level, an agent loop is a cycle. The user gives the system a goal. The agent plans how to achieve it. It performs actions. It checks whether the goal has been achieved. If yes, it reports back. If not, it changes the plan and tries again.
That is the whole machine. Not magic. Not consciousness. Not the singularity wearing a hoodie. A loop. The interesting part is what gets placed inside it.
A useful coding loop might look like this:
Receive a measurable goal.
Inspect the codebase.
Build a plan.
Create or assign subagents.
Implement changes.
Run tests, type checks, builds, benchmarks, or other validators.
Log what happened.
Judge whether the goal is complete.
If not complete, revise the plan and continue.
If complete, summarize the result for the human.
This is the logic behind /goal-style workflows in tools like Claude Code and Codex. You are no longer writing every intermediate prompt yourself. You are giving the agent a target and letting the system generate its own intermediate prompts, actions, checks, and revisions. That is the shift.
Prompt engineering was about what you say to the model.
Loop engineering is about the process that keeps talking to the model after you stop typing.
The Goal Is the Steering Wheel
The secret to loop engineering is almost insultingly boring. Write better goals. This will disappoint anyone hoping for a mystical framework involving Sanskrit, transformers, and a $499 course. But it is true. If you have ever managed a team, you already know the concept: SMART goals. Specific, measurable, achievable, relevant, and time-bounded.
Agents need the same thing, except they also need explicit permission boundaries, test criteria, file scope, cost limits, and a stern reminder not to redesign your entire application because a sidebar component looked at them funny.
A bad goal looks like this: “Improve the frontend.” This is not a goal. This is a weather condition.
A better goal looks like this: “Optimize the frontend so that every route in the app loads in under 100ms in the local benchmark. Do not change the visual design. Preserve all public APIs. Add benchmark results to performance-report.md. Stop after three failed attempts and explain the blocker.”
Now we are getting somewhere. The agent knows what success means. It knows what not to touch. It knows where to record progress. It knows when to stop. That last part is important. Without a stopping condition, an agent loop can become a token-powered combine harvester, chewing through your repo, your budget, and your patience while confidently “improving architecture.”
Testable Goals vs Judged Goals
There are two broad kinds of goals.
The first type can be tested.
“Make all unit tests pass.”
“Reduce bundle size by 20%.”
“Make every page load in under 100ms.”
“Fix this bug and add a regression test.”
These are excellent loop targets because the agent can verify them mechanically. It runs the test. The test passes or fails. There is less room for self-congratulation.
The second type must be judged.
“Rewrite this article so it is ready for the front page of Forbes.”
“Improve the onboarding flow.”
“Make this documentation clearer for non-technical users.”
Now the agent needs evaluation. Usually this means LLM-as-a-Judge, a separate evaluator prompt, or a human review step. This is where things get slippery.
Models are often extremely impressed with their own work. Ask a model whether its revised essay is now clear, compelling, and polished, and it may respond like a proud parent at a school play. Magnificent. Elegant. Publication-ready. Slightly longer than War and Peace, but otherwise perfect.
So if you use LLM-as-a-Judge, split the roles. Do not let the same agent plan, implement, and applaud itself.
Use at least three agents:
Researcher: inspects the codebase, sources, requirements, or context.
Implementer: makes the changes.
Evaluator: judges the output harshly against explicit criteria.
The evaluator is the adult in the room. Make it strict. Make it dull. Make it allergic to vague success. A friendly evaluator produces beautiful disasters.
Loops Are Not New. They Are Newly Packaged.
A careful reader may now ask: “Isn’t this just agentic development?” Yes. Mostly. If you were already building serious agent workflows, none of this is cosmically new. You already had planners, workers, reviewers, test runners, memory files, evaluation harnesses, and retry logic.
What changed is packaging.
Previously, only advanced users built these workflows deliberately. Now tools like Claude Code and Codex are surfacing the pattern more directly. The idea becomes accessible. The command becomes a habit. The habit becomes a meme. The meme becomes a methodology. The methodology becomes a consultant deck by lunchtime. That does not make it fake. It just means the interface finally caught up with the pattern.
The Real Skill: Designing the Loop
A good loop is not “let the agent work until it feels done.”
That is how you get a pull request with 97 files changed, three new abstractions, a broken migration, and a note saying “improved maintainability.” A good loop has design. Here are the decisions that matter.
1. Trigger: Who Starts the Loop?
Some loops are manual. - You start them when you want a task done. Fix this bug. Refactor this module. Draft this report.
Some loops run on a schedule. - Every morning, scan the repo for failing tests. Every Friday, generate a changelog. Every night, optimize documentation or review open issues.
Some loops are event-driven. - A GitHub issue appears. A test fails. A customer support ticket arrives. A new file is uploaded. A benchmark drops below threshold.
Choose the trigger based on the job. Do not automate things just because you can. That is how people end up with an AI agent opening tickets about tickets opened by another AI agent.
2. Branches: Give Every Loop Its Own Sandbox
If you run multiple loops in parallel, isolate them.
One branch per feature.
One worktree per agent.
One folder per experimental task.
Do not let four agents hammer the same repo at the same time unless you enjoy archaeology. They will overwrite each other, duplicate work, break assumptions, and produce a merge conflict that looks like a crime scene.
Parallel loops are powerful. Parallel loops in the same workspace are raccoons in a kitchen.
3. Skills: Stop Making Agents Rediscover Your Project
Skills are one of the least glamorous and most useful parts of this workflow. A skill is a reusable instruction pack: how to run tests, how the repo is structured, how deployment works, what style rules matter, where logs live, which commands are safe, which commands are forbidden.
Without skills, every agent begins life as a tourist. It wanders around the repo. It reads package.json. It guesses the test command. It discovers linting. It runs the wrong script. It apologizes. It tries again. This burns context and tokens.
Before putting loops on top of your project, create skills. Give agents a map before asking them to drive.
4. Tools, Plugins, MCP: Give the Loop Real Hands
A loop without tools is just a model thinking very hard in a padded room. If the task requires code changes, the agent needs file access, shell access, test commands, package manager commands, Git operations, and maybe browser automation. If the task requires research, it needs source access, web search, database queries, internal docs, or APIs. If the task requires production work, it may need deployment tools, logs, monitoring, or issue trackers. But tools are also risk.
Give too few tools and the loop becomes useless. Give too many tools and you have built a caffeinated intern with root access.
Tool access should be deliberate. The agent should have exactly what it needs, not a chainsaw because gardening is technically plant-related.
5. State: Write Down What Happened
Long loops need memory outside the context window. This is not optional.
If a loop may run for many iterations, create a state file. A simple markdown file is often enough.
Something like: agent-state.md
It should record: Current goal. Plan. Completed steps. Failed attempts. Test results. Important decisions. Known blockers. Next action. This prevents the agent from slowly becoming a goldfish as the context fills up.
Without state, long loops forget what they already tried. Then they repeat themselves. Then they contradict themselves. Then they proudly solve the problem they created three iterations earlier.
Logs are not bureaucracy. Logs are how you prevent an autonomous system from developing amnesia.
6. The Minimum Loop Rule
Make loops small. This is the rule people will ignore, because it is no fun.
Everyone wants the mega-loop.
“Build my app.”
“Rewrite the whole documentation system.”
“Refactor the backend.”
“Launch a startup.”
No. Make the loop smaller.
“Implement password reset email flow.”
“Refactor the billing service without changing public API.”
“Add tests for the import parser.”
“Rewrite the onboarding docs for first-time users.”
Small loops finish. Small loops can be reviewed. Small loops produce understandable diffs. Small loops fail in ways you can diagnose. Mega-loops create civilizations. Then they collapse.
7. Avoid Understanding Debt
This is the danger nobody wants to discuss. Agent loops can produce work much faster than you can understand it.
At first, this feels incredible. Code appears. Docs appear. Tests appear. Screens appear. Entire subsystems emerge overnight like mushrooms after rain. Then, one day, something breaks. You open the codebase and realize you do not understand the architecture anymore. There are thousands of lines of agent-written logic, helper functions, abstractions, generated conventions, and subtle dependencies. The machine has been moving faster than your mental model. Congratulations. You have understanding debt. It is worse than technical debt because you cannot even describe the thing you need to fix.
The solution is not to stop using agents. The solution is to remain the architect. Let agents implement architecture. Do not let them own it. After every serious loop, review not only the result, but the path.
What files changed?
Why were those decisions made?
What assumptions did the agent introduce?
Did it create new abstractions?
Did it move responsibility somewhere unexpected?
Is the solution simpler or just larger?
A loop that delivers working code but destroys your understanding of the system has not saved time. It has taken out a loan. The interest will be paid later, usually at 2 a.m.
The Loop Around the Loop
LangChain has an interesting way of framing the next stage: build loops that improve loops. This sounds ridiculous, like putting a turbocharger on a blender. But the idea is not stupid.
Every agent run produces traces. Those traces show where the agent hesitated, failed, repeated itself, used the wrong tool, misunderstood the goal, or needed human rescue.
A higher-level loop can inspect those traces and improve the system. Better prompts. Better skills. Better evaluators. Better tool access. Better stopping rules. Better decomposition. This is the hill-climbing loop: not just using agents to do work, but using the evidence from each run to improve the agent system itself.
That is where loop engineering becomes real engineering. Not “the model did something.” But “the system improved because the last run produced measurable evidence.”
The Practical Template
Here is a useful loop prompt skeleton: /goal
Objective: [One measurable outcome.]
Scope: [Files, folders, features, or documents the agent may touch.]
Constraints: [What must not change.]
Success criteria: [Tests, benchmarks, review criteria, or evaluator rubric.]
Process:
Inspect the current state.
Write a short plan.
Implement the smallest viable change.
Run validation.
Log each attempt in [state file].
If validation fails, revise the plan and retry.
Stop after [N] failed attempts or [budget/time limit].
Return a final summary with changed files, validation results, and remaining risks.
Agents:
Researcher: understand context and constraints.
Implementer: make changes.
Evaluator: judge against success criteria.
Safety:
Do not modify unrelated files.
Do not introduce new dependencies without approval.
Do not run destructive commands.
Ask for confirmation before migrations, deletions, or production actions.
This is not beautiful prose. It is better. It is operational.
What This Means for Coding
The future of AI coding is not a person typing ever more elaborate prompts into a chat window. That phase was useful. It taught us what models can do. It also taught us that humans are terrible at supervising high-speed machines one prompt at a time.
The next phase is systems. Loops. Goals. Evaluators. State files. Worktrees. Skills. Tool access. Human approval gates. Trace analysis.
This will not remove the engineer. It will change the engineer’s job.
Less typing every line. - More designing the environment in which useful work can happen.
Less “please write this function.” - More “here is the goal, here is the architecture, here is the test, here is the boundary, here is how you know you are done.”
That is a very different skill. It is also why “vibe coding” is starting to sound too small. The serious version is not vibes. It is delegation. And delegation has always required management.
The only difference is that now your team can run at 3 a.m., spawn subagents, burn tokens like aviation fuel, and confidently refactor the authentication system unless you told it not to. So yes, loop engineering is a real thing. But the trick is not to build the biggest loop.
The trick is to build the smallest loop that can safely finish the job. Then improve the loop. Then improve the loop that improves the loop. And somewhere around there, you may discover that software development has not become easier.
It has become stranger.
Source worth reading: https://www.langchain.com/blog/the-art-of-loop-engineering#level-4-hill-climbing-loop
You are right that the real shift is from writing prompts to designing the loop, and the boring secret is just writing good goals with a clear stopping condition. That part is hard to argue with. The piece I keep coming back to is understanding debt. A loop can pass every test and still leave you owning a system you can no longer explain. Tests catch broken code. They do not catch a mental model that quietly fell behind. So the stopping rule I trust most is not N failed attempts. It is the point where I stop being able to review the path.