Seventy Percent Planning, and No Regrets

That’s per feature or project, not seventy percent of all my time. Here’s what it buys, and what I’ve been iterating on along the way.

By the time my agent is writing implementation code, the interesting decisions are already made, already argued with, already written down. The code is the easy part. It’s supposed to be the easy part. And that’s where I usually take myself out of the loop.

A while back I wrote about my three-phase workflow, planning, implementation, and verification, and I said the framework does the heavy lifting. This is the deep dive on phase one. Although honestly, each piece of it could probably be its own post.

It’s as much for me as it is for the AI, or maybe more

Here’s the bit I’d most want you to take away.

This loop does catch things early. It genuinely does. But the reason it works isn’t that the AI is clever. It’s that the process forces me to understand the feature. It’s also the deliberate layers of investigation, checks, and reviews. It doesn’t catch everything. Things still come up in review, and it’s a process I keep iterating on.

I could automate a lot more of it. I’ve tried, at home, on my own projects, where nobody’s watching and I can be as YOLO as I want. I didn’t like it. What I lose is context, the felt sense of why this shape and not the other one, which tradeoffs we took, what we decided not to do. Once that’s gone I’m not really the one making the choices anymore.

So I keep myself in the loop on purpose. It helps me get my head around the feature and feel confident about the approach, especially when I’m not looking at the code. It surfaces the questions that need to go back to product before they turn into rework. I think you get a better feature at the end. I know you get a better informed me.

What I’ve been doing

Brainstorming is where the whole thing lives or dies. It takes the ticket and the files and whatever context I’ve got, then goes and reads the actual code around where we’ll be working. Not to write anything yet. Just to find the connections and the interactions in the system that’s already there.

If it’s an area I don’t know well, I have it teach me what it just learned. That step is pure selfishness and I’m not sorry about it. I ask questions until I’m out of questions, and then we move on. Then it turns around and asks me things. The edge cases it noticed, the ambiguities in the ticket, the stuff nobody has decided yet. And it waits. Finding that out at the start instead of halfway through the build is most of the value right there.

The design doc answers what we’re building and why it takes this shape. Two or three approaches when there’s a real choice to make, the decision and the reasoning behind it, architecture, data flow. It records whether we’ll need visual QA, and it records how we’ll know the thing works. Both of those matter later.

Then the review starts. A subagent sweeps the design through five lenses: oversights, unnecessary complexity, bugs and functional gaps, completeness, and the QA plan if one exists. It comes back with findings, I pick which ones to fold in, and we go again until I’m satisfied.

Notice the lens for unnecessary complexity. It’s easy to end up with a reviewer that only ever adds. More cases, more handling, more abstraction. You want one that also takes things away.

The implementation plan is a different question. How do I execute this, and in what order? Slicing shows up here if the work needs it. It links back to the design doc, it asks whether you want a full QA test plan written, and it gives you numbered steps with file paths that have actually been verified to exist. Plus the two checklists, verification and progress, which are what let you put a feature down and pick it back up across sessions without re-deriving the whole thing.

Then I review that plan too, and this pass is stricter. It re-pulls the story, finds the QA test plan and the design doc, and reads all three together. It’s hunting for gaps against acceptance criteria, scope that crept in, steps that assume facts nobody established, risky ordering, missing rollback. And disagreements between the three documents, which is the failure you can’t catch by reading any one of them on its own.

Every finding gets verified before it’s shown to me. Then they come back grouped Critical / Important / Suggestion and I say which ones to fold in. When a finding is really about the design and not the sequencing, it rolls back up and edits the design doc. That’s the dashed line on the diagram, and it’s the piece I’d point you at first if you’re building your own.

The bdd-spec-set comes last, built off the implementation plan. Happy path, validation, edge cases, accessibility. It isn’t a document for me, it’s a document for the next phase. qa-test-planner, playwright-tester, and TDD all eat it downstream.

Plan maxxing is real, and yes, I did it

Let me save you some time.

If you build a loop like this, at some point you will plan for the sake of planning. It feels productive. It looks productive too… nothing is broken, no test is red, every round turns something up. So why would you stop?

Because when you’re six rounds deep and rounds three through five each found a defect in the previous round’s fix and nothing else, that isn’t convergence. That’s hardening the wrong object.

So here’s the rule I landed on: review depth should track how expensive it is to be wrong and how hard it is to find out. Cheap to reverse and easy to notice? One pass, go. Expensive and invisible? Take the rounds. If you’re spending the same number of rounds on both, you’re not being rigorous.

It’s still agile, I promise

I know how this reads. Ten steps, three documents, a doc that reviews a doc. Somebody is going to say waterfall, and honestly, I get it.

But look at what’s actually set in stone. Nothing is. We iterate inside the planning cycle, not just around it. Brainstorming loops until I stop having questions. The design doc gets reviewed and revised until it stops turning up findings. The implementation plan gets the same treatment against the design doc. And findings don’t get patched wherever they happen to be noticed, they roll back up to the level that actually owns them.

What makes it feel like big design up front is that the artifacts are written down. Writing something down is not the same as freezing it. Waterfall is a plan that can’t change. The whole design here is a plan that stays open to change, right up until it ships.

Always iterating

I’m always experimenting and tweaking, so this stuff changes. It used to be broken apart into a lot more steps that I had to call by hand, and it’s condensed over time into about three skills that get me all of it.

Seventy percent of every feature, and no regrets. :)