Ship like the best engineers: Matt Pocock's AI workflow

Summary

The video explains Matt Pocock’s AI-agent workflow, built around a collection of reusable “skills.” Its central idea is that agents can handle implementation, but people should make the product decisions an agent cannot safely guess.

Workflow

1. Grill the idea before coding The grill me skill interviews the developer in numbered rounds, mapping decisions and asking about the next unresolved set—the “frontier.” It recommends answers, while delegating fact-finding to helper agents when answers can be found in the code. Coding waits until the decisions are settled and the developer agrees with the plan. Matt says a small change may take about six questions and a typical one around twenty.

2. Keep terminology clear grill with docs maintains a project glossary during the interview, distinguishing terms such as “pause” and “skip.” The wait what skill can restate an agent’s previous message in plain language using that glossary.

3. Prototype questions that are hard to answer in words For visual or otherwise “ungrillable” decisions, the agent can hand off to a fresh session to make rough alternatives. The developer chooses among them, and that decision returns to the interview.

4. Write a spec, then break it into tickets to spec turns the agreed decisions into a spec with the problem, solution, user stories, and an agreed testing seam. The spec is treated as the destination; to tickets divides it into independent, end-to-end slices that fit fresh agent sessions. The video explains this as a way to keep work within the model’s effective context, or “smart zone,” which Matt describes as roughly below 150,000 tokens.

5. Implement in clean sessions Each ticket can be implemented in a fresh chat, using test-first development: add a failing test at the agreed seam, then write enough code to pass it. The v1.3 implement spec skill can instead work through ready tickets in parallel, with separate agents using separate repository copies and contributing to one branch. Matt says he removed a refactoring step from implementation because agents were not reliably doing it.

6. Review separately from implementation Code review uses two fresh agents: one checks the diff against the spec for missing, unnecessary, or incorrect behavior; the other checks it against coding standards and common code smells. The rationale is that a separate reviewer can focus on problems the coding agent may overlook.

7. Prepare the pull request and learn from the run The PR skill writes a concise pull-request description with before-and-after evidence and a “merge danger” section assessing whether the change is reversible and its blast radius. Afterward, retro reviews the session and suggests improvements to project instructions, checks, or tooling. It only proposes changes; Matt advises against automatically applying its findings because they may be false positives.

Example and analysis

The walkthrough uses a coffee subscription feature. A customer pausing after their coffee has already been packed raises product questions the original one-line prompt would leave to the agent to guess: what happens to the packed bag, charges, pause duration, and reminders. The workflow makes those decisions explicit before implementation.

The video also reports a real run in Matt’s course-making app: a 41-user-story spec became ten linked tickets, with work landing on one branch in 28 commits and nearly 14,000 lines. It was merged a little over two hours after the spec was written. The last ticket was left open for research.

The video addresses two objections:

• “Isn’t this waterfall?” Matt’s response is that the spec records decisions made during planning and is closed after the work ships; the lasting record is in the code, tests, and glossary. Prototypes and planning small changes in a single session are presented as ways to keep the process flexible.
• “Are these skills too defensive for modern models?” Matt argues that many skills only load when invoked, so they add little overhead when unused. He also removes skills when the underlying models or harnesses can handle those tasks themselves; v1.3, for example, dropped a merge-conflict skill.

The overarching message is that agents can be strong tactical programmers, but developers remain responsible for strategic choices: what the product should do, how users should experience it, and what risks are acceptable.

Guides and resources discussed

• grill me / grill with docs: Interview the developer, surface decisions, and maintain project terminology.
• wait what: Translate an agent’s explanation into plainer language.
• to spec and to tickets: Document decisions and divide the work into appropriately sized slices.
• implement / implement spec: Build tickets individually or process ready tickets in parallel.
• Code review, PR, and retro: Review implementation, describe merge risk, and suggest process improvements.

Main speakers and sources

• Kevin, the video’s narrator and presenter.
• Matt Pocock, whose skills and workflow are the subject of the video.
• Uncle Bob, mentioned as making the case during a Matt livestream.
• Dex Horthy, cited as the source of the “smart zone” term and inspiration for the PR skill.