AI-Assisted Coding Workflow: Matt Pocock's 8 Practical Lessons

AI coding tools are getting more powerful, but many people find that after using AI to write code for a while, the quality of generated output actually declines. Where does the problem lie? Matt Pocock offers a systematic answer in his recent workshop, Full Walkthrough: Workflow for AI Coding.

His core view is: good AI-assisted coding isn't about writing more clever prompts, but about applying solid software engineering practices to AI agents. In other words, AI hasn't replaced software engineering fundamentals—it has made them more important than ever.

Understanding AI's "Smart Zone" and "Dumb Zone"

Matt Pocock offers an intuitive metaphor: an LLM's context window has two regions.

• Smart Zone: the context is fresh and the task is focused, so the model makes higher-quality decisions.
• Dumb Zone: the context balloons and information overload sets in, so the model's reliability drops and errors increase.

He uses roughly 100K tokens as a practical warning line—not a hard technical limit, but a signal to watch for.

The corresponding strategies include: break large tasks into small independent tasks; keep system instructions lean; rather than repeatedly compressing long conversations, clear the context and restart with a clearly defined task; use subagents when you need isolated exploration so you don't pollute the main agent's context.

Behind this is a simple principle: the smaller the task and the cleaner the context, the more controllable the AI's output quality.

Context Window refers to the entire token sequence an LLM can "see" during a single inference pass, including the system prompt, conversation history, code files, and tool return results, usually measured in tokens. Mainstream models have nominal limits ranging from 128K to 200K, but effective reasoning capability often degrades well below that limit: attention is diluted by large amounts of irrelevant content, the relative weight of key instructions drops, and the model begins to miss constraints or repeat mistakes. That's why the industry often speaks of "effective context," which is usually significantly smaller than the nominal window. In practice, you need task splitting, subagent isolation, and structured summaries to control the true signal density fed to the model, rather than simply stuffing all materials into the window.

Align on Requirements Before Writing Code

Most people's habit is to throw requirements directly at the AI and let it start implementing. Matt Pocock does the opposite: he designed a skill called "Grill Me"—letting the AI interview the developer instead, asking one question at a time and offering suggested answers.

For example, to build a gamification feature, the AI asks one by one: which activities earn points? Do existing users get retroactive points? How do levels work? Where does the UI go?

The goal is to reach consensus before starting work. This reveals an important judgment: the planning phase requires deep human involvement; only the coding phase can be safely delegated to AI. If you let AI start writing when requirements are vague, the cost of rework later far exceeds the ten minutes spent aligning up front.

PRD and Independent Tasks: Defining the Destination

Once requirements are clear, the next step is to write a Product Requirements Document (PRD) covering the problem and solution, user stories and acceptance criteria, implementation decisions, testing requirements, and features explicitly excluded from scope.

The PRD describes the "destination." Next, break it down into independent issues with explicit dependencies, forming a kanban-style task queue that the agent can process item by item, or even in parallel.

The value of this approach is that it separates "humans making architectural decisions" from "AI doing implementation execution." The clearer the task boundaries, the less room there is for AI to go off track.

Vertical Slices, Not Horizontal Layers

AI has a natural tendency to implement features layer by layer—first build the entire database layer, then all the APIs, and finally the frontend. The problem is that effective end-to-end feedback arrives too late.

Matt Pocock recommends vertical slices (tracer bullets): each small feature cuts through database changes, backend logic, API integration, a minimal frontend, and tests. Each slice can run and be verified independently.

This way integration problems surface earlier, fixing costs are lower, and AI gets real feedback signals at every step.

Tracer bullets comes from The Pragmatic Programmer. Originally it referred to tracer rounds in night combat that show the bullet's trajectory so the shooter can correct aim in real time. In software development, it means using the smallest but end-to-end runnable feature path that cuts through all layers, so you get feedback in a real environment as early as possible. The key difference from horizontal layering is feedback timing: layered implementation requires all layers to be complete before you can run the system for the first time, whereas vertical slices produce verifiable behavior at every step. This matters especially for AI agents, because models can only iterate on executable feedback signals—a system that can't run is equivalent to no feedback at all.

The Ralph Loop and Parallel Execution

Once the task queue is ready, implementation can become an automated loop: pick an unblocked issue, explore the relevant code, implement the feature, run tests and type checks, commit the changes, and repeat until the queue is empty. Matt Pocock demonstrated this process with a "Ralph-style" loop.

On parallel execution, he introduced Sand Castle—using isolated Git worktrees and Docker sandboxes to let different agents handle planning, implementation, review, and merging separately. This division of labor extends CI/CD thinking from software engineering to the orchestration of AI agents.

TDD Makes AI More Reliable

Matt Pocock strongly recommends test-driven development (TDD) for AI agents, following the red→green→refactor rhythm: first write a failing test, then implement the minimal code that just passes the test, and finally refactor while keeping tests green.

Writing tests first has a subtle but critical effect: it makes it hard for AI to generate weak tests that merely confirm its own implementation. More fundamentally, AI needs fast feedback loops—unit and integration tests, type checking, linting, and automated code review.

His view in one sentence: the quality of the feedback loop often determines the quality of AI-generated code.

Red→green→refactor is the three-beat rhythm of TDD: red means first writing a test that must fail, confirming the test itself is valid and the requirement is accurately expressed; green means writing the minimal implementation that just makes the test pass, avoiding over-engineering; refactor means improving the structure under the protection of keeping tests green. For AI agents, the "red" step also serves as a specification—because the test exists before the implementation, the model cannot reverse-engineer a necessarily passing assertion from existing code. Without this constraint, models tend to write tests highly isomorphic to the implementation under test, with seemingly high coverage that fails to catch real defects.

Deep Modules and Simple Interfaces

Matt Pocock also borrows concepts from A Philosophy of Software Design, recommending deep module design: a small, clear public interface hides substantial functionality internally, with well-defined responsibilities and boundaries that are easy to test.

This is preferable to numerous tiny, tightly coupled modules. Developers should understand and control the overall architecture, delegating internal implementation details to AI. As AI generates more and more code, this principle is a guardrail against developers losing architectural understanding.

Deep modules is a core concept proposed by John Ousterhout in A Philosophy of Software Design, contrasted with "shallow modules": shallow modules have complex interfaces but simple internal implementations, with lots of logic leaking out to callers, causing complexity to spread through the system; deep modules carry substantial functionality through a small number of methods, encapsulating complexity internally. The anti-patterns in the book—"pass-through method," "information leakage," "classitis"—all point to the same conclusion: the main goal of software design is to control complexity. For AI-assisted development, deep modules have an additional benefit—a small interface means a smaller contract surface the agent needs to understand, which reduces the chances of errors when generating and modifying code.

Human QA and Code Review Can't Be Skipped

Passing automated tests doesn't mean the product is usable. Matt Pocock emphasizes that humans still need to: verify real user behavior, review important architectural decisions, inspect tests and critical code, assess frontend usability, and identify missed requirements.

He also recommends doing code review with a fresh AI context, rather than having the agent review its own output after a long implementation session—the latter easily falls into the blind spot of self-confirmation. Issues found in QA can flow back as new backlog items, forming a cycle of continuous improvement.

The Complete Workflow at a Glance

This methodology can be strung into a clear pipeline:

1. Idea
2. Grill Me (requirement alignment)
3. PRD (defining the destination)
4. Independent issues (vertical slices)
5. AI implementation (Ralph loop)
6. TDD and automated feedback
7. AI code review
8. Human QA
9. New issues and improvements
10. Repeat

The developer's role is shifting from "writing every line of code" to defining requirements, designing systems, providing feedback, and maintaining quality. AI can take on a lot of implementation work, but the decision-making power and responsibility for the final product remain in human hands.

If you're using Claude Code, Cursor, or another AI coding agent, try starting with one or two steps from this workflow—for example, next time before you start, have AI "interview" you first, or force yourself to write tests first. These seemingly plain engineering habits are precisely the scarcest competitive advantage in the AI era.

One-line Summary

The root cause of declining AI coding quality is missing engineering practices, not insufficiently clever prompts.

Paragraph Summary

Based on Matt Pocock's workshop, the article argues that the key to AI-assisted coding isn't writing more clever prompts but applying solid software engineering practices to AI agents. Core points include: LLMs enter the "dumb zone" after roughly 100K tokens, where reliability drops, so tasks should stay small and context fresh; the planning phase requires deep human involvement, using "Grill Me" to have AI interview you and align on requirements, then translating them into a PRD and a queue of independent tasks with dependencies; use vertical slices rather than horizontal layers so end-to-end feedback appears earlier; constrain AI with TDD and automated feedback loops; safeguard architectural understanding with deep module design; and never skip human QA and code review with fresh context. The result is a ten-step closed loop from idea to improvement, with the developer's role shifting toward defining requirements, designing systems, and maintaining quality.