Learning Loops, Not Prompts

Photo by Christina @ wocintechchat.com on Unsplash.

Boris Cherny, the engineer behind Claude Code at Anthropic, put it plainly: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”

That line landed hard.

Worth being precise about what he means. Cherny is not talking about a cleverer prompt with an until clause in one chat. He means automated systems that run without him: loops that prompt Claude, figure out what comes next, and keep going. That is closer to Ralph, /goal, and /loop than to typing careful follow-ups in a thread. Uninstall-the-IDE territory. His job is to design those systems, not to steer each turn.

Most of us are not living there, and many of us do not want to. What I am learning is a middle path anyone can try today: borrow the finish-line idea without building a factory. Name done. Let the run continue until the exit is met or you stop it. Put the ledger on disk so you can resume without scrollback. Stay in the craft. No parallel agent farm required.

That framing still names a shift in where the leverage lives. The valuable unit of work is no longer a single message. It is a cycle with a condition you can reuse. Prompt engineering was the old center of gravity. Loop design is the new one, even when the loop is small.

Anthropic is not alone in the factory end of this. Claude Code ships /goal (run until a verifiable end state) and /loop (run again on a schedule). Codex has /goal. Cursor ships a /loop skill for recurring local work. The tooling is catching up. One-shot prompts do not match work that needs a finish line, whether you automate the whole run or not.

Addy Osmani called the full version loop engineering: automations, skills, sub-agents, and state on disk instead of in chat. That framework helped me see the shape Boris is pointing at. What I am still learning is the smaller version: work with a finish line I can resume without scrollback, with me still in the room.

So here is the uncomfortable part, and maybe you feel it too.

We still work like it is a search box

Most agent tasks in the wild still look like this: write a prompt, read the answer, send a follow-up if something feels off, stop when you are tired or satisfied. There is rarely a finish line. There is rarely a ledger outside the chat. There is rarely an agreed definition of done, only looks good or keep going.

We would not run a PR fix cycle, a lint cleanup, or a review pass that way with a teammate. We would name done. We would track what changed. We would pick up tomorrow from a ticket, not from scrollback.

Cherny’s loops point at the factory end. Our habit is still the search box. The middle path is what I have been trying to close, not by reading more threads, but by experimenting and noticing what breaks.

The loop I did not want

Before Cherny’s quote clicked, I had already heard a different loop story, the Ralph loop. Hand the machine a goal, walk away, come back to a finished thing. Full automation. Set it, forget it.

It never sat right with me.

Coding is craft. It is the part of this work I actually love: the taste, the structure, the small decisions that compound. I did not get into this to become someone who only watches work spin in the background. I am not trying to remove myself from the work. I am trying to stay in the work without drowning in repetition.

So I filed Ralph in the back of my mind and did not touch it.

Cherny reframed the question. Maybe the idea was valid. Maybe only the factory execution was wrong for me: too hands-off on one side, one-shot prompts on the other. A smaller loop. Human still in the work. Structure, not abdication.

So I started experimenting.

What I learned first

My first experiments were prompts that said, in effect, keep going until this is done.

That failed in a predictable way. “Keep going until it is good” is not a loop. It is hope with extra steps.

A hack that almost worked looked like this: loop this as much as you like, but break every five rounds so I can give input. That got me somewhere: human checkpoints without full autopilot. But the exit was still fuzzy. I kept appending another line: or if you find it satisfies this condition: … lint clean, tests green, whatever counted as done that day. The condition was doing the real work. The “every five rounds” part was just a safety rail because I did not yet trust the agent to know when to stop.

The moment I wrote the until as the primary contract, not a footnote after “keep looping”, lint clean in src/, tests green, PR feedback addressed, the behavior changed. The agent had something to verify against, not a vibe to chase. The human breaks stayed, but they became optional gates, not the only thing preventing an infinite run.

That matches what /goal is trying to enforce: a verifiable end state, not a process description. Good. But I was in Cursor, retyping the same contract every session, and /loop in my tooling meant something else entirely: time, cron, poll again in five minutes. I needed work until a condition holds, not wake up again because the clock said so.

I kept iterating on the prompt. It worked, but it got repetitive: re-explaining gates, re-teaching shape. That repetition pushed me from prompt habit to skill: package the protocol once, invoke it when the pattern fits.

Using it surfaced the next wall: context.

Long runs eat the window. By iteration four or five, the conversation is fat with diffs, decisions, and dead ends. Context rot is quiet amnesia. You feel it before you can prove it.

So I made the work durable by design.

Not remember everything in chat. Write the ledger to disk. Start in conversation one. Stop before the rot. Open conversation two and resume with the same goal, same until, fresh context budget. The work outlives the chat.

That unlocked delegation. If continuity lives in files, the parent can hold the contract (the until clause, what is done, what is blocked) while subagents do the sweatiest reads and edits. Handoff is not scrollback. It is an artifact. Subagents get a bounded job. The parent merges and checks the exit.

That is the line from experiment to packaged protocol to orchestration. I am still learning the edges, but the shape held.

What I am learning to design

Cherny says write loops. I agree with the direction. What I am trying to design is narrower: replace the search-box habit with a contract you can reuse, without giving up craft, and without calling it loop when loop already means cron.

What most of us still do	What I am learning to need
One prompt, one answer	A verifiable until clause
Chat as memory	A ledger on disk that survives a new session
Stop when it feels done	Stop when the condition is met, or I say so
One agent, one thread	Delegation; parent keeps the contract
Full autopilot or manual repetition	Stay in the work as orchestrator

The contract I keep coming back to:

1. An until clause, not a vibe: “lint clean in src/” passes; “make it better” gets rejected at the gate.
2. Durable session files: resume in a new conversation with confirmation, never auto-continue.
3. Subagent handoffs: bounded jobs, validated reports, parent merges.
4. Stall detection: same blocker twice means stop, not spin.
5. Human-gate: when I want to stay in the craft on risky work.

Naming still trips me up. Loop in agent tooling already means time: Cursor’s /loop, Claude’s scheduled /loop. What I mean is simpler to say in plain language: work until a condition is met, with proof and a file to resume from. Not a timer. Not scrollback. A finish line.

Default practice        →  one prompt, chat as memory, stop when tired
What I am learning      →  until-clause, ledger on disk, resume, verify, delegate
Domain workflows        →  same contract, job-specific steps

What I still refuse to automate

I want to be clear about what has not changed for me.

I still write the until clause. I still confirm before a run continues, especially after resume. I still choose human-gate when the work touches auth, production paths, or anything I would not blindly ship. A packaged protocol does not replace judgment. It replaces re-explaining the same rules every afternoon.

That is the compromise I was looking for when Ralph felt too hands-off and one-shot prompts felt too brittle. Cherny’s loops pointed at the future. What I am learning is how to practice the same idea today: structured work with an exit, durable enough to survive context, flexible enough to keep me in the craft.

I had already stopped calling AI output slop, the same phase separation I wrote about in thinking in code: fast exploration, human standards for delivery. Trust made experimentation possible. The loop conversation made it urgent.

If this sounds familiar

You might recognize the failure mode:

• You asked the agent to fix the PR. It did something. You closed the laptop. Next day you had no idea where you left off.
• You said keep going until tests pass. It kept going, and also kept “fixing” things that were not broken.
• You tried a long chat and watched quality drift as the window filled up.

Those are not model failures alone. They are missing contracts: the gap between what Anthropic is preaching and what our daily habit still looks like.

If you want to go further, I packaged what I learned as a reusable skill you can install. The idea matters more than the artifact: give the agent an until clause, put the ledger on disk, delegate the sweat, stay in the work.

That is the kind of loop I am willing to run, and still learning to run well.