Why This Walkthrough Is Different
Matt Pocock is a senior TypeScript educator. His audience is developers who want to understand things properly, not developers who want to be impressed by productivity numbers. When he shows his AI coding workflow, he is not demonstrating what is possible in a demo. He is showing what he actually does on real projects.
That distinction matters. Most AI coding content shows the tool at its best: clean inputs, obvious tasks, satisfying outputs. Pocock shows the workflow with all its constraints, including the places where AI is not faster and the places where a bad spec will cost you more time than it saves. The honesty is what makes it worth studying.
The workflow has four stages. Each one has a specific job. Understanding why each stage exists is more useful than copying the exact tools he uses, because the tools will change and the logic will not.
Stage One: The Spec Is the Quality Gate
Most developers skip straight to asking AI to write code. Pocock argues this is exactly backwards. Before any code gets written, he uses AI to help write the spec: what should this component do, what are the edge cases, what does success look like, what are the inputs and outputs.
The spec-first insight is simple but it changes everything downstream. A well-written spec makes the AI's code output dramatically better. A vague prompt produces code that technically runs but misses half the requirements. The spec is where the intelligence actually goes , not the implementation prompt, not the code review, but the upfront definition of what you are building.
He describes this as a "garbage in, garbage out" problem at the spec level. If you cannot write a precise spec, the AI cannot write precise code. Using AI to help refine the spec before touching implementation forces clarity that most developers skip when they work alone. It turns a solo thinking exercise into a collaborative one, and the output is sharper for it.
The spec also becomes documentation. When the implementation is done, the spec is already written. When someone asks why the component behaves a certain way, the spec has the answer. This is a side benefit that compounds over time on projects with more than one contributor.
Stage Two: Tests Before Implementation
After the spec comes the tests. Pocock writes them before any implementation code exists. The tests define what "done" looks like. When AI writes the implementation, the tests are the success criterion , not the developer's judgment that the code "looks right."
This is the test-driven development discipline applied to AI-assisted workflows. It makes the loop self-verifying. The AI writes code, the tests run, the loop continues until the tests pass. There is no subjective judgment required at the implementation stage because the judgment was already encoded in the tests.
The practical effect is that the developer's attention stays on the right layer. You review whether the tests cover the spec adequately, not whether each line of implementation looks correct. That is a higher-use use of attention , and it is the kind of review that catches real gaps rather than stylistic preferences.
Writing tests before implementation also surfaces ambiguity in the spec. When you try to write a test for an edge case and realize you do not know what the correct output should be, that is valuable information. Better to resolve the ambiguity at the test-writing stage than to discover it after the AI has made an assumption and built twenty functions on top of it.
Stage Three: The Implementation Loop and Tool Stack
For the implementation stage, Pocock uses Claude Code as the primary engine. Not because it is the only option, but because it handles multi-step implementation tasks well when the spec and tests are clear enough to guide it. When the tests fail, the loop continues. When they pass, the implementation stage is done.
He uses different tools for different parts of the workflow rather than forcing one tool to do everything. Cursor handles navigation and multi-file awareness. Zed handles editing speed. Claude Code handles implementation. Each tool gets used where it performs best, not where the developer is most comfortable with it.
The division is worth noting because the alternative , using one tool for everything , tends to produce mediocre results at each stage. A tool optimized for fast editing is not optimized for multi-file agent runs. A tool optimized for implementation is not optimized for code navigation. The workflow treats different stages as genuinely different tasks.
What AI handles well in this workflow: boilerplate, standard patterns, error handling, type definitions, documentation. What it does not handle well: architectural decisions, edge case judgment, complex state management. Pocock does not pretend the line does not exist. He designs the workflow around it, keeping AI on the tasks it does reliably and keeping humans on the tasks it does not.
Stage Four: Human Review With AI Explanation
The final stage is human review. Not rubber-stamping the output , actual review of whether the implementation matches the spec and whether the tests cover what they should. AI assists here in a supporting role: explaining what it did and why, flagging decisions it made under uncertainty, pointing to places where the implementation diverged from the most obvious reading of the spec.
This is where Pocock draws a clear line. Review is human work. You need to understand the code that goes into your codebase. Using AI to explain its own output during review is a legitimate shortcut. Using AI to approve its own output is not.
The workflow closes the loop back to the spec. If review reveals a gap , a behavior the spec did not anticipate, a test that did not cover a real case , the spec gets updated before more code gets written. The discipline of keeping the spec current pays off every time the loop runs again on a related task. The spec becomes a living document, not a one-time artifact.
The Honest Time Math and the Biggest Mistake
Pocock's time estimates are more honest than most: 40 to 60 percent faster on familiar patterns. Roughly equal on novel architectural challenges. Potentially slower if the spec is not written well first.
That last point deserves emphasis. The developers who report AI coding making them slower are usually skipping the spec stage. They are asking AI to do the thinking they have not done yet. When the output is wrong, they revise, prompt again, revise again. The loop gets expensive fast without a quality gate at the start.
The biggest mistake he identifies is treating AI as a replacement for thinking. His workflow does the opposite. Every stage front-loads human judgment: into the spec, into the test definitions, into the review. AI accelerates execution once the judgment is in place. It cannot substitute for the judgment itself.
This is a more conservative stance than most AI workflow content takes. It is also more accurate to what the tools actually do well. They are very good at executing clearly defined tasks. They are not reliable substitutes for the work of figuring out what the task should be. The developers who build the most with these tools are not the ones who prompt most cleverly. They are the ones who think most clearly before they prompt at all.
What This Workflow Tells You About the Tools
One implicit lesson in Pocock's walkthrough is what it reveals about the tools themselves. Claude Code, Cursor, and Zed are not interchangeable. Each has a design center , a type of task it was built for and a type of task it handles poorly. Using them correctly means knowing which one to pick up for which part of the job.
This matters because the AI coding tool market is still consolidating. The tools that exist today are not the tools that will exist in two years. What will persist is the underlying workflow logic: spec before implementation, tests as success criteria, human review as a non-optional stage. Those principles do not depend on any specific tool. They depend on a clear model of what the human is responsible for and what the AI is responsible for.
Pocock's workflow keeps that boundary explicit at every stage. The human owns the spec. The human owns the test definitions. The human owns the review. The AI executes within those boundaries. That is not a limitation of the tools , it is a deliberate choice that reflects what these tools are actually good at and what they are not. A workflow that acknowledges the boundary produces better output than one that pretends the boundary does not exist.
Spec first.
Tests before code.
Review never skipped.