Phased Workflows for AI-Assisted Development

This one is more technical than my usual posts. I want to acknowledge that upfront, because I know most of what I write sits closer to strategy and leadership than to tooling. But I've been sitting with this long enough that I think it's worth stepping outside my lane — because the people who will work most effectively alongside AI aren't just the ones who understand it conceptually. They're the ones who understand how it actually behaves. And that includes its failure modes.

So if you've never written a line of code in your life, stay with me anyway. The underlying pattern here will be useful to you.

Something I kept running into

When I was building the AI Champion Training platform, I ran into a problem I couldn't immediately name. I'd be deep into a build session — dozens of files, dozens of decisions — and the model would start contradicting itself. A component built in one session would silently break in another. Interfaces would drift. Variable names would diverge. The bugs weren't random. They traced back to a specific cause: the model losing track of decisions it had made earlier in the conversation.

I've since learned that this isn't a flaw in any particular model, it's how large language models work. They operate within a finite context window — a working memory of sorts. When you're building something complex, earlier context starts competing with current tasks. The further you get from a decision, the less reliably the model holds onto it. Output quality degrades. Not catastrophically, and not all at once — just gradually, in ways that compound.

In my experience, this is where most preventable bugs in AI-assisted development actually come from. This isn't hallucination or gaps in capability, like we so often think. In reality, the model was forgetting what it agreed to three hours ago.

So, how do you prevent that? You could try to keep the model's context window clean, but that means constantly reminding it of decisions made earlier. That works for a while, but it doesn't scale. The more you have to remind it, the more you risk introducing noise and contradictions. And eventually, the model will forget anyway.

Chunking as a design principle

The training platform I wrote about in my previous post was where I first started applying this seriously. When I entered plan mode, I gave Claude Code the research, pointed it at the database, and asked it to break the build into self-contained phases — phases where each one could be implemented without any knowledge of what came before it in active working memory.

That last part is the critical constraint. Not just "break it into phases," but design each phase so it carries only what it needs to implement it: the relevant file paths, the partial context, the acceptance criteria. No "as we discussed" references or full conversation history. No relying on the model to remember Phase 1 when it's working on Phase 4.

Between each phase, I clear the context entirely. The model starts fresh. It reads the plan document, reads the current state of the codebase, and builds exactly what's specified — without carrying three hours of accumulated noise into the work.

The difference in output consistency was significant enough that I eventually codified the whole workflow into a Claude Code plugin: phased-workflow. View on GitHub.

The four commands

/phased-workflow:brainstorm is discussion-only. No code edits, no file creation — just a back-and-forth about feasibility, approach, and risks. The model reads your codebase, surfaces constraints you might not have considered, and asks clarifying questions. I've learned to not skip this step, even when the feature feels simple. The context gathered here feeds directly into the plan, and a plan built on a thorough brainstorm tends to require significantly less rework than one built on a vague description.

/phased-workflow:plan takes everything from the brainstorm and produces a detailed implementation plan saved as a markdown file. Each phase in the plan is explicitly self-contained — full file paths, core context, acceptance criteria — written as if the person (or model) implementing it has no memory of the phases before it. It also includes a complexity estimate per phase, which helps identify where to slow down and decompose further before implementation starts.

/phased-workflow:implement executes one phase at a time. You run it, review the output against the acceptance criteria in the plan, then clear context and move to the next phase. The plan document becomes the authoritative reference — not the model's degrading memory of what it built last session. Functions defined in Phase 2 get called correctly in Phase 5 because the model is reading the plan fresh each time, not trying to recall it.

/phased-workflow:validate runs after all phases are complete. It reads the full plan and checks three things: whether every acceptance criterion was actually met, whether integration points between phases are consistent (missing imports, interface mismatches, schema discrepancies), and whether the implementation has critical issues that tend to slip through when you're reviewing code piece by piece — unhandled errors, auth gaps, race conditions. This is consistently where I catch the things that would have reached production otherwise.

The workflow in practice

01/phased-workflow:brainstorm [describe your idea]
02/phased-workflow:plan [describe what to build]
03/clear
04/phased-workflow:implement ./PLAN.md
05/clear
06/phased-workflow:implement ./PLAN.md 2
07/clear
08... (repeat for each phase)
09/phased-workflow:validate ./PLAN.md

The context clears feel counterintuitive at first. It seems like you're throwing away useful information. But the model isn't consulting its memory of prior phases when you clear — it's consulting the plan. The plan is better than the model's memory. It doesn't drift, doesn't get noisy, and it was written when the model had the full picture in front of it.

Why this extends past code

Structuring work to account for how AI systems actually behave — not how we wish they behaved — is becoming a real professional skill. The people getting consistent value from these tools aren't just the ones using the most powerful models. They're the ones who know when to give the model a clean start, how to decompose a complex goal into phases that fit inside its effective working range, and where to build verification into the process rather than hoping it all comes together at the end.

That applies whether you're building software, producing research, drafting a strategy document, or running a complex analysis. The underlying pattern is the same: chunk the work, keep context clean, verify at the end.

If you want to try the plugin, drop the files into ~/.claude/plugins/phased-workflow/ and install it. The README walks through the full workflow. Start with something small — a feature you've been meaning to build — and run it through the full cycle. The validation step is usually where the value becomes most visible.