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 written spec as the real unit of work instead of a prompt.

Pocock's central argument is that in AI-assisted work, engineering fundamentals are the biggest advantage anyone has rather than 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 that moves from a vague idea to shipped code through a sequence of named, repeatable steps instead of 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 failure mode we describe 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?

The pipeline has five stages, each narrowing the one before: interrogate the idea until it is 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 value is in the steps it will not let you skip. An idea never goes straight to code; it first goes through a grilling stage, an interrogation one question at a time that surfaces the decisions a vague request left unstated. Only once those decisions are explicit does the plan get written down as a locked spec, which becomes the single source of truth for everything downstream. The spec is then cut into tickets small enough that each one is independently provable: 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 is test-first, so the definition of correct exists before the code that has to satisfy it. Review then asks two separate questions that are never collapsed into one: does this follow our standards, and does it 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, covering intent, seams and what is 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: check separately whether it follows our standards and whether it matches the spec, and never infer one from the other.

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

The pipeline turns one long chat into a series of written artifacts. A freeform chat treats every message as equally durable, so decisions made in message twelve are easy to contradict by message forty. In the pipeline each artifact is thinner and more durable than the last, so no important decision exists only in the chat history.

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 can be thrown away once the decision is captured in a written artifact. That 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 is actually written down, and a long chat thread full of half-remembered decisions does not count as a spec. Once a locked spec file exists, tickets are cut against it rather than against the conversation, so a ticket can go to an agent that never saw the original discussion and the agent still knows exactly what to build.

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

Two studies bracket the case for structure. In one, AI assistance on a scoped task with a clear definition of done measurably sped work up. In the other, assistance on ambiguous, unscoped real work measurably slowed it down, even though 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, with ambiguous scope and no pre-built definition of done, and the same category of AI assistance made them 19% slower, even though those developers believed throughout the study that it was helping. The variable that flipped the result was not the model but whether the task had a real spec before work started, and that is the whole argument for cutting tickets before implementation rather than after.

DORA's 2025 industry survey reports the same finding at the scale of whole organizations. AI adoption among software professionals reached 90%, up 14 points from the year before, and DORA concluded that AI acts 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 determines which way the amplification goes, so every AI consulting engagement we run starts with the pipeline stages before anyone picks 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?

The review gate checks two things: whether the code follows the team's own standards, and whether it matches what the ticket asked for. It keeps them as separate passes because a single combined review lets well-written but wrong code slip through: clean code reads as correct even when it is not.

Splitting review into two questions catches a specific failure: code that is well-written, properly typed, sensibly structured and tested, and still does not do what the ticket asked for. A single reviewer skimming for quality tends to approve it, because clean code gets the same reaction as correct code. Running the standards check and the spec check as two separate passes (sometimes two separate reviewers, or two agent runs with different prompts) forces each question to be answered on its own terms. This is the worker-checker separation from 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 runs as a state machine anchored in the repo. 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; the harness hands it 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 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. The harness hands it exactly one, the wave builds against a locked spec and a real test, and a separate process (not the agent itself) verifies the result before anything merges. The sequence is Pocock's; our part was wiring it into a state machine so the discipline holds when nobody is watching the terminal.