Smart Zone, Dumb Zone: Matt Pocock's Playbook for Planning AI Coding Sessions Before You Touch Code

Matt Pocock - TypeScript educator and the author behind AI Hero - ran a two-hour workshop built around one thesis: AI feels like a new paradigm, but the software engineering fundamentals that make humans productive together turn out to work just as well with AI agents. Here's the technique he walked a packed room through, end to end - from a raw feature idea to parallel agents shipping code overnight.

The smart zone and the dumb zone

The foundational idea, borrowed from Dex Horthy (HumanLayer): every LLM session has a smart zone and a dumb zone. Fresh context, nothing added yet, is where a model does its best work - attention relationships between tokens are least strained. Every token you add is like adding a team to a football league: the number of relationships between all the pieces scales quadratically, not linearly. Past roughly 100k tokens - regardless of whether the window is 200k or 1M - the model reliably gets dumber, and decisions get worse.

The practical consequence: size tasks so they fit inside the smart zone. This isn't new advice - Martin Fowler and The Pragmatic Programmer said the same thing decades ago about human teams: don't bite off more than you can chew. Old-school multi-phase plans (phase one, phase two, phase three...) were one attempt at this. Pocock's take: if you're numbering phases like that, you've basically written a loop by hand - so why not just loop?

Clearing vs. compacting: be Momento, not a hoarder

Every session moves through the same stages: system prompt, exploration, implementation, testing. Clear the context and you snap back to the system prompt - a clean, repeatable state, like the amnesiac protagonist of Memento. Compacting is the alternative most people reach for: it squeezes the whole conversation into a smaller summary instead of wiping it. Pocock argues compacting is worse - it carries forward sediment and drift. He'd rather always reset to the exact same known-good starting point than carry a lossy summary forward indefinitely. Practical tip: keep a visible token counter in your status line at all times, so you always know how close you are to the dumb zone before it's too late.

Stop starting with specs-to-code - start with a 'grill me' session

The workflow he argues against is "specs to code": write a document, turn it into code, and when something's wrong, edit the spec instead of looking at the code. He tried it - it doesn't work, because the code is still your battleground and you still need to understand it.

Instead, he opens every new feature with a tiny skill called grill me: the agent interviews you relentlessly about every branch of the design, one question at a time, offering its own recommendation for each. The goal isn't a plan or a spec - it's reaching shared understanding with the model, what Frederick Brooks called the "design concept" in The Design of Design. A grilling session can run 20, 40, even 100 questions. That transcript becomes the real asset - not a document you write once and hand off, but a negotiated, shared mental model.

A few nuances that came up: negative decisions (things you decided against) get captured in an explicit "out of scope" section, so scope doesn't quietly creep back in later. And this is explicitly a human-in-the-loop phase - the alignment questions need a person (or several) in the room; you can't loop or delegate this part.

The PRD is a destination document, not something to proofread

Once alignment is reached, a write a PRD skill turns the grilling transcript into a structured document: problem statement, proposed solution, user stories, implementation decisions, testing decisions, and what's explicitly out of scope. Pocock doesn't reread these once generated. His reasoning: if you already reached shared understanding through the grilling session, reading the PRD is only testing the model's summarization ability - and LLMs are already reliably good at summarization. The PRD's job is to mark the destination, not to be admired.

Vertical slices beat horizontal layers - tracer bullets, not phases

The next skill breaks the PRD into independently workable issues - and this is where a subtle failure mode shows up. Left alone, agents love coding horizontally: all the database schema first, then all the API layer, then the frontend on top. That means you get zero real feedback until the very last phase, because nothing is integrated and testable until then.

The fix, borrowed from The Pragmatic Programmer's tracer bullets: like an anti-aircraft gunner who can't tell where regular bullets are going in the dark, you attach phosphor to every few rounds so you get a visible line of feedback as you fire. Applied to features, that means every slice of work should cut vertically through all the layers it touches - a bit of schema, a bit of service, a minimal bit of frontend - so you get an integrated, testable result at the end of each slice, not just at the end of the whole plan.

Turning a plan into a parallelizable graph

A sequential numbered plan can only ever be picked up by one agent at a time. Structuring issues instead as a dependency graph - a kanban board where tickets block each other - means independent branches can be grabbed and worked simultaneously by separate agents, with only genuinely dependent work serialized. Each issue also gets tagged by whether it needs a human in the loop or can run AFK (away from keyboard) - the distinction that separates work an agent can just run unattended from work that genuinely needs a person watching.

The Ralph loop: queuing up the night shift

Once issues are ready, an AFK agent (nicknamed after the "Ralph Wiggum" software practice) works through the backlog unattended: read the local issue files, pick the next task by priority (critical fixes first, then infrastructure, then tracer bullets, then polish), implement it with TDD, run the feedback loops, commit, repeat. Run once first, watched, so you can tune the prompt before trusting it to run in a loop inside a sandboxed container. The mental model: the planning and alignment phases are the day shift, done by humans; the implementation loop is the night shift, done by agents while you're away.

TDD is what keeps agents from coding blind

Without tests, an agent has no feedback loop and effectively codes blind - the quality of your feedback loops is the ceiling on how good your AI-written code can get. Red-green-refactor forces a failing test to be written before the implementation, which makes it much harder for an agent to quietly cheat by writing shallow, tautological tests that only wrap what it just built. Reviewing an agent's own output should also happen in a fresh, cleared context - review done inside the same context that did the implementation is dumb-zone review, checking dumb-zone work with a dumb-zone reviewer.

Deep modules over shallow ones

Drawing on John Ousterhout's A Philosophy of Software Design: a codebase full of small, shallow modules with sprawling cross-dependencies is exactly what agents struggle to navigate and test - the AI ends up writing shallow tests that wrap tiny functions individually, missing the bugs that live at the boundaries between them. Deep modules - a small, simple interface hiding substantial functionality behind it - are both easier to test (wrap one clear boundary around real functionality) and easier to delegate. Once a module's interface and behavior are well specified, its implementation can be handed off entirely, without needing to review every line inside it. A dedicated "improve codebase architecture" skill scans a codebase for clusters of related, poorly-tested modules and proposes where to deepen them - Pocock's single biggest recommendation from the whole talk.

Push vs. pull, and why review needs a fresh model

Two different mechanisms for shaping how an agent codes: push (always-loaded instructions, like a CLAUDE.md file) versus pull (a skill sitting in the repo that the agent can choose to load when relevant). His rule of thumb: let an implementer pull coding standards when it needs them, but push those same standards directly into an automated reviewer's context, so the reviewer always has both the code and the standard to compare it against. In practice, he runs implementation on a faster/cheaper model and review on a stronger one - the reviewer needs more of the smarts.

Parallelizing for real: a planner, N sandboxes, a merger

His own tool for this, built recently, runs a planner agent that reads the backlog and selects a batch of non-blocking issues to run in parallel, spins up an isolated sandbox (a git worktree in a Docker container) per issue, runs an implementer in each, and then hands the resulting branches to a merger agent that reconciles conflicts, fixes any type or test failures from the merge, and lands the work. It's the same day-shift/night-shift loop as before, just fanned out across multiple agents instead of one.

The takeaway

None of this replaces human judgment - it relocates it. The human stays firmly in the loop for the parts that require real alignment and taste: the grilling session, code review, and QA. What moves to the machine is the mechanical middle: turning an aligned understanding into vertical, testable, parallelizable units of work, and running the implementation loop unattended. Skip the alignment step or the architecture work, and you get slop, AI-written or not. Do them well, and cheap tokens plus deep modules plus tracer bullets turn a two-week feature into something a team can queue up before lunch and review by end of day.