Plan, then spar, then build

The more of a build I intend to hand off and walk away from, the more thorough the plan has to be up front, because the plan is the contract. An agent executing autonomously can't ask me a clarifying question halfway through the night; it does what the plan said. So a vague plan handed to an autonomous builder isn't flexibility, it's a blank check. The thing to refuse isn't the autonomy — it's the autonomy without a plan solid enough to bear its weight.

That raises the stakes on plan quality in a way that's easy to underrate. When I was going to be in the loop for every step, a mediocre plan was survivable — I'd course-correct as I went. When the machine is going to execute the whole thing while I sleep, the plan has to be right before it starts, because there's no me in the middle to catch the drift. So I write the plan in an explicit plan mode and get it approved before a single mutation is allowed to happen, which forces the plan to exist as a real artifact rather than a vibe I carry in my head into the editor.

A plan is the contract for autonomy. The more of the work you'll hand off unattended, the more the plan has to survive being attacked before you sign it.

Not every request earns the full rail, and pretending otherwise just adds ceremony to a rename. So I classify the work by altitude first. Trivial — a one-line fix, a mechanical edit, an obvious rename — just gets done, no plan. Substantive — a new feature, a multi-file change, anything touching data or migrations or money — gets investigated and then planned before I edit anything. Build-sized — a whole initiative, a migration, a sweep across many files I'd hand to an agent and walk away from — gets the plan, the spar, and only then the dispatch.

The rule I hold underneath that is: when I'm unsure which rung a task sits on, I climb one. Under-planning is the more expensive mistake, and it's the one I'm biased toward, because starting to build feels like progress and planning feels like delay. It isn't. The half-hour spent deciding this is Build-sized rather than Substantive is the half-hour that puts the spar in front of the thing that most needed sparring — the change that touches production, or the sweep that rewrites a hundred files at once.

A normal review asks "does this look good?" and the honest answer is usually yes, because the plan was written by someone competent who already believes in it. That's the trap: agreeable review finds agreeable problems. Sparring inverts the incentive. The job isn't to approve the plan; it's to defeat it — to find the assumption that doesn't hold, the failure mode nobody costed, the way this repeats a mistake I've made before. You only find those when someone is actively looking for them rather than nodding along.

So I run it as a panel of lenses, each with one fixed angle of attack, because different failures hide from different lenses. One lens asks whether this is a repeat of a known past mistake. One is a premortem: it's six months later, the thing failed, what killed it? One checks whether it quietly over-builds or duplicates something that already exists. One asks whether it actually scales to where it's supposed to go — all the way to the North Star, not just to the demo. One asks whether this is the kind of thing that gets built and then never exercised. A separate judge reads every lens's findings and synthesizes them into one ranked risk list, so I get the sharpest objections surfaced rather than six overlapping essays.

The sparring is far sharper when it's grounded in my actual history of being wrong, rather than generic best-practice objections. A critic that knows the specific ways I've screwed up before — the time I chased scale before I'd earned it, the time I trusted a status flag that was lying, the fabricated metric I had to go rip out — can check this plan against those exact failure patterns. Generic criticism is cheap and easy to wave off. Criticism that says "this is the same shape as the thing that bit you in March" is much harder to dismiss, and much more likely to be right.

This is why I keep those failures written down as small, durable memories in the first place — one catalogued mistake per note, the kind of thing an agent should actually remember about me. Each documented failure becomes ammunition for the next plan's stress test. The spar doesn't just ask "could this fail?" in the abstract; it pulls my catalogued mistakes and my known critical landmines and asks "does this rhyme with a way you've already failed?" — and because I've written those failures down, the answer is checkable rather than a matter of memory and mood.

The spar ends in a verdict, not a vibe: go, go-with-conditions, or no-go. That structure matters, because the point of the exercise is to make a decision, not to generate anxiety. Go-with-conditions is the most common and the most useful outcome — the plan is sound but here are the three things you have to change or watch first. Only once the plan clears that bar does it become a build I'll actually dispatch, and by then the obvious ways it could have failed have already been surfaced and handled while they were cheap.

One thing the spar deliberately does not do is edit the plan itself. It only proposes — it writes its critique down and hands it back, and acting on the critique is a separate step I drive. That separation is on purpose: I don't want the same pass that found the risks to also silently rewrite the plan around them, because then I lose the record of what was wrong and why the fix is what it is. The verdict is advice with teeth, not an automatic edit.

On a go, the build finally gets dispatched — and how it runs depends on its shape. A multi-phase effort with independent pieces goes out as a parallel fan-out; a simpler chain goes out as sequential agents that each do one step and hand off. Either way, any file-mutating work that runs in parallel gets isolated in its own fresh git worktree, so two agents editing the same tree at once can't stomp on each other's changes. The plan says what to build; the worktrees keep the builders from colliding while they build it.

The whole rail — plan, spar, build — is really one bet: that the cheapest place to catch a bad idea is before any code exists, and the way to catch it there is to attack it on purpose rather than admire it. The building is the easy part and always was, and it's only getting easier as the agents get better. The judgment about whether to build this, in this way, is the part worth surrounding with adversaries before I commit. Impressive execution of the wrong plan is just an expensive way to be wrong faster.