What Is Loop Engineering?
Take on the new term loop engineering (the shift from prompt→context→harness→loop, traced to Boris Cherny and Peter Steinberger), put on one table with TDD/SDD. TDD/SDD are the source of truth; loop engineering is the wiring of the iteration, and TDD/SDD are exactly the verify-and-stop step inside the loop. Maps onto my own Spectra (SDD plus a human reviewer) and Rails (the substrate that makes loops converge). Closes with the honest doubt: is this just hype to make you burn more tokens? Answer: it cuts both ways. The marketing version (more autonomy) burns tokens, the engineering version (faster convergence, stop when you should) saves them.
There's a new term going around: loop engineering. It doesn't try to replace anything. It just gave me a clean way to explain why my way of building software fits AI coding so well.
Where the term comes from
It's an evolution. The attention keeps moving from "how do I ask once" toward "how do I design a loop that converges on its own":
- Prompt engineering: get the single question right.
- Context engineering: how you assemble the whole bundle of context you feed the model.
- Harness engineering: wire the model to tools and an environment so it can act and get feedback.
- Loop engineering: design the loop the agent runs round after round, deciding when to keep going, when to stop, and what feedback each pass uses to correct itself.
The lineage roughly traces to Boris Cherny (Claude Code) and Peter Steinberger (OpenClaw, the predecessor to NanoClaw).
How it differs from TDD/SDD
A lot of people assume it's here to replace TDD/SDD. It isn't. They live on different layers.
| Aspect | TDD / SDD | Loop engineering |
|---|---|---|
| Source of truth | Green tests / the spec | Doesn't provide one; relies on external signals |
| What the human does | Write tests, review the spec, define right vs. wrong | Design the loop, set the stop condition, watch the critical decisions |
| What the agent does | Code until it passes / build to spec | Run round after round: act, get feedback, correct |
TDD and SDD both answer "what counts as correct," so they're the source of truth. Loop engineering answers "how do I run round after round, and when do I stop," so it's the wiring of the iteration. They aren't rivals: TDD/SDD are exactly the "did this pass, can we stop" check at the end of every loop. Without a clear source of truth, the loop can't stop, it just spins.
One practical takeaway: the clearer your source of truth and the cheaper/faster your feedback, the more easily the loop converges, and the more automation you can safely hand it. If you want more automation, don't chase a "smarter agent." Invest in better verification signals.
flowchart TD
Spec["Source of truth<br/>SDD spec / TDD tests"]
Act["Agent acts"]
Feedback["Get feedback<br/>tests / types / lint"]
Check{"Correct?<br/>(verify = stop condition)"}
Human["Human in the loop<br/>gate by risk"]
Done["Converged: stop"]
Spec --> Act --> Feedback --> Check
Check -->|No| Act
Check -->|Yes, high risk| Human
Human -->|Approve| Done
Human -->|Send back| Act
Check -->|Yes, low risk| Done
Mapping onto my Spectra and Rails
My everyday setup lines up with this exactly. Spectra's discuss → propose → apply → archive is essentially "SDD plus a human reviewer." Rails is what makes the loop converge: conventions shrink the action space, tests make feedback arrive in seconds, the monolith keeps the context whole, and Kamal turns deployment itself into a converging loop. The three things loop engineering needs (a small action space, cheap feedback, complete context) are all baked into Rails already.
There's one dimension people overlook: the cost to start a loop. NanoClaw runs on a Raspberry Pi and I drive it from Discord, so I can kick off a round from my phone on the train: draft an article, test an idea, or squeeze something overlong down to a length people will actually read (this piece got trimmed exactly that way). The lower the barrier, the more rounds you can run in a day.
Is this just hype?
Honestly, my first instinct was that the term smells like a nudge to burn more tokens. That doubt is half right. The agentic-AI crowd does have a tailwind that says "let the agent run a few more rounds," and there's a commercial incentive behind it: the people selling tokens are happy to see "just let it loop" become best practice. But the other half is the opposite: doing this craft seriously means making the loop converge faster and stop sooner, which saves tokens. What actually burns tokens is the un-engineered loop that spins without converging. So it cuts both ways:
- Marketing version: give the agent more autonomy, let it run. Burns tokens.
- Engineering version: shrink the action space, make verification cheap, set a clear stop condition. Saves tokens.
The test is simple: ask whether a given practice makes your loop "stop in fewer, clearer rounds" or "gives it more autonomy to keep running." And how far you open that dial should be decided by risk: in healthcare, where patient safety is on the line, the human stays inside the loop at the critical decisions.
One line to close
Loop engineering didn't overturn how I work. It just turned "Spectra defines right and wrong, Rails makes the loop converge, the human gates by risk" into a frame I can state clearly. Don't get pulled along by the buzz: the value isn't "let the agent run more," it's "make every round cheap, make it converge, and stop when you should."
