Full Walkthrough: Workflow for AI Coding — Matt Pocock
Summary
Matt Pocock, a TypeScript educator and AI-assisted development practitioner, delivers a hands-on workshop at AI Engineer Europe 2026 demonstrating his full workflow for shipping production features with autonomous coding agents. The session is built around the thesis that classical software engineering fundamentals — task decomposition, test-driven development, module design — are precisely what make AI agents effective, not just raw AI capability.
Pocock opens by explaining the 'smart zone vs. dumb zone' concept, attributed to Dex Hardy of Human Layer: LLM performance degrades around 100K tokens due to quadratically scaling attention relationships, regardless of whether you're using a 200K or 1M context window. He argues against compacting in favor of clearing context entirely, keeping sessions stateless and deterministic.
The workflow proceeds through seven structured phases. Phase 1 begins with the 'Grill Me' skill — a custom Claude Code skill that runs a Socratic interrogation session instead of jumping straight to a plan. Pocock criticizes the 'specs-to-code' movement (passing a document to AI and iterating only on the spec), arguing it requires ignoring the codebase, which degrades output quality. The grill session can run 40–100 questions and produces a shared 'design concept' — alignment between human and agent — without requiring the developer to review a lengthy plan document.
Phase 2 converts the grill session output into a PRD (Product Requirements Document) using a 'Write a PRD' skill. The PRD captures problem statements, user stories, implementation decisions, testing decisions, and out-of-scope items. Crucially, proposed modules to modify are listed explicitly to keep codebase shape in mind throughout planning.
Phase 3 converts the PRD into a Kanban board of independently grabbable GitHub (or local markdown) issues using 'vertical slices' (tracer bullets from The Pragmatic Programmer). Pocock demonstrates correcting AI when it tries to slice horizontally (schema only, then API, then UI) versus vertically (schema + service + minimal UI in one slice). Vertical slices provide integrated feedback after each issue and enable parallelization via a directed acyclic graph of blocking relationships.
Phase 4 is implementation via a Ralph loop — a bash script (once.sh / afk.sh) that concatenates all issue markdown files and the last five git commits, then invokes Claude Code with `--permission-mode accept-edits` to run autonomously. The agent uses TDD (red-green-refactor) enforced by a skill: it writes a failing test first, confirms red, then implements to green. Pocock attributes 284 tests in the demo repo directly to this discipline. Agents run in Docker sandboxes for AFK (away-from-keyboard) execution.
For parallelization, Pocock introduces Sandcastle, a TypeScript library he built for running multi-agent loops. Sandcastle creates a planner agent that analyzes blocking relationships to identify phases, then spawns parallel implementer agents (using Claude Sonnet) in separate Git worktrees and Docker containers per issue. A reviewer agent (using Claude Opus for 'smarts') then reviews the commits before a merger agent resolves any type/test failures and merges branches.
The final section covers codebase architecture using John Ousterhout's 'deep modules vs. shallow modules' framework from The Philosophy of Software Design. Shallow modules (many small files with thin interfaces) are hard for agents to navigate and test. Deep modules (large surface area behind a simple interface) are easy to wrap in a single test boundary and allow agents to see the full flow. An 'Improve Codebase Architecture' skill scans for shallow module clusters and suggests consolidation. Pocock recommends designing module interfaces but delegating implementation to agents, preserving a high-level mental map without requiring exhaustive code review of internals. He uses Sonnet for implementation (with coding standards available via pull/skills) and Opus for review (with coding standards pushed directly into context).
Key Takeaways
- •Keep LLM context under ~100K tokens (the 'smart zone') regardless of available context window size; clear context instead of compacting to ensure deterministic, high-quality sessions.
- •Use a 'Grill Me' skill to interrogate requirements before planning — reaching a shared design concept with the AI is more valuable than producing a polished plan document.
- •Avoid the specs-to-code approach; always keep the codebase in view throughout planning because 'bad codebases make bad agents'.
- •Slice work into vertical tracer bullets (full-stack thin slices) rather than horizontal layers — this provides integrated feedback after each issue and enables parallel agent execution.
- •Structure issues as a directed acyclic graph with explicit blocking relationships so multiple agents can work in parallel on independent branches.
- •Enforce TDD with a red-green-refactor skill: agents that write failing tests first produce far fewer cheated or low-quality tests compared to writing tests after implementation.
- •Run autonomous (AFK) agents in Docker sandboxes to safely execute long-running loops without risking the host environment.
- •Use Sandcastle (or similar) for multi-agent parallelization: a planner agent selects phases, implementer agents (Sonnet) run per-issue in isolated worktrees, a reviewer agent (Opus) checks commits, a merger agent resolves conflicts.
- •Design codebases around 'deep modules' (simple interfaces over rich internals) rather than 'shallow modules'; run the 'Improve Codebase Architecture' skill to identify consolidation candidates — this is the single highest-leverage improvement for agent output quality.
- •Push coding standards to reviewer agents; allow implementer agents to pull standards via skills on demand.
Transcript
[music] >> Yeah, we're good. Okay, folks. We're at capacity. Let's kick off. I don't want you waiting here for 25 more minutes before we some arbitrary deadline. So, welcome. My name's Matt, I'm a teacher, and I suppose now I teach AI. Um We have a link up here, if you've not already been to this, which is has the exercises for the um stuff we're going to do today. This is going to be around 2 hours, so we might just sort of kick off 2 hours from now. Is that all right, Mike? Yeah, perfect. Um a...
