AI coding works better when tasks stay inside the model's smart zone and each session starts from a small, stable context.
2
Planning should use a human-reviewed grilling session, a PRD, and a Kanban board of small vertical slices before agents implement the work.
3
Agents can handle implementation with TDD and feedback loops, while humans retain responsibility for alignment, QA, code review, and codebase design.
Summary
Matt Pocock presents a workflow for taking an ambiguous feature idea through planning, implementation, and review with coding agents. He begins with two constraints: long contexts become less reliable, and models lose useful state as a session grows. His workflow therefore starts with a grilling session that forces alignment between the developer and the agent. The resulting understanding becomes a PRD, which is split into independently grabbable issues using vertical tracer bullets. Once the human has reviewed the plan and task structure, agents can implement the issues, run TDD and other feedback loops, and work either sequentially or in parallel sandboxes. Humans still QA the result and feed new issues back into the board. Pocock also argues that codebase architecture controls agent performance. Deep modules with small interfaces are easier to understand and test than collections of shallow modules. He is direct about the cost: delegating implementation means more code review, while manual QA remains necessary to preserve product taste.
Small contexts keep agents in their reliable working range
Pocock describes LLMs as having a smart zone and a dumb zone. A fresh session starts in the smart zone, but adding more tokens strains the model's attention relationships. He uses around 100K tokens as his current practical marker, regardless of whether the advertised context window is 200K or 1 million tokens. His advice is to size tasks so the agent does not bite off more than it can handle. Rather than allowing one long conversation to accumulate context, he prefers clearing the session and returning to a consistent starting state. He sees compacting, which turns the conversation into a written history, as less useful than resetting the context.
A small grilling skill creates alignment before planning
Pocock starts with an ambiguous Slack brief about improving student retention through gamification. Instead of immediately entering plan mode, he invokes a small "grill me" skill. It asks questions one at a time, walks through dependencies, and gives a recommended answer for each decision. The point is to reach what Frederick P. Brooks calls a shared design concept. Questions about which actions earn points, whether existing lesson progress should be backfilled, and where the UI should live expose decisions that the original brief did not contain. Pocock has seen sessions ask 40, 80, or even 100 questions. The resulting conversation becomes a useful design asset, and the same process can be applied to meeting transcripts or input from domain experts.
The PRD records the destination without replacing code understanding
After the grilling session, Pocock asks the agent to write a product requirements document. His template records the problem statements, the proposed solution, user stories, implementation decisions, testing decisions, and out-of-scope work. He calls this the destination document. The PRD also proposes which modules will change, so the code remains part of the discussion rather than being ignored until implementation. Pocock does not normally review the completed PRD line by line. He believes the grilling session has already created shared understanding, and that the remaining task is mainly summarization. He puts more effort into QA later, where he can test whether the feature and the code actually work.
Vertical slices give agents feedback across the whole system
Pocock turns the PRD into a Kanban board instead of a sequential multi-phase plan. The issues have blocking relationships and are written so agents can grab them independently. He stresses vertical tracer bullets because AI tends to code horizontally, completing database work first, then API work, then frontend work. That delays integrated feedback until late in the process. A vertical slice crosses the required layers and produces a thin, visible piece of functionality. For the gamification example, the first slice should include some schema changes, a new service, and a minimal frontend representation. This lets the agent test the whole flow early. The resulting dependency graph also makes parallel work possible when independent issues become available.
Implementation can move to an AFK loop after humans curate the work
The human stays involved through the idea, grilling session, PRD, and issue breakdown. Once the Kanban board is reviewed, implementation can become an away-from-keyboard task. Pocock's loop passes the local issue backlog and recent commits to an agent, asks it to choose the next AFK task, explore the repository, use TDD, run feedback loops, and commit the result. A simple version runs one agent at a time. His more advanced Sandcastle setup creates Git worktrees, runs agents in Docker sandboxes, selects several unblocked issues, and launches implementers in parallel. Completed branches then go through review and a merger agent. The backlog is the output of the planning phase and the input for the autonomous implementation phase.
TDD gives agents a testable feedback loop and makes cheating harder
Pocock says test-driven development is essential for getting useful work from agents. The agent follows red, green, refactor: it writes a failing test first, confirms the failure, then implements the code until the test passes. He finds that this produces better tests and makes it harder for the agent to write an implementation first and then create tests that merely accept it. In the demonstration, the agent creates a gamification service, writes a test against a test database, confirms that the missing module causes a failure, and then implements the service. The broader point is that tests, type checks, and other feedback loops define the ceiling for agent output. Without them, the agent is coding blind.
Human QA preserves product judgment after autonomous implementation
When an issue completes, the agent reports its changes, runs tests and type checks, and creates a commit. Pocock then tests the feature himself. In the demonstration, a missing database table causes the manual flow to fail, which is exactly the kind of issue that an automated pass did not remove. He reviews the tests first, then the implementation, and checks the feature in the UI. He argues that human QA is where the developer imposes taste and catches behavior that automated checks miss. Automating the entire process, including research and QA, can produce software that does not work as intended or lacks a human sense of quality. QA also creates further issues for the Kanban board, so development and testing can continue together.
Deep modules make codebases easier for agents to understand and test
Drawing on John Ousterhout's The Philosophy of Software Design, Pocock contrasts shallow and deep modules. A codebase made from many small files with many dependencies forces an agent to trace a large graph and makes test boundaries difficult to choose. Deep modules expose a small, simple interface while containing more functionality behind it. That structure gives callers fewer details to understand and lets tests cover meaningful behavior at a larger boundary. Pocock recommends designing the interfaces and module shapes himself while delegating much of the implementation. This lets him retain an overview of the codebase without knowing every internal detail. He uses an architecture-improvement skill to find related modules, missing tests, and candidates for consolidation.
"You need to think about thin slices of functionality that cross all of the layers that you need to."43:42
Who should watch
You are moving from chat-based assistance toward agents that can implement issues without constant supervision.
Your feature briefs are vague, and you need a repeatable way to expose missing decisions before code is written.
Your agents produce code that is hard to test or understand, and you want to connect architecture, feedback loops, and agent performance.
