Let's Talk About Plans

Regardless of if your factory is dark or has lights on, I think you should always plan.

By the time my agent is writing implementation code, I’ve stepped out of the loop. Sometimes I step out sooner. 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.

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.

This loop does catch things early. But the reason it works isn’t that the AI is clever. It’s the deliberate layers of investigation, checks, and reviews. It doesn’t catch everything, but I’ve worked without it and I much prefer the result when I use this system. It’s a process I keep iterating on.

To stay or not to stay in the loop, that is the question

At home I’ve got a handful of side projects going. Some of them support a Dark Factory pattern just fine: fully autonomous, nobody required in the room to keep it moving. I’ve completed entire side projects this way. Others don’t, not because they can’t but because I don’t want them to, and for those I still want to be in the loop.

The planning still happens either way. That part isn’t optional. When at home, I decide based on the project or feature whether I stay in the loop while planning happens.

At work, planning is as much for me as it is for the AI, or maybe more

At work, sure, I could turn some more of the factory lights off, but here is why I keep them on. It’s that the planning process forces me to understand the project or feature and how it integrates with the rest of the system. It’s especially helpful when working in areas of the code base I haven’t worked in before. It allows me to continue to be able to speak about the feature and its details and arguably, to have learned a lot of those details through this process. Without it, I lose context, and the mental map of the system. I lose the felt sense of why this shape and not the other one, which tradeoffs we took, what we decided not to do.

Another benefit I’ve had through these discussions while in the loop is the surfacing of pre-existing system bugs and design flaws. In surfacing them, we’ve been able to fix them, making the system better.

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 or bubbles up things I might want to discuss with my team before they turn into rework. It fosters collaboration. I think you get a better feature at the end. I know you get a better informed me.

My Planning Loop

When working the Dark Factory pattern, the AI auto resolves all the open questions and keeps moving. When the lights are on, the resolver is me.

A reminder before walking it: every pause below is a pause only when the lights are on. In Dark Factory mode the AI resolves all of it automatically and keeps going. Same steps either way, nobody waiting on me.

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. Along the way it establishes the glossary for the feature or project: for each domain concept, it finds the term the code already uses and quotes the file and line. It only stops to ask when a concept has no term, or has two, then passes that glossary to the design and implementation plans. What I’ve learned about glossaries has the full argument.

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 clarifying and probing questions until I’m out of them, 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. On personal projects I’m the one answering. At work, the ones that need a product decision go to product. Finding that out at the start instead of halfway through the build is most of the value right there.

The design plan answers what we’re building and why it takes this shape. Two or three approaches we discussed, the tradeoffs, what we went with and why, architecture, data flow. Sometimes I ask for a diagram. It records whether we’ll need visual QA in our verification phase, and it records how we’ll know the thing works. Both of those matter later.

Then the design plan gets reviewed. A subagent sweeps it through five lenses: oversights, unnecessary complexity, bugs and functional gaps, completeness, and the QA plan if one exists. It comes back with findings, verified before they’re shown to me and grouped Critical / Important / Suggestion. Nothing changes unless I say so. 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 maps the design plan into something executable. How do I execute, and in what order? Slicing shows up here if the work needs it. It links back to the design plan, it asks whether you want a full QA test plan written, and it gives you numbered steps with file paths. It also carries mutation checks: break the code on purpose, name the test that has to go red. Those pass to the TDD skill at build time. 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 the implementation plan gets reviewed too, and this pass is stricter. It re-pulls the story, finds the QA test plan and the design plan, 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.

Same reviewer, same triage. When a finding is really about the design and not the sequencing, it rolls back up and edits the design plan. 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, error 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 and keep yourself in it, 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.

The same goes for the light switch. Some work I hand over and let run dark, some I stay in the loop for, and the call gets easier the more I make it.

So let’s keep talking about plans. :)