The Loop Doesn't Know

Loop Engineering — Addy Osmani:

Build the loop. Stay the engineer.

Osmani's pitch is that the job has moved. You no longer prompt a coding agent turn by turn; you design an autonomous loop that prompts it for you, then walks away. And the striking thing is he's not forecasting. The pieces have shipped: Claude Code's /loop and /goal, Codex's scheduled automations, git worktrees so parallel agents don't trample each other, sub-agents where one writes and another checks. If you live inside these tools, this is a real change in posture, not a thinkpiece.

Worth noticing what the whole structure stands on, though: a verifiable stop condition. /goal keeps grinding until something like "tests pass and lint is clean" is actually true. That's the mechanism, and it only exists where "done" is machine-checkable. Most professional work has no such oracle, and a fair amount of code doesn't either. Where you can't write a check a second model can grade, the loop has no brakes. Only momentum.

The bottleneck doesn't vanish, either. It relocates from your typing speed to your reviewing capacity. Run more loops than you can read and you haven't scaled yourself; you've just accumulated unread output faster.

To his credit, Osmani says all of this. Verification stays on you, comprehension rots if you let it, the comfortable posture is the dangerous one. The honest part is that those caveats aren't footnotes to the technique. They are the technique. Which is precisely the section a busy reader skims past to get to the five building blocks.

His best line is the one he almost throws away: two people build the identical loop and get opposite results, because one understands the work and the other has stopped. The loop can't tell which you are.

Neither can your manager — until something ships that nobody read.