Matt Pocock's Full AI-Coding Workflow — Idea to Merge
this is the hands-on, end-to-end version of the workflow I already noted from Pocock's interview — the actual keystrokes from idea to merged code. It's the clearest live demo of "own your planning stack" I've found, and every stage maps onto a skill I can lift into my own setup. The through-line — *20-year-old software-engineering books are the cheat code for AI* — is exactly the harness-over-model bet I keep making.
Watch the original by AI Engineer on YouTubeTL;DR
Pocock's thesis: AI isn't a new paradigm that throws out software-engineering fundamentals — it's a new reason to take them seriously. He works around two hard constraints of LLMs: a smart zone / dumb zone (models get dumber as context fills, ~100K tokens regardless of window size) and Memento-style amnesia (they reset to base every session). The workflow that falls out: idea → grill-me → PRD → Kanban board of vertical slices → AFK implementation (Ralph loop in a Docker sandbox, TDD) → QA + review in fresh context → team. Planning is human-in-the-loop (the "day shift"); implementation is AFK (the "night shift"). The recurring rule: don't ignore the code ("specs-to-code" is vibe coding by another name), keep the shape of your codebase — deep modules, good feedback loops — in your head at all times, because bad codebases make bad agents.
Key takeaways
- Smart zone vs dumb zone (h/t Dex Horthy). Attention scales quadratically with tokens, so quality craters as context fills — ~100K tokens is the practical marker whether your window is 200K or 1M. Size every task to stay in the smart zone. A 1M window "just shipped you more dumb zone" — great for retrieval, weak for coding.
- LLMs are the guy from Memento. They forget and reset to base every session. Pocock hates compacting (it rots into unreliable "sediment"); he'd rather clear and start clean, because the base state is always identical.
- Grill-me, not specs-to-code. A tiny skill that interviews you relentlessly until you and the agent share a design concept (Brooks, The Design of Design). You're not producing a plan — you're getting on the same wavelength. Can run 20–100 questions. This is the one stage that must be human-in-the-loop.
- The PRD is the destination; don't polish or even read it. You already aligned during the grill; reading it only tests the model's summarizing. It carries an out-of-scope section (that's where "decisions against" and definition-of-done live).
- Kanban board beats a multi-phase plan. A numbered plan is a single loop — one agent. A Kanban DAG of independently-grabbable issues can be parallelized across agents.
- Vertical slices / traceable bullets (Pragmatic Programmer). AI loves to build horizontally (all DB, then all API, then all UI) — so you get no feedback until phase three. Force thin vertical slices through every layer so each one is testable immediately.
- Feedback loops are the ceiling. Bad or missing tests/types = AI codes blind. If output is bad, improve the feedback loops before anything else. TDD (red-green-refactor) is the unlock — writing the failing test first makes it much harder for the model to cheat.
- Review in a fresh context. The implementer already burned the smart zone, so it reviews in the dumb zone. Clear, then review clean. (Pocock: Sonnet implements, Opus reviews.)
- Deep modules > shallow modules (Ousterhout). Small interface, lots of functionality inside → one clean test boundary, easy for AI to navigate. Design the interface yourself, delegate the innards as a gray box — that's how you keep a sense of your codebase while moving fast.
The two constraints everything is built around
1. Smart zone / dumb zone. Every token you add creates attention relationships with every other token — "like adding a team to a football league," the matches scale quadratically. Past roughly 100K tokens the model just gets dumber, no matter how big the window. So the whole game is keeping each task inside the smart zone.
2. Memento. LLMs forget and snap back to the base state. A session always moves through the same shape — a tiny system prompt (keep it small; people who stuff 250K in there start in the dumb zone), then explore → implement → test. Clearing sends you all the way back to the system prompt; compacting squeezes the session into a written history. Pocock prefers clear — the base state is reliable, compaction sediment is not.
The spine: idea → grill → PRD → Kanban → AFK → QA
The whole workflow splits into a day shift (a human plans and queues the work) and a night shift (agents implement AFK). Planning is where humans are irreplaceable; implementation is where you step back.
Grill-me is a deliberately tiny skill: "Interview me relentlessly about every aspect of this plan until we reach shared understanding… for each question provide your recommended answer… one at a time." It kills the model's eagerness to jump to a plan, and its recommendations are usually good. The output — the Q&A history — is the asset (you can also feed in a meeting transcript and grill the assumptions out of it). Against specs-to-code: ignoring the code and only editing specs is vibe coding renamed; the code is your battleground, keep a handle on it.
The PRD summarizes the design concept into a destination doc. Pocock doesn't optimize it and doesn't read it — you've already aligned, so reading only checks summarization. Then he asks for proposed modules to modify before implementing — the code stays in mind the whole way.
Why vertical slices, not horizontal layers
Turn the PRD into a Kanban board, not a numbered plan — a numbered plan is one loop for one agent; a DAG of independently-grabbable issues parallelizes. And insist on vertical slices: AI defaults to building horizontally (all schema, then all API, then all UI), which means no integrated feedback until the last phase.
Implementation is AFK: the Ralph loop + TDD
Once the board exists, the human leaves the loop. A Ralph loop (once.sh) cats every issue file + the last five commits + a prompt into Claude Code (--permission-mode acceptEdits), running inside a Docker sandbox; it picks the next AFK task, implements with TDD, runs the feedback loops, commits, repeats. Run it once by hand first to watch and tune it.
TDD matters because feedback loops are the ceiling on AI quality — no tests/types and the model codes blind. Writing the failing test first (red → green → refactor) makes it much harder for the model to cheat, because the code is instrumented before it's written. And review in a fresh context:
To go parallel, Pocock built Sandcastle (a TypeScript library): a planner reads the backlog and picks issues whose Kanban dependencies are clear, spins up a Docker sandbox + git worktree per issue, runs an implementer in each, reviews the commits, and hands the branches to a merger agent that resolves type/test conflicts on the way in.
Bad codebases make bad agents: deep modules
The last idea is the one Pocock says to take away if you take only one. From Ousterhout's A Philosophy of Software Design: shallow modules (many tiny files, thin bodies) are hard for AI to navigate and impossible to draw clean test boundaries around — so you get bad tests and bad feedback loops. Deep modules (small interface, lots of functionality) get one big test boundary that catches real behavior.
improve-codebase-architecture skill scans for shallow clusters to deepen. "If you take one thing away, run it on your repo."Designing interfaces but delegating implementations lets you keep the shape of the codebase in your head — the antidote to the real cost of moving fast, which is knowing your own codebase less well. And doc rot is real: Pocock deletes finished PRDs (closes the GitHub issue) rather than let a stale spec mislead a future agent.
My take
This is the missing manual for the note I already have on Pocock — same worldview, but here you watch him actually do it. Three things I'm lifting straight into my own setup: (1) grill-me before anything, because misalignment is the expensive failure and it's cheap to prevent; (2) Kanban of vertical slices instead of numbered phases, so work parallelizes and I get feedback per slice; (3) review in a fresh context with a stronger model (his Sonnet-implements/Opus-reviews split is a clean, cheap rule). The deeper lesson is the one he keeps hammering: the leverage isn't a better model, it's a better harness — feedback loops, module shape, and your own taste imposed at QA. Bad codebases make bad agents.
The honest caveats he raises himself: you end up doing more code review, not less ("not a fun thing to say," but true), and he has no clean answer for keeping PRs small when a loop lands four issues at once. And there's a soft commercial layer — Sandcastle and his AI Hero course sit under the free advice — though the method stands on its own and every skill he uses is in the open repo.