Matt Pocock’s AI Coding Workflow Explained
Most developers hand an agent a one-line request and hope the output is close enough. The code arrives in seconds, and the parts that are wrong stay hidden until much later. Matt Pocock ran into the same wall, and his fix was not a better model. His AI coding workflow is a handful of small markdown files that force alignment before any code gets written. He published them as skills, barely promoted them, and the repo became the second most starred skills repo in the world.
Why his AI coding workflow starts with an interrogation
The most popular skill Pocock wrote is called grill me. It is tiny. All it does is tell the agent to interview you relentlessly about what you want. He credits the original idea to Tariq, who works on Claude Code, and says the behavior that emerges from such a small instruction surprised him. Models start thinking outside the box and throwing options back at you.
Pocock’s reasoning is about a gap that most people ignore. You understand your own priorities, so you assume the agent picks them up too. It cannot. However smart the model is, it cannot read your mind. Grill me is not only about implementation details. It also settles what is in scope, what is out, and what you actually care about.
Splitting work to stay inside the smart zone
Pocock borrows the smart zone and dumb zone framing from Dex Horthy. Roughly the first 150,000 tokens of a context window are where a model performs well. After that, every token competes for attention and quality slides. Context window size does not change this. Raw token count does.
Worth keeping in mind: that 150,000 figure is a working rule of thumb from practitioners, not a published benchmark. Treat it as a rough boundary rather than a measured limit, and check it against your own results.
So he splits the work. One document describes the destination, which he calls a spec. That spec breaks into tickets, one ticket per session, sometimes 30 or 40 of them. An implement loop chews through the tickets. For planning too large to fit one grilling session, he built wayfinder skill, which keeps a map with milestones and a fog of war. Each session reveals more of the map. He designed all of this to run unattended: plan during the day shift, let agents work the night shift.
Old books became his prompt vocabulary
Pocock got worse results from spec-driven development than from writing code by hand, so he opened The Pragmatic Programmer. He found a section on software entropy and recognized what agents were doing to his codebase. He kept reading, and the 25-year-old advice mapped onto today’s problems: tracer bullets, vertical slices, working inside your feedback loops.
Then he noticed something. When he used those phrases in prompts, the agent repeated them back inside its own reasoning. He calls these leading words. The books are part of the training data, so the terms are already in the model’s priors. He went further with domain-driven design and built a skill that develops a shared vocabulary for your app as you plan. In one of his projects, a cascade of ghost records turning real became “the materialization cascade.” One phrase replaced a paragraph of explanation.
When he skips planning entirely
Pocock does not grill everything. The test is how expensive the mistake would be. If bad code lands in the context window and shapes everything after it, align first. If the change is five lines or a button moving three pixels, align afterwards. He calls this shifting right.
His own setup shows the extreme version. A feedback button in his video editor files a GitHub issue, an implement agent picks it up, a review agent checks the work, and he only looks at the end. His rule of thumb: small enough to fix after the fact means no grill me, one session means grill me, multiple sessions means wayfinder. He still keeps a TDD skill, though he now argues TDD solves a human working-memory problem that agents do not have. What agents need is a feedback loop they cannot fake, so he asks them to prove a change would fail without it.
Where this holds up, and where it doesn’t
Worth saying plainly: Pocock builds alone. He says so in the interview, and it shapes everything about this workflow. One person holds the full picture, makes every call, and answers to nobody at review time. On a team, the grilling session is exactly the conversation that should include other humans. A spec that one developer produced with an agent is still a spec nobody else read.
The grill me skill also has no sense of proportion. It will ask 35 questions about an endpoint that needed three. Pocock’s answer is to not reach for it on small work, which sounds fine until you notice it puts the judgment back on you. Knowing in advance which changes are expensive to reverse is the senior skill. The skill does not teach it.
Leading words are the cheapest idea here and the one I would steal first. My hesitation is the evidence. Pocock noticed the agent repeating his phrases back, and that is where the story ends. Echoing a term is not the same as applying the concept behind it, and a model that says “tracer bullet” while building all three layers separately has learned the vocabulary and nothing else.
The night shift deserves the most skepticism. Reviewing a few hours of code you did not write is slow, and it is the least enjoyable work in the job. Pocock trades planning time for review time. Whether that comes out ahead depends on how good your review is, and nobody in this conversation measured that.
Key takeaways
- Pocock treats the agent as a collaborator who cannot read your mind, so his first move on any substantial feature is an interrogation rather than a prompt.
- He keeps each agent session inside roughly 150,000 tokens by splitting work into a spec and then into one ticket per session.
- He repeats phrases from classic programming books in his prompts because those terms sit in the model’s training data and pull its behavior toward the concept.
- He matches planning effort to the cost of being wrong, skipping the whole process for small changes he can correct after the fact.
- He believes agents make strategic mistakes surface faster, because they produce far more code in far less time.
Conclusion
Pocock’s approach is less about clever prompting than about removing ambiguity before an agent writes anything. Interrogate first, keep each session small, borrow precise language from people who wrote it down decades ago, and skip the ceremony when the change is cheap to undo. None of it depends on a particular model. It depends on knowing what you actually want.
Source
Everything above comes from Matt Pocock’s appearance on The Pragmatic Engineer podcast with Gergely Orosz. Watch the full conversation here: Matt Pocock on The Pragmatic Engineer.
