Loop Engineering: The Feedback Loop Matters More Than the Code

What is loop engineering?

Loop engineering is building software around short, repeatable feedback loops: understand the problem, plan, build, test, review, learn, and repeat. With AI coding agents, the engineer’s main job becomes designing the feedback the agent works against.

It isn’t an official methodology. There’s no manifesto or certification. I use the term as a practical name for something good teams already do, which matters more now that an agent can run the build and test steps dozens of times an hour.

Asking an agent to write code and accepting what comes back is one pass through the middle of that loop, with nothing at either end. Nobody checked the problem going in, and nobody checked the result coming out. Loop engineering puts both ends back and makes each step produce a signal you can act on.

The important part is the quality of that signal. An agent that iterates ten times against a weak test suite gets very good at passing weak tests. More iterations don’t make software better. Better feedback does.

We’ve been doing this for decades

Software engineering has always been more than writing code. It’s understanding a problem, making decisions, checking assumptions, delivering something that works and learning from what happens next. Most of our best practices are feedback loops of different lengths:

• Test-driven development: seconds to minutes. Does this function do what I said it would?
• Continuous integration: minutes. Does my change still work with everyone else’s?
• Code review: hours. Does another engineer understand it and agree with the approach?
• Agile iterations: a week or two. Did we build what the business needed?
• Monitoring and observability: continuous. Is it working for real users right now?
• Incident reviews: after something breaks. Why did our other loops miss it?
• Customer feedback: weeks to months. Did it solve the problem?

None of this is new. I made the same argument about design and requirements in forward engineering isn’t new. What’s changing is how fast the inner loops can run, and that puts new pressure on the outer ones.

How AI changes the loop

The traditional loop looks like this:

Engineer → write code → run tests → debug → review → deploy

With an agent like Claude Code or Codex, it looks more like this:

Engineer defines the outcome → AI plans → AI implements → automated validation → AI fixes → human reviews → deploy

The engineer has moved to both ends. More of the time goes into defining the outcome, the constraints and the checks up front, and into reviewing behavior at the end. The middle runs faster than any person could run it.

The last row matters most. When the same agent writes the code and the tests, a green build tells you the two agree with each other. It doesn’t tell you either one matches what the customer needed. That’s why an agent shouldn’t be allowed to keep changing code without checks it can’t influence and a limit on how long it can keep trying.

Vibe coding, agentic engineering and loop engineering

I compared the first two in vibe coding vs. agentic engineering. Loop engineering is the third piece, and it isn’t a separate method so much as the part that makes the second one work.

Agentic engineering asks who does the work. Loop engineering asks how we’ll know the work is right, at every step, and what happens when it isn’t.

When the feedback is wrong

A fast loop with bad feedback produces wrong answers faster. These are the failure modes I watch for:

• The agent fixes symptoms. A test fails, it adds a special case, the test passes, and the bug underneath stays.
• Tests pass but check the implementation, not the business requirement.
• The agent changes unrelated code to make its change fit.
• Each fix adds a layer, and the solution keeps getting more complicated.
• Acceptance criteria were vague, so the agent built a reasonable reading of them that nobody wanted.
• The agent grades its own work, with no independent check.
• An engineer sees green checks and merges without trying the feature.

Here’s a hypothetical that combines several of these. An agent builds appointment booking for a business with customers in more than one time zone. It stores every slot in UTC, and its tests confirm that a booking for 9:00 UTC is saved as 9:00 UTC. Every test passes. The review looks clean. But the booking page shows available slots in the server’s time zone, so a customer three hours away picks “9:00,” thinking it’s their morning, and arrives at the wrong time.

The code did what the tests said. The tests checked storage, and nobody had written down that customers must see slots in their own time zone. A successful execution loop doesn’t mean a successful engineering outcome. The fix starts with an acceptance criterion and a test written from the customer’s side of the screen.

Smaller loops, smaller changes

I prefer small user stories and small pull requests, and AI makes that preference stronger. The bigger the change, the longer the loop, and the more it costs to be wrong. Small changes give you:

• Feedback in minutes or hours instead of at the end of a sprint
• Reviews someone can read carefully
• Less risk per deployment
• Debugging where the cause is one of a few changed lines
• Rollback that undoes one thing
• A team that knows what changed

An agent can produce a 3,000-line pull request in the time it takes to get coffee. Nobody reviews 3,000 lines carefully, so that pull request has effectively skipped review. Continuous delivery depends on keeping each change small enough that the loop closes quickly. I wrote about the team side of this in smaller user stories and pull requests.

What humans still own

AI can help with every item on this list. Accountability for each one stays with the engineering team:

• Understanding the actual business problem
• Architecture decisions, including the ones to not build at all
• Security and compliance
• Acceptance criteria
• Weighing tradeoffs
• Production readiness
• Deciding when a solution is good enough

The last one is easy to miss. An agent will keep improving something as long as you let it. Someone has to decide that the change does what it needs to, at a cost that makes sense, and stop.

A practical loop engineering workflow

Here’s how I’d run a hypothetical feature, letting customers book appointments, with Claude Code or Codex.

The pattern is that people approve direction and agents iterate inside it. Steps 1 to 4 decide what we’re building and how. Steps 5 to 7 are where automated iteration pays off, because the agent is working against checks a person already agreed with. Steps 8 to 10 confirm it worked for a real user.

The guardrails I’d set before step 5:

• Iteration limits. Three attempts at the same failure, then stop and report what was tried. Repeated failure usually means the plan is wrong, and more attempts won’t fix a plan.
• Scoped changes. The plan names the files and directories the agent may change. Anything outside that is a new conversation.
• Independent checks. Tests come from the acceptance criteria and the agent can’t edit them without approval. CI runs them, not the agent’s own report.
• Escalation. When the agent hits a limit, touches authentication or payments, or wants to change a test, a person decides.
• Written instructions. Project rules in a CLAUDE.md or AGENTS.md file, so every session starts with the same constraints.

Review scales with risk. A copy change can lean on automated checks. Anything touching permissions, money or customer data gets a person, which I covered in code review doesn’t start with a pull request. Unlimited loops also cost real money in tokens and time, as I worked through in the hidden cost of AI coding.

What this means for engineering leaders

If AI cuts implementation time, the bottleneck moves somewhere else. On most teams it moves to:

• How clear the requirements are
• Architecture decisions
• Review capacity
• Test quality
• Deployment safety
• Coordination across teams

That changes what to invest in. A team that doubles its code output without improving its tests or adding review capacity has built a bigger queue in front of review.

It also changes what to measure. Lines of code, pull request counts and agent iterations were weak measures before AI, and they’re now trivial to inflate. I’d look at:

• Lead time to deliver useful functionality
• Change failure rate, how often a release causes a problem
• Time to recover when one does
• Escaped defects that customers find before we do
• Rework, changes that exist to fix recent changes
• Customer outcomes, whether the feature solved the problem it was built for

The first three come from DORA’s delivery metrics. All of them describe how well the loop works, which is why they’re harder to game than activity counts. More on how I run teams in how I run engineering.

My perspective

Over more than 20 years in software engineering, I’ve watched the tools change many times: languages, frameworks, infrastructure models, cloud platforms, and now AI coding agents.

The basic problem hasn’t changed. We still need to understand what we’re building, why we’re building it, and whether it works. AI makes each trip around the loop faster. Engineering judgment decides whether those trips are heading somewhere useful.

Short answers