Agent loops are release artifacts

A guide making the rounds today is built on a striking admission from Boris Cherny, the creator of Claude Code: he doesn't really prompt anymore. He writes loops — recurring, persistent jobs that prompt the model, check the result, and decide what to do next, while he does something else. Review loops, maintenance loops, nightly cleanup loops.

The guide sells this as the next productivity unlock, and it is. But the framing everyone will take away — "stop prompting, start looping" — hides the part that will actually determine who wins with it. The moment your instruction runs without you watching, it stops being a prompt and becomes software. And almost nobody is treating it like software.

Disposable versus maintained

The sharp line is not prompt versus agent. It is disposable instruction versus maintained operational artifact. A prompt you type, read the answer to, and discard is disposable — quality control is you, in the moment. A loop that wakes up at 2 a.m., reads your codebase, and files changes has no you in it. Everything you were silently providing — judgment, context, the decision to stop — has to be made explicit, or it is simply absent.

Count what a real loop contains: a schedule, state that survives between runs, retry behavior, a termination condition, a review step, and some evidence trail of what it did. That is a release checklist wearing a trench coat. We have known for decades where things with those properties live: in version control, with tests, behind code review.

The prompt cookbook is where this goes wrong quietly. I have watched a team demo a beautiful library of prompts — every one of them worked, in the demo, with a human at the wheel. Promoted to scheduled loops, the same prompts had no fixture inputs to regression-test against, no failure policy beyond "retry", no budget ceiling, and no history of which revision worked last month. When a model update shifted behavior — and the guide itself warns a workflow edge can expire within three to six months as models change, a claim I can't independently verify but my own experience roughly matches — nobody could say which loops were degraded, because nothing was pinned, versioned, or measured. A cookbook cannot carry operational reliability. It was never designed to.

What a released loop looks like

My rule: a loop earns its schedule the way code earns a deploy. Concretely, the loop file lives in the repo next to the code it touches. It declares its budget — tokens, dollars, wall-clock — and its stop conditions: what "done" is, what "give up" is, and what triggers a human. It has at least three fixture inputs with expected-shape outputs, run on every model or prompt change, so drift shows up in CI instead of in production. And every run writes a one-line ledger entry — started, cost, outcome — because a loop with no evidence trail is unauditable by construction.

None of that is heavyweight. It is perhaps an hour per loop, once. Which is the point: the discipline is cheap, and the absence of it is only expensive later, which is exactly the trade software engineering exists to manage.

Steal this: take your three most-used prompts — the ones already informally load-bearing — and promote them properly. Commit each one, add fixtures, a budget line, a stop condition, and a ledger. That's your first release. Cherny's job title shift is real, and it is coming for the rest of us: less prompting, more loop-writing. The teams that treat those loops as release artifacts will compound. The teams running a folder of hot prompts on a scheduler will spend next year debugging ghosts.

A prompt is a conversation; a loop is a deployment — version the things that run without you.