There's a new slogan going around, and it's a good one: you shouldn't be prompting coding agents anymore — you should be designing loops that prompt your agents. Peter Steinberger said it. Boris Cherny, who runs Claude Code, said the same thing in different words: "I don't prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops."

I think they're right about the direction. I'm also skeptical, in the specific way you should be skeptical of anything that lets you stop paying attention.

But skeptical isn't the same as sitting it out. The leverage point is moving, and it's the kind of shift that compounds — the distance between people who learn to design loops well this year and people still typing prompts one turn at a time is going to be a lot harder to close later than it is to start closing now.

So here's where I've landed after running this on my own portfolio for a while — not "here are five shiny capabilities," but the one thing that actually decides whether a loop is leverage or a liability.

The short version: a loop is only as good as the skills it calls and its ability to check its own work, and it is only safe if it halts. Everything else is downstream of that one sentence.

What loop engineering actually is

For two years the deal was simple. You write a good prompt, you share enough context, you read what comes back, you type the next thing. The agent is a tool and you are holding it the entire time, one turn after another.

Loop engineering replaces you — the person typing the next turn. You build a small system that finds the work, hands it out, checks it, writes down what's done, and decides the next thing — and you let that system poke the agents instead of you. You design it once. You don't prompt the steps.

The canonical loop is five pieces plus a memory: a heartbeat (something on a schedule or a condition that does discovery on its own), worktrees (so parallel agents don't step on each other's files), skills (your project knowledge written down so the agent doesn't re-guess it every run), connectors (so the loop can touch your tracker, your DB, your CI), and sub-agents (so the one who makes isn't the one who checks). Plus a memory on disk — a file, a board, a tracker — because the model forgets everything between runs, but the repo doesn't.

That list is real, and the tools ship all of it now. But the list describes the machinery and says almost nothing about the governance. A loop with all five pieces and no eval is just a faster way to generate confident mistakes. A loop with all five pieces and no halt is a billing surprise with a progress bar.

Why I think a governed SDLC is the right substrate

I wrote a while back about why I stopped treating Claude Code as a tool and started treating it as an engineering team — tickets, reviews, QA, merge gates. That setup became ApexYard, the open-source framework I run my whole portfolio through (code at github.com/me2resh/apexyard). The thing I didn't fully appreciate at the time is that a governed SDLC turns out to be exactly the substrate a safe loop needs.

Most people reaching for loops have to invent two things from scratch: a library of reusable skills, and a way for the loop to grade its own output. A governed SDLC already has both — and that's the catch most people hit. The machinery (worktrees, sub-agents, a scheduler) is the easy part; the governance is the moat, and building a real skill library and eval layer from zero is months of work. It's why so many loop experiments look great in a demo and quietly stall before production.

That's the gap I'd point you at. ApexYard ships both prerequisites — the skill library and the eval layer — MIT-licensed (code at github.com/me2resh/apexyard). You can start designing safe loops this week instead of spending a quarter building the scaffolding that makes them safe. The point isn't "use my thing" — it's that you shouldn't have to re-derive governance everyone needs and almost nobody enjoys writing.

• The skill library — the named commands the loop calls (/migration, /decide, /code-review, …). A loop that calls a skill inherits the policy baked into it instead of re-deriving "how we do migrations" in fresh prose every tick.
• The eval layer — and this is the part nobody has lying around. An automated code reviewer on every PR. An architecture reviewer on design changes. A security reviewer that fires on auth/crypto diffs. CI running lint, types, tests. A QA gate that verifies acceptance criteria. And a merge gate that refuses to merge without two reviews at a matching commit SHA.

That second list is the loop's verifier — already wired, already adversarial. I didn't have to build "is it done?" The SDLC already answers it: done means the reviewer approved, CI is green, coverage holds, and a human said ship it.

So when I added looping to my own setup, I didn't build a new engine. I added a rule that says when to reach for a loop and binds every loop to those existing gates as its eval. The guardrails are the whole point — I'll get to them.

A war story, from building this

Here's the moment that made the guardrails real for me.

I had a multi-view UI redesign — nine screens to rebuild onto a shared component library. Same build-then-verify cycle, nine times. Textbook loop. So I fanned the eight remaining views out across parallel agents, each in its own worktree, eight redesigns at once. It worked. The build was green across all of them.

But the loop's verify stage ran only the build — not the test suite. One shared component injected its styles through a hook that crashed under the test runner, and several view tests were left red. The loop reported success because the build passed. The broken tests landed as cleanup afterward.

That is the lesson made tangible: "verify" has to mean build and tests and a review — not just a green build. A loop that skips its own test step won't get caught until the PR gate, by which point the cleanup cost has already landed.

The guardrails

Every loop I run now has to state these up front. They are the actual content of the discipline:

1. Halt at the human gate. A loop may build, test, and review — but it stops at the per-PR merge approval and hands back. It never approves its own merge. This is the load-bearing one, and I enforce it mechanically: the merge gate won't let a merge through without both a reviewer approval and a human approval at a matching SHA.
2. Verify means build + tests + review — not just build. (See above. Scar tissue.)
3. A budget and an iteration ceiling. Set a max iteration count and a token ceiling before you start. The expensive part of modern AI work is the loop, not the model — most of the engineering is making it stop.
4. No-progress detection. Stop after a couple of rounds that produce nothing new, instead of spinning.
5. Call named skills, not re-derived prompts. A loop that re-explains your conventions every iteration is burning budget and drifting from policy.

If you offer a loop without naming these, you didn't propose a loop. You proposed a runaway.

What the loop still doesn't do for you

The loop changes the work. It doesn't delete you from it. And three problems get sharper as the loop gets better, not softer.

Verification is still on you. A loop running unattended is a loop making mistakes unattended. The separate reviewer and the merge gate exist to make "it's done" mean something — but "done" is still a claim, not a proof. Your job is to ship code you confirmed works.

Comprehension debt compounds faster. The faster the loop ships code you didn't write, the wider the gap between what exists and what you understand. A smooth loop grows that gap faster unless you read what it made.

Cognitive surrender is the comfortable failure. When the loop runs itself, it's tempting to stop having an opinion and take whatever comes back. Designing the loop is the cure when you do it with judgement — and the accelerant when you do it to avoid thinking. Same action, opposite outcome.

That last point is the whole game. Two people build the identical loop and get opposite results. One moves faster on work they understand deeply. The other avoids understanding the work at all. The loop can't tell the difference. You can.

This is exactly why I refuse to make the merge gate skippable by the loop. The mandatory human nod isn't ceremony — it's the designed-in moment that forces me back into the decision. You can automate the build, the test, the review, the draft PR. You cannot automate the ship it. On purpose.

Build the loop. Stay the engineer.

I think this is a genuine preview of how the work evolves. I also know that if I leaned entirely on the loop to fix what the loop broke, my quality would spiral and I'd dig the hole faster than I could climb out of it.

So set up your loops. But don't forget that prompting directly is still effective, and the balance is yours to strike. Cherny's point was never that the work got easier — it's that the leverage point moved. That's what makes loop design harder than prompt engineering, not easier: the failure modes are quieter and the budget is bigger.

"Harder," though, isn't "optional." This shift is already underway, and it's the compounding kind — every month you spend designing good loops widens the distance from where you'd be still prompting by hand. The only real choice is whether you arrive deliberately, with the guardrails in place, or arrive late and spend that lead cleaning up after a loop you let run without them. Starting early and governed is the whole win. That's the gap ApexYard exists to close — so you can be early without being reckless.

Build the loop. But build it like someone who intends to stay the engineer — not just the person who presses go.

---

The loop-mode rule, the merge gates, and the rest of the governed SDLC in this post are open source. ApexYard is at yard.apexscript.com — code at github.com/me2resh/apexyard (MIT).