Skip to content
Mitchell MillerDigital growth. Software. Consulting.
Menu
Back to Signals & Systems
StudyingAgentic Engineering

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 YouTube

TL;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.
Smart zone → dumb zoneAttention scales quadratically — quality craters as context fills~100K tokensSMART ZONEfresh context,sharp decisionsDUMB ZONEstupid decisions, more tokens billed per turnqualitycontext used →Same marker whether the window is 200K or 1M — a bigger window just ships you more dumb zone (good for retrieval, weak for coding).
"Size your tasks so the AI doesn't bite off more than it can chew." Old advice (Fowler, the Pragmatic Programmers) — now aimed at the model.

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.

Every session has the same shapeKeep the system prompt tiny — then explore, implement, test. Clear resets to base.SYSTEMPROMPTkeep it tinyEXPLOREread the codebaseIMPLEMENTwrite the codeTESTrun feedback loopsCLEAR → back to base (Pocock prefers this over compact)
"I want my AI to behave like the guy from Memento — because the base state is always the same."

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.

Idea to mergePlan with humans in the loop; implement away from the keyboard☀️ DAY SHIFT · human-in-the-loopIdeaGrill-meshared conceptPRDdestinationKanban boardvertical slices, a DAG🌙 NIGHT SHIFT · AFKImplement (Ralph loop)QA + review → teamEverything left of the handoff is human-reviewed. QA feeds new issues back onto the Kanban board — the loop keeps turning.Skip research & prototype when the idea is clear; bounce back to them when the team needs to hash something out.
Grill-me is the only stage that can't be looped or delegated — alignment is a human job.

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.

Slice vertically, not horizontallyTraceable bullets: get feedback on the whole flow at the end of slice one✖ HORIZONTAL (what AI defaults to)UI — phase 3API — phase 2DB — phase 1No working system to test until phase 3.✔ VERTICAL (what you want)UIAPIDBslice 1slice 2slice 3Each slice crosses every layer — testable, visible, end-to-end, immediately.
A traceable bullet glows so you see where you're firing. Same idea: build a thin line through all layers first, then thicken it.

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:

Never let the implementer grade itselfIt already spent the smart zone — so it reviews from the dumb zone✖ SAME CONTEXTimplement (smart) → review (dumb)the reviewer is dumber than thecoder that wrote it — misses bugs✔ CLEAR, THEN REVIEWimplement → clear → review (smart)fresh eyes in the smart zone catcha ton more — tokens are cheapPocock's split: Sonnet implements · Opus reviews (push the coding standards to the reviewer).
Push vs pull: the implementer pulls standards when it needs them; the reviewer gets them pushed every time.

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.

Deep modules, not shallow onesOusterhout’s rule — small interface, lots of hidden functionality✖ SHALLOWTangled deps, no clean test boundary.AI can’t navigate it; tests wrap every tiny fn.✔ DEEPsmall interfacelots offunctionality insideone cleantest boundaryDesign the interface; delegate the innards as a gray box.
The 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.

🗣️ The Buzz — what the audience actually said
150 comments · 3,634 likes · paraphrased, ranked by likes
Prevailing sentiment: strongly positive — repeatedly called one of the most complete, practical workshops on the AI software-development lifecycle, and Pocock gets singled out as an unusually good teacher. The tactics that stuck: the DAG/worktree parallelism, grill-me alignment, and tracer-bullet vertical slicing. The sharpest, most-upvoted pushback is a cargo-cult critique — that this is rediscovering 40 years of software best practices and bolting them onto AI without understanding them — plus a camp arguing the whole "dance" will be obsolete as tooling improves. The top comment is a rueful joke about becoming a "markdown-file-manager." Spam ~0%.
😂 1,400 likes · @mistermankoTop comment, rueful: "Wanted to become a programmer, became a markdown-file-manager. Thanks AI." The joke that captures the whole shift.
👍 668 likes · @TheOrionMusicNetwork"Matt, you're doing a great thing for people" — most are too proud or embarrassed to admit they need this laid out plainly.
🔧 153 likes · @ShreksSpliff"I ask my agent to separate tasks into a directed acyclic graph and work in parallel via worktrees. Game changer." Independent confirmation of the Kanban/DAG approach.
🚩 63 likes · @heyitsmkgamingThe sharpest critique: "Re-discovering the last 40 years of software best practices and applying them to AI without understanding them is the newest cargo cult."
🚩 55 likes · @adamkadmon6339"Like watching someone who learned to swim deliver a lecture on limb movement abstracted from self-observation" — questions whether the theory is real or post-hoc.
🚩 25 likes · @lcoproductions2828Foundational doubt: "This whole system, like all agentic systems, rests on LLMs being great at summarizing — as he literally says." Skeptical the premise holds.
👍 32 likes · @PrikshitTalks"Great how Matt aligns AI with software best practices to get the most juice out of the agents."
🔧 37 likes · @AlistairLynnTried grill-me in Codex: it asked 171 questions over nearly two hours before it was satisfied. "Fascinating."
👍 16 likes · @kierankelleher"Matt is an excellent teacher — hands down one of the most complete, inspiring and practical workshops on AI SDLC."
🔧 8 likes · @rongze-b2t"Tracer-bullet slicing is the part I'd underline — agents get much more useful when the task is small, has a clear test signal, and stays reviewable."
🚩 7 likes · @aitoolcornerCounter-take: "A lot of this dance won't be necessary as tooling improves — Cursor already does much of the prompt engineering for us."
🚩 10 likes · @infinity_zero_one"Requirements → design → implement/test → deploy… software dev circa 1990–2000. We're reinventing waterfall." A pointed historical eyebrow-raise.
🔧 17 likes · @georgivatsov4379Distilled the method: get the AI on your wavelength before planning (inherited from Domain-Driven Design's shared vocabulary), then slice.
😂 208 likes · @romankalinchuk2750"Raise your hand if you watched this video. Now raise your hand if you actually raised your hand." Pocock's audience-participation bit clearly landed.
😂 6 likes · @davidz-c137"Didn't watch the video, got AI to watch it for me." The 2026 mood in one line.
🤖 pinned · @aiDotEngineer (organizer)Pinned promo for the AI Engineer World's Fair (ticket code) — the commercial layer around the free talk.
🤖 Bot/spam estimate: ~0%. Method: heuristic scan of 150 comments for links, crypto/giveaway scams, emoji-only and generic-praise templates — found only the single pinned organizer promo and no bots. Notably substantive thread (several viewers posted full timestamped chapter breakdowns). Disclosed estimate, not certified detection.

Download the resume that fits the role.

Each version emphasizes different evidence: enterprise SEO, AEO/GEO, AI product systems, or organic growth.

Selections may be reviewed in aggregate to understand which paths are getting interest.

Search DirectionEnterprise search leadership + AI-search strategy.Download PDF AI Search EngineeringHands-on AEO/GEO optimization + AI tooling.Download PDF Product ManagementRoadmap, requirements, shipped AI products.Download PDF Organic Systems ArchitectureProgrammatic SEO + organic growth systems.Download PDF