Full Walkthrough: Workflow for AI Coding — Matt Pocock

Matt Pocock’s central argument is that effective AI-assisted development depends less on abandoning established engineering practices than on applying them deliberately to a new collaborator. Task decomposition, shared understanding, architectural boundaries, testing, and review remain essential because coding agents have operational constraints that make undisciplined work especially fragile. 0:48

Pocock describes a practical distinction between an agent’s smart zone and dumb zone: as a conversation accumulates tokens, attention relationships become more demanding and the quality of coding decisions can deteriorate. He treats roughly 100,000 tokens as a personal working threshold, while acknowledging that capabilities may improve; a larger advertised context window can still be useful for retrieval without necessarily making long-context coding reliable. The actionable lesson is to keep individual tasks small and monitor context consumption rather than assuming that available context is equally effective throughout. 3:00

A second constraint is that a fresh agent session begins again from its persistent instructions. Pocock therefore favors a small system prompt and clean resets over repeatedly compacting conversation history, because a reset produces a predictable starting state while compaction carries forward an imperfect summary. Typical work then proceeds through codebase exploration, implementation, and testing; isolated subagents can perform expensive exploration in separate context windows and return only the useful findings to the main agent. 7:21

The example begins with an ambiguous request to add gamification to Cadence, a course platform where students complete a few lessons and then drop off. Pocock rejects a simple specifications-to-code handoff because it encourages developers to ignore the implementation and assume that repeatedly editing a specification will eventually produce good software. His alternative begins with the Grill Me skill, which explores the repository and interviews the human about unresolved design decisions until both sides share a coherent understanding of the proposed work. 11:35

The interview exposes decisions that a short client brief does not settle: which actions earn points, whether video-watching events are too noisy or easy to game, whether existing lesson completions should receive points retroactively, how progression levels work, and where the interface belongs. Recommendations accompanying each question help the human make decisions quickly, but the human remains accountable for resolving ambiguity. Pocock notes that these sessions can grow to dozens of questions, and that meeting transcripts or other domain-expert input can supply additional material for interrogating assumptions. 16:17

This alignment stage is explicitly human-in-the-loop, not suitable for an unattended implementation loop. When a developer cannot answer a product or technical question, Pocock recommends involving the appropriate domain expert, another developer, or a broader team; research and prototypes may also send the group back to reconsider the original idea. In this framing, the workflow is iterative even though its teaching example moves from idea to implementation in a visible sequence. 24:48

Once the design concept is established, a product requirements document, or PRD, captures the destination: the problem, proposed solution, user stories, implementation decisions, testing decisions, and out-of-scope items. Pocock prefers to trust the agent’s summarization after a thorough alignment session instead of extensively reviewing or repeatedly optimizing the document, but he remains attentive to the proposed modules because the implementation must fit the existing codebase. This is a personal workflow judgment, not a claim that every team should skip document review. 28:17

A destination document is not yet an execution plan. Rather than asking for a rigid sequence of numbered phases, Pocock converts the PRD into a Kanban board of independently actionable issues with explicit blocking relationships. Some work can begin immediately, other work depends on earlier issues, and tasks suitable for unattended execution are identified as AFK. This structure makes dependencies visible without forcing all work through one sequential agent. 39:23

The crucial review criterion is whether issues represent vertical slices, also called tracer bullets, rather than isolated horizontal layers. Agents tend to implement an entire database layer, then an API layer, and only afterward a front end; that ordering delays discovery of integration problems until late in the process. A better initial issue crosses the necessary layers and produces a small, testable behavior that supplies immediate feedback about the complete flow. 41:57

In the gamification example, Pocock rejects an initial proposal that creates the schema and gamification service without any visible user-facing result. He steers the agent toward awarding points for lesson completion and showing those points on the dashboard, which requires enough schema, service, and interface work to prove the feature operates across boundaries. Later issues can build on that working slice, while independent branches of the dependency graph become candidates for parallel execution. 40:42

After humans have shaped the idea, PRD, and issue graph, implementation can move into the night shift: an agent repeatedly selects eligible AFK issues and works through the backlog. Pocock demonstrates a simple script that supplies local issue files, recent commits, and an implementation prompt to a coding agent; a more complete unattended version runs inside a Docker sandbox. He recommends first running the single-iteration version repeatedly so developers can observe agent behavior and tune the prompt before trusting a longer loop. 51:58

The implementation prompt defines task-selection priorities and instructs the agent to explore the repository, use test-driven development, and run feedback loops. With red-green-refactor, the agent first writes a failing test, then implements the behavior needed to make it pass. Pocock argues that this sequencing makes it harder for agents to produce misleading tests after the implementation is already complete, while leaving behind useful coverage for subsequent changes. 55:44

Automated review belongs in the implementation pipeline, but it should happen in a fresh context rather than at the exhausted end of the implementation session. Resetting allows the reviewer to operate inside its own smart zone, and Pocock describes using Sonnet for implementation and Opus for review. For coding standards, his distinction is pull versus push: implementers can pull relevant guidance from available skills when needed, while reviewers should receive the applicable standards directly so they can compare the generated code against explicit expectations. 1:04:58

Automation does not remove the need for human QA and code review. During the demonstration, tests and type checks pass, but trying the feature exposes a missing database table, illustrating that automated feedback and actual user-facing behavior are different forms of evidence. Pocock also acknowledges an unresolved tradeoff: agents can generate more code than developers comfortably review, and he does not present a complete solution for reconciling rapid implementation with small, self-contained pull requests. 59:23

Pocock argues that bad codebases make bad agents because tangled dependencies and weak feedback loops make it difficult for an agent to understand, modify, and verify a system. Numerous small, interconnected shallow modules create unclear testing boundaries and encourage brittle tests around individual functions. By contrast, deep modules present a small, understandable interface while containing substantial internal functionality, making it easier to test meaningful behavior at the module boundary. 36:35

This architectural discipline also helps developers retain ownership as implementation accelerates. Humans should understand and design module interfaces, maintain a mental map of which services and routes are changing, and delegate internal implementation where robust behavioral tests provide confidence. Pocock describes using an architecture-improvement skill to identify clusters that could become deeper, more testable modules, including a video-editing flow that became substantially easier for agents to modify once it could be tested across its full path. 1:18:17

Parallel execution becomes practical when architectural boundaries, issue dependencies, and verification are already clear. Pocock describes Sandcastle, a TypeScript library that creates worktrees, isolates agent runs in Docker containers, and coordinates a planner, per-issue implementers, reviewers, and a merger agent. The planner selects compatible issues, implementations occur on separate branches, reviewers inspect resulting commits, and the merger resolves integration problems involving tests and types. 1:29:10

The workflow remains cyclical rather than fully autonomous: human QA can create new issues while implementation continues, team feedback can reshape earlier assumptions, and front-end work may require disposable prototypes because visual judgment still benefits from human inspection. Pocock also warns against doc rot: completed PRDs left in a repository can mislead future agents after requirements and code change, so he prefers closing or removing stale planning artifacts rather than treating them as permanent authority. The consistent principle is to automate bounded execution while preserving human responsibility for alignment, architecture, taste, and final quality. 1:00:53