Running AI Coding on Matt Pocock's Method, in Production

Who Is Matt Pocock and Why Did We Adopt His Method?

Matt Pocock is a working AI engineer and educator, formerly a Vercel developer advocate and the creator of Total TypeScript, who now teaches AI-assisted engineering at aihero.dev. We adopted his coding pipeline because it treats a spec, not a prompt, as the real unit of work.

Pocock's central argument is that engineering fundamentals are the biggest advantage anyone has in an AI-assisted era, not a smaller one, because bad code has never been cheaper to produce or more expensive to live with. He lays out a concrete pipeline in his walkthrough video and open-source skills, moving from a vague idea to shipped code through a sequence of named, repeatable steps rather than one long freeform chat with an agent. We watched the full walkthrough workflow for AI coding, tried the shape of it on a real client build, and kept it, because it solved the exact failure mode we cover in our report on why AI agents fail: capable models producing unreliable output because nothing structured the work before the agent started typing.

What Are the Stages of Pocock's AI Coding Pipeline?

Five stages, each shrinking the last: interrogate the idea until it's a real plan, lock that plan into a written spec, cut the spec into small independently provable tickets, implement each ticket test-first, and review on two separate axes before merge.

The pipeline's power is in what it refuses to skip. An idea doesn't go straight to code. It goes through a grilling stage first, an interrogation, one question at a time, that surfaces the decisions a vague request was quietly hiding. Only once those decisions are made explicit does the plan get written down as a locked spec, the single source of truth for everything downstream. The spec then gets cut into tickets small enough that each one is independently provable, meaning a person or an agent can look at a single ticket and know exactly what "done" means for it without touching the other nine. Implementation happens test-first, so the definition of correct exists before the code that's supposed to satisfy it. And review runs on two separate questions that never get collapsed into one: does this follow our standards, and does this actually match what the ticket asked for.

• Grill: interrogate the idea one question at a time until the hidden decisions are explicit.
• Lock the spec: write the plan down as the single source of truth, intent, seams, and what's explicitly out of scope.
• Cut tickets: break the spec into small units, each independently provable on its own.
• Implement: build test-first, so correctness is defined before the code that has to satisfy it.
• Review on two axes: does it follow our standards, and does it match the spec, checked separately, never assumed from the other.

How Does This Look Different From Just Chatting With an Agent?

A freeform chat treats every message as equally durable, so decisions made in message twelve are easy to contradict by message forty. A staged pipeline turns the messy conversation into a series of artifacts, each one thinner and more durable than the last, so nothing load-bearing survives only in the chat history.

The difference isn't cosmetic. Pocock's own framing is that the transcript dies when the spec is born, meaning the raw back-and-forth that got you to a decision is disposable once that decision is captured in a written artifact. That single habit solves a problem we cover at length in our report on the repo as source of truth: an agent, or a person picking the work back up tomorrow, can only act on what's actually written down. A long chat thread full of half-remembered decisions is not a spec. A locked spec file is. Once the spec exists, tickets get cut against it, not against the conversation, so a ticket can be handed to an agent that never saw the original discussion and it still knows exactly what to build.

Where Does the Data Back Up Structured Pipelines Over Freeform Prompting?

Two studies bracket the case for structure. Assistance on a scoped task with a clear definition of done measurably speeds work up. Assistance on ambiguous, unscoped real work measurably slows it down, even while the people doing it believed the opposite the whole time.

The GitHub and Accenture randomized controlled trial gave developers a scoped exercise, build an HTTP server, with an obvious definition of done, and AI assistance made them 55.8% faster. METR's 2025 study gave experienced developers real backlog items in their own repos, ambiguous scope, no pre-built definition of done, and the same category of AI assistance made them 19% slower, despite those developers believing throughout the study that it was helping. The variable that flipped the result wasn't the model. It was whether the task had a real spec before work started. That's the entire argument for cutting tickets before implementation, not after.

DORA's 2025 industry survey adds the organizational-scale version of the same finding. AI adoption among software professionals reached 90%, up 14 points from the year before, and DORA's own conclusion was that AI functions as an amplifier: it makes disciplined teams more disciplined and undisciplined teams more chaotic, faster than either would have moved without it. A structured pipeline is what determines which direction the amplification goes. This is why every AI consulting engagement we run starts with the pipeline stages, not with picking a model.

The transcript dies when the spec is born. Your messy idea gets distilled at every stage, and the next stage only ever receives the thin artifact, never the raw conversation.

What Does the Review Gate Actually Check, and Why Two Axes?

One axis checks whether the code follows the shop's own standards. The other checks whether it actually matches what the ticket asked for. Collapsing them into a single review lets code that's well-written but wrong slip through, because clean code reads as correct code even when it isn't.

Splitting review into two questions catches a specific failure mode: code that is genuinely well-written, properly typed, sensibly structured, tested, and still doesn't do what the ticket actually asked for. A single reviewer skimming for quality tends to wave that through, because clean code triggers the same approval instinct as correct code. Running the standards check and the spec check as two separate passes, sometimes literally two separate reviewers or two separate agent runs with different prompts, forces both questions to get answered on their own terms. It's the same worker-checker separation we cover in our field note on premature completion, applied at the review stage instead of the individual task stage.

What Has This Actually Looked Like Running on Real Client Work?

In production, the pipeline turns into a repo-anchored state machine: the current stage is written to a file, gates require a human decision to advance, and an autonomous build wave never picks its own next task, it's handed exactly one ticket at a time.

We built our version of Pocock's pipeline as a conductor that reads its own state from a file in the repo, routes to the right stage, and stops at exactly three points for a human decision: locking the design, approving the spec, and approving a merge. Everything between those three gates can run unattended, because each ticket carries its own provable definition of done, the same discipline we apply across every automation build we ship. An autonomous wave of work never chooses its own next ticket either; the harness hands it exactly one, it builds against a locked spec and a real test, and a separate process, not the agent itself, verifies the result before anything merges. None of that is our invention. It's Pocock's sequence, wired into a state machine so the discipline holds even when nobody's watching the terminal.