The Loop Doesn't Replace You

The loop changes the work. It does not delete you from it. And three problems actually get sharper as the loop gets better, not easier.

1. Verification is still on you

A loop running unattended is also a loop making mistakes unattended. The whole reason you split the verifier sub-agent from the maker is to make the loop's "it's done" mean something.

Even then, "done" is a claim, not a proof.

"Your job is to ship code you confirmed works."

The verifier sub-agent raises your confidence. It does not remove your responsibility. When the loop says "all tests pass and the PR is open", you still read the diff before you merge.

2. Comprehension debt

The faster the loop ships code you did not write, the bigger the gap between what exists and what you actually understand.

That's comprehension debt, and a smooth loop makes it grow faster — unless you read what the loop made. Every PR the loop opens is a reading assignment you owe yourself. Skip enough of them and you're maintaining a codebase you no longer understand, built by a system you're trusting on faith.

Comprehension debt compounds silently

You don't feel comprehension debt the way you feel a failing test. The codebase keeps working. The loop keeps shipping. Six months later, when something breaks at 2am, you open a file you've never read, that the loop wrote, that no human has ever understood — and you're stuck. Pay the reading tax every PR, or pay a much larger tax later.

3. Cognitive surrender

The comfortable posture is the dangerous one. When the loop runs itself, it's very tempting to stop having an opinion and just take whatever it gives back.

That's cognitive surrender. And here's the cruel part: 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 result.

The engineer who designs a loop to move faster on work they understand deeply → gets leverage.
The engineer who designs a loop to avoid understanding the work at all → digs a deeper hole.

The loop doesn't know the difference. You do.

The leverage point moved, the work didn't get easier

Cherny's point isn't that the work got easier. It's that the leverage point moved — from writing good prompts to designing good loops.

Two people can build the exact same loop and get completely opposite results. The loop is a multiplier on whatever you bring to it: judgement, or the absence of judgement.

The test for a healthy loop

Ask yourself after a week of running it: Do I understand my codebase better or worse than when I started? If the answer is worse — you're accruing comprehension debt and drifting toward cognitive surrender. Tighten your review checkpoints, slow the loop down, or narrow its scope until the answer is "better".

Build the loop. Stay the engineer.

Loops are a preview of how this work is going to evolve. Used with judgement, they're the biggest leverage move in a decade. Used to avoid thinking, they're a downward spiral you don't notice until you're stuck in it.

So set up your loops. But build them like someone who intends to stay the engineer, not just the person who presses go.

That is what makes loop design harder than prompt engineering — not easier. And that is the skill this course has been teaching you to build.

You've finished Loop Engineering. Go back to the course syllabus, or continue to the next course.