Loop engineering isn’t new. Don’t reinvent the wheel. | by Jon Wiggins | Jul, 2026
A lone senior developer with no spec, no tests, and no code review ships bugs. Not sometimes. Reliably.
This is why we invented all the ceremonies, the design documents nobody wants to write, the PRs that sit waiting for a second pair of eyes, and the test suite that goes red at the worst possible moment. We didn’t build that machinery because engineers are dumb. We built it because a smart person working alone, unchecked, is unaccountable, and unaccountable and unreliable are the same word wearing different clothes.
A single large language model call is that same lone developer. Brilliant on a good day. Confidently wrong on the same day. And with nothing standing between its first draft and your production codebase.
“Loop engineering”. It’s the term the AI world has landed on for the fix. It sounds exotic. It isn’t. You’re asking the AI agent to perform the tasks that a software team typically spreads across roles:
Specs: Project Owners, Scrum Masters, Developers
Plans: Architects, Developers
Code: Developers
Tests: Developers / Quality Assurance
Review: Different Developer than Author
Loop engineering is the software development lifecycle with different (artificial) staffing.
A team is not an org chart. It’s a set of checkpoints.
Every one of those roles exists because the step before it is known to be unreliable on its own.
- Specs catch the misunderstandings. Before a line is written, someone forces a fuzzy request to become a concrete spec, and any disagreements surface on paper instead of in production.
- Plans catch the architectural dead-end. The “wait, if we do it that way, the migration breaks” that’s cheap now and expensive later.
- Devs produce the artifact. This is the only step most people think of as “the work.” It is the least reliable one.
- Tests catch not only the new artifact, but the remaining codebase. The regression tests. The things that worked yesterday and quietly stopped working today.
- Reviews catch the defects the author is constitutionally blind to, because you cannot proofread your own assumptions.
The spec exists because humans hear or give requirements wrong. The test exists because humans forget edge cases. The review exists because authors can’t see their own blind spots. The team is a chain of error-correcting checkpoints.
No single step has to be trustworthy, because the loop is what’s trustworthy.
Staffing the checkpoints with model turns
Loop engineering in AI means running an agent through those same checkpoints (spec, plan, dev, test, review, fix, approve) with model turns instead of people. And it works for the same reason it has always worked. But the difference between a loop that catches your mistakes and a loop that’s just for show comes down to three mechanical choices.
1. Give every role its own fresh context window.
This is the one people skip, and it’s the one that matters most. If the same conversation that wrote the code also “reviews” it, you don’t have a reviewer, you have an author defending their work. The model has already committed to its choices and now it will rationalize them. It saw the reasoning, so it reviews the intent, not the artifact.
So don’t ask one long thread to do everything. Spin up a subagent for the review and hand it only the diff, cold. No history. No “here’s what I was going for.” A reviewer that never heard your justification reviews like an outsider, or another developer checking a PR that their name goes on, which is the entire point of a reviewer. Fresh context is what makes the checkpoint bite. Same trick for the spec, the plan, the test analysis: isolate the role so it can’t inherit the previous role’s blind spots.
2. Review with a different model family than the one that wrote it.
Shared weights share failure modes. If Claude wrote the code and Claude reviews it, they have the same training, the same instincts, and the same blind spots. The bug the author couldn’t see is often exactly the bug the same-family reviewer waves through.
So cross the streams. Have GPT or Gemini review what Claude wrote. A different family was trained on a different mix, reasons differently, and trips on different things. The disagreements between them are where the true value lies. This is the single highest-leverage upgrade you can make to an AI review loop.
3. Keep the objective steps out of the model’s hands.
The test verdict comes from running the tests, not from an LLM’s confidence that they’d probably pass. The moment the objective check becomes a model’s opinion, the loop stops being a loop.
If you don’t want to wire this by hand, someone already did. The open-source Superpowers skills package encodes this exact discipline. Brainstorm the idea into a spec, turn the spec into a dependency-ordered plan, implement in slices, delegate to subagents, verify before declaring done. It’s a working, inspectable example of the whole loop encoded as skills you can read and modify. Start there, steal the parts that fit, and you’ll internalize the shape faster than any article can teach it.
How do we enable our AI agents to perform these checkpoints?
It’s in the harness.
Where Errorta fits
I got tired of wiring this by hand, examining the agents and their sub-agents to check for context and bias, and then re-prompting again and again through the loop. So I built errorta.app. An open-source harness that pulls your AI agents together, wherever they sit, and makes them act as individuals with their own role responsibilities inside the lifecycle.
Errorta’s own development runs as an AI software team (Coding Council). A feature doesn’t go from idea to shipped in one heroic generation. It moves through the checkpoints, each with a fresh context window and tailored information for the task at hand, provided by a PM agent:
- A spec turn writes down what the feature must do and where it must fail closed.
- A plan turn slices it into dependency-ordered work.
- Dev turns write the actual bytes.
- A test run (deterministic, not model-graded) has to pass.
- An independent (different model family encouraged), adversarial review turn tries to find the rubber-stamp hole, the fail-open edge, the case where the thing quietly lies.
- Only then does it get accepted, and only then does it get verified live against a real running build.
If I stopped here it would be a hype piece, and you’d be right not to trust it.
The rub: loops that don’t bite
A checkpoint that always says yes is worse than no checkpoint at all, because it manufactures false confidence. This is the failure mode that will eat your AI team alive: a reviewer turn that approves everything, a test step that passes easily, an approve gate that’s cosmetic. You get all the ceremony of a loop and none of the error correction, and now you’re shipping bugs.
The hardest engineering in loop engineering is not adding the loops. It’s making the loops bite.
- Fail closed, always. When a verification step can’t actually verify (the process crashed, the head is stale, the sandbox failed to launch) the answer is “not done,” never a hopeful default. An inability to check is a block, not a pass.
- Make the reviewer adversarial by construction. Its prompt isn’t “does this look fine?” It’s “find the hole. Assume it’s broken. Prove it ships anyway.” A reviewer told to approve will approve.
- Never let a model grade its own homework. Objective verdicts come from execution, not opinion. The moment the test result becomes a model’s belief about the test result, the loop stops being a loop.
Those three rules are the difference between a loop that catches your mistakes and a loop that co-signs them. I learned them the way everyone learns them, by watching a rubber-stamp slip through and having to go build the gate that stops the next one.
Errorta isn’t the be-all end-all. It’s an open-source guardrail that pushes your AI agents through the loop that software teams have trusted for decades, because the loop was never about the people. It was always about the checkpoints.
