Writing
plan → build → review
The loop I work by — and why evals turn "it works" into something you measure, not a vibe.
Most people's agentic workflow is one step: ask, then read the diff. It works until the task is bigger than a function, and then it fails in a way that feels like the model's fault and isn't. The agent didn't misunderstand you — it was never given a boundary, so it invented one. Everything downstream is you discovering, in the diff, which boundary it picked.
The fix isn't a better prompt. It's three steps instead of one.
Plan — the scope is an artifact, not a sentence
Before anything gets written, the work gets scoped: what changes, what explicitly doesn't, what "done" means, and which files are in play. Not in your head — written down, in the repo, where the agent can read it and you can argue with it.
This is the step people skip, and it's the one that pays. Reviewing a plan costs two minutes; reviewing 600 lines of code built against the wrong assumption costs an afternoon and usually ends in a rewrite. Disagreements are cheap while they're still prose. Plan mode exists for exactly this — use it, and don't approve a plan you wouldn't have written yourself.
A good plan is also the thing you hand to the next agent. That's the part that compounds.
Build — against the scope, not against your attention
Now the agent builds. Your job here is not to watch. If you find yourself reading every tool call and interrupting every third one, the plan wasn't specific enough — go back and fix that, rather than steering in real time. Steering is the most expensive form of correction: it costs your full attention and leaves nothing behind for next time.
One rule governs where the work lives — match each piece to the lightest layer that can carry it:
- Inline — a one-off. Say it, get it, move on.
- A command — a procedure you repeat. Same steps, different input.
- An agent — work that needs judgment and its own context, and that you want to delegate rather than run in your own thread.
- A skill — knowledge worth packaging: reusable, shareable, versioned.
Climbing too fast is the common failure. A packaged skill wrapping what should have been three lines of bash is debt with good branding. Deterministic work drops to a script; only what genuinely needs judgment earns an agent. Get this wrong and you end up with a pile of clever prompts nobody — including you, in six weeks — can reason about.
Review — two reviewers, and one of them isn't you
Here's where most teams stall. They delegate the building and keep 100% of the reviewing, so their own attention becomes the bottleneck. Ship more agents and you just hit the wall faster.
So the review step is split. The machine reviews correctness: tests, types, lint, build — running automatically after edits, ideally fired by a hook rather than by your good intentions. That's the difference between "I usually run the tests" and a loop the agent cannot exit while red. It also changes the agent's behaviour, not just yours: given a failing check it can see, it self-corrects, and you never enter the conversation.
You review judgment: is this the right change, at the right altitude, in the right place? That's the part that doesn't automate, and it's the part worth your time.
Evals are how this scales past your own repo. A test asks "does this code do what the code should do." An eval asks "does this system — prompt, context, tools, model — still produce acceptable output on cases I care about." Without them, every prompt tweak is a coin flip you'll discover in production. With them, "it works" is a number that moved, and you can change the model underneath without holding your breath. Most teams have zero. It's the single most common gap I find, and the most reliable thing to fix first.
Why it's a loop
Each pass leaves something behind: the plan becomes a spec, the failure becomes a test, the correction you typed twice becomes a hook. Run it enough times and the loop gets cheaper — not because the model improved, but because the scaffolding around it accumulated. That accumulation is the harness, and it's what eventually lets work run without you in the loop at all.
The honest version of the failure modes, since I've hit all three: planning so thoroughly you could have written the code; treating a green test suite as proof the behaviour is right; and writing evals that only cover the happy path, which is a comfortable way to measure nothing. The loop is a discipline, not a guarantee.
If you want to install this loop on your own setup rather than read about it, that's exactly what a session is for — we do it live on your repo, and you keep the keyboard.