My PM coding stack

Fundamentals are the same. The rest is optimization.

The Forced Start

I didn't diversify my AI stack because a blog post told me to. Anthropic forced me.

I was all-in on a Claude Max plan when Opus 4.6 shipped and (one user's experience, plainly stated) it made my daily driver dumb and unreliable overnight. 4.7 didn't win me back. By the time 4.8 recovered, I'd spent weeks doing something I should have done much earlier: seeing what everyone else could do.

That accident is the whole stack. Run real work through a few frontier models side by side and you stop asking “which model is best.” You notice something more useful: they have personalities. And personalities want roles.

The Cast

GPT 5.5 turned out to be exceptional at hard engineering problems. Rigorous, precise, relentless. And flat: no spark in brainstorming, no spine when I needed pushback instead of agreement.

A great CTO who could not be a cofounder.

Claude is the opposite: opinionated, creative, willing to argue with me. That's who you brainstorm with, grill an idea with, write a PRD with.

Once you see that, the stack stops being about models and becomes about tiers. Three roles, three price points, plus one seat that never gets automated:

The cofounder seat gets a frontier model, because judgment is the expensive part: Opus or GPT 5.5, whichever is sharpest this quarter, each in its own harness. In practice I swap Opus and Sonnet freely on that desk; the frontier tier earns its price at the decision moments, not on every message. Freezing the PRD, for instance, runs on the mid tier: by then the arguing is done, and writing down decisions already made takes rigor, not brilliance. The engineering-manager seat gets a mid-tier model: enough rigor to critique a plan and cut clean work items, without frontier pricing. The executor seat gets the cheapest model that follows detailed instructions well; by the time work reaches it, the instructions are specific enough that it doesn't need to be brilliant.

The roles are stable. The names on the doors change with every release cycle.

And the economics are not a rounding error.

The same logic runs at the token level. Reasoning tokens are the expensive kind, and a frontier model spends them on everything it touches, boilerplate included: the over-reasoning problem, at desk level. Give the bulk work to the cheaper tier and you stop paying judgment prices for typing.

The org chart is also the cheaper option.

The Skeleton

The process these three run inside is not mine. In plain words: argue with the model about the idea until it's actually understood (grilling: requirements gathering with teeth), write the agreement down as a PRD, cut the work into thin end-to-end slices that each ship something usable, write the test before the code, review every change, and let a human try it before it counts as done.

Credit where it's due: the skeleton is Matt Pocock's, and several skills in my pack are adapted straight from his skills repo; the write-ups are worth your time. I was already doing a looser version of this instinctively, building small and testing as I went. The structure turned those instincts into a system, and I grew mine on it.

Two things in the pack are mine.

The Memory

The first is the wiki. The original pack keeps the project's brain in git as documents, which works when your artefacts are mostly code. A PM's work is messier: research dumps, transcripts, decision docs. Context that piles up faster than any one conversation can hold.

So my pack keeps a small database the agents can read and query: glossary, decisions, references, a map of the code. Every stage runs in a fresh session and writes its output back, so the next session picks up exactly where the last one died.

The conversation is disposable. The wiki compounds.

One rule makes it work: when a session gets long, don't let the tool compress the conversation into a summary and keep going (“compacting,” in the jargon; summaries lose exactly the details that matter). Write the state to the wiki and start clean.

The Gate

The second is where the human sits: every slice ends with me actually using the thing.

Not because AI can't write tests. Because this is the oldest rule in software: build small, ship iteratively, be your own first user. You catch issues while they're cheap. And there's a part AI cannot do for you: it can verify the spec was delivered, but it can't feel what the thing is like to use. Traditional teams never dropped manual testing, for exactly this reason.

You need to feel the gears mesh.

The Boring Lesson

This is a personal stack, not a doctrine. If one model for everything is working for you, my fork is overhead you don't need: start from the original instead. The repo is public; copy it in, run /setup-sdlc, and adjust it until it disagrees with you in the right places.

Strip away the models, and what's left is a sprint. Nothing about AI-assisted building suspended good software practice; every stage above is an old discipline wearing a new name:

• Grilling is requirements gathering.
• Thin vertical slices are agile done properly.
• Test-first is test-first.
• The QA gate is the manual test step we never should have skipped.

Fundamentals are the same. The rest is optimization.

Next in this direction: A Layer Down Part 3, where I build a harness in the open with this exact stack.