I Tried Loop Engineering

There’s a skill shift happening. Writing a good prompt matters less than it did a year ago. What matters now is the system around the agent, the one that decides what to prompt it with, and when.

That idea has been going around for a few weeks. Peter Steinberger put it on X: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Boris Cherny, who leads Claude Code at Anthropic, said his job now is to write loops, not prompts.

Here’s what I learned.

What a loop actually is

A loop is a workflow that runs itself. You tell it what done looks like. Then it goes: pick up a piece of work, hand it to an agent, check what came back, write down the result, move to the next thing. Then it does it again tomorrow. Without you in the chair.

This is one level above the codebase preparation I wrote about in Make Your Codebase Agent-Friendly. That post was about making a repo an agent can succeed in. This one is about removing yourself from the turn-by-turn conversation entirely.

The interesting part: you no longer need custom infrastructure for this. A year ago a loop meant a pile of bash scripts that only you understood and only you maintained. Today most of the pieces ship inside the tools. Claude Code has them, Codex has them too, and the shape is close enough between the two that I stopped thinking of this as a tool feature at all but as a pattern.

The six pieces

Every working loop I built ended up needing the same six things.

1. A trigger

Something has to wake the loop up. Could be a schedule, a cron job, a hook, or CI. In Claude Code I mostly use the goal-directed mode: you write a condition, mine was “tests in test/ pass and lint is clean,” and the session keeps working until that condition actually holds. Not until it feels done. Until it’s true. Codex has its own version of the same thing.

No trigger, no loop. You just have a fancy prompt you run manually.

2. Isolation

Run two agents in one working directory and they will write over each other. Same failure mode as two engineers pushing to the same lines without talking.

git worktree solves it. Each agent gets its own checkout on its own branch, sharing history but not files. I made this point in the last post as a question: can you run five agents in your repo right now? Loops are where that question stops being hypothetical.

3. Written-down knowledge

The agent starts every run cold. Whatever it doesn’t know, it makes up on the spot, and it sounds completely sure while doing it.

Skills fix this. A folder with a SKILL.md holding your conventions, your build steps, your “we don’t do it that way because of what happened in March.” You write it once and the agent reads it on every run. My first loop didn’t have one, and I watched it re-derive the project from scratch every single night. Adding the skill was the point where things started to compound instead.

I made this point in the last post: if you never wrote it down, the agent has no way to know it. In a loop it gets worse, because nobody is watching the session to catch the bad guess before it turns into a commit.

4. Reach

A loop that can only touch the filesystem is a small loop. MCP connectors are what give it reach into everything else. Mine reads the issue tracker and opens the PRs. You could go further, let it query a staging database or post to Slack when CI goes green, whatever your workflow actually needs.

Without connectors, all the agent can do is describe the fix and wait for you to apply it. That’s not much of a loop.

5. A reviewer that didn’t write the code

This was the most important structural decision I made. The model that wrote the code is a terrible judge of it. Way too generous when grading its own homework.

So split it. One sub-agent implements. A different one, with different instructions and ideally a different model, verifies against the spec and the tests. Both Claude Code and Codex support defining these as files in your repo, each with its own role and model.

You wouldn’t let an engineer approve their own PR, so don’t let an agent do it.

6. Memory outside the context window

The model forgets everything between runs, so the state has to live somewhere on disk. I use a plain markdown progress file. A Linear board works too, or honestly anything that records what was tried, what passed, and what’s still open.

It sounds too basic to be worth a section. It isn’t. Tomorrow’s run picks up exactly where today’s stopped because the file says so, and that file ends up doing more work than any other piece in the loop.

The loop I actually ran

Here’s one that stuck.

Every night, a scheduled run wakes up in its own worktree. A skill tells it what “healthy” means for this repo: dependencies current, no flaky tests, lint clean. It checks the state file for what last night left unfinished, then works the list. One sub-agent drafts each fix. A second one reviews the draft against the tests and the skill. Connectors open the PR and update the ticket. Anything it can’t resolve gets written to the state file with a note, and that’s what I read with my coffee.

I designed it once. I haven’t prompted a single one of those steps since.

Where it bit me

I’d be lying if I said this was free.

Tokens. Loops get expensive fast. Every sub-agent runs its own model and makes its own tool calls, so one run already costs more than a normal session. If it runs on a nightly schedule, you pay that cost every night. Check your usage before scheduling anything.

Unattended mistakes. The same loop that fixes things overnight can break things overnight, and you won’t know until morning. The verifier sub-agent helps a lot here, but its “done” is still just a claim. Verification stayed my job. It just moved to a different hour of the day.

Your own understanding. This problem grows quietly. The loop writes and merges code that you never wrote yourself. Over time, the codebase changes but your knowledge of it does not. One day you open the repo and you no longer understand your own system.

The only fix I’ve found is simple: read the code the loop produces. Even when a run succeeds and everything is green, still read it. Those successful runs are the ones you’re most tempted to skip, and skipping them is exactly how you lose track of your own project.

Two people can build the same loop and get opposite results, depending on whether they use it to move faster on a system they understand or to avoid understanding it in the first place. The loop has no opinion about which one you are.

Conclusion

Steinberger and Cherny are right about the direction. I’ll add the usual caveat: it’s early, direct prompting still has its place, and I still do plenty of it. The balance will keep shifting.

But the job didn’t shrink, it moved up a level. Instead of writing prompts you’re designing the thing that writes them: the trigger, the isolation, the knowledge, the reach, the review, the memory. Which, when you look at it, is just engineering.

Build the loop, but stay the engineer.