Matt Pocock's AI Coding Workflow Fully Deconstructed: From Grill Me to Modular Development

5 Lines of Code, 7 Million Downloads

Recently, a skill called "Grill Me" has been blowing up in the AI coding community. It comes from a project open-sourced on GitHub by Matt Pocock, a top expert in the TypeScript space — the project has already earned over 160,000 stars and been downloaded 7 million times.

For those unfamiliar with Matt Pocock, here's a quick introduction: he's a legendary figure in TypeScript education who created the Total TypeScript learning platform. His courses cover core challenges from generics and type gymnastics to advanced pattern inference, and are widely regarded as the gold standard for intermediate-to-advanced TypeScript learning. Countless developers have leveled up their skills through his materials. His GitHub projects like ts-reset have also been widely adopted, demonstrating his deep understanding of the type system. The project that went viral this time is essentially his complete AI development workflow, accumulated over years, open-sourced for everyone.

What's interesting is that Grill Me — the first skill to go viral — contains only five short lines when you open the file. But many people fixate solely on this one skill, which I think is a real shame. The entire project is actually the "magnum opus" of Matt's years of experience collaborating with AI in programming — it packages the expertise of a senior engineer into a complete set of freely composable, modular tools.

This article will walk you through each piece of this workflow: starting with Grill Me, examining how the subsequent skills work together, exploring why Matt designed them this way, and comparing them with another popular toolkit called Superpowers.

Core Philosophy: Controlling AI's Randomness

Over the past year, Matt has shifted his focus almost entirely to AI-assisted development. After relying heavily on AI, he discovered that the harder problem isn't coding speed — it's how to control AI — because AI is fundamentally a black box full of randomness.

There are already several frameworks trying to solve this problem, such as Spec It and Superpowers. But Matt believes the problem with these large frameworks is that they try to take over your entire development process, locking it into a "heavy and rigid" fixed pipeline. If one early step goes wrong, the error propagates down the entire line, and fixing it often means rerunning everything.

So Matt's skills take the completely opposite approach: each one is small, easy to modify, and freely composable. This philosophy of "small and modular" is the underlying logic behind all of his subsequent designs.

Grill Me: Taking Decision-Making Power Back for Humans

The starting point of the entire workflow is Grill Me, and its purpose is simple — make the AI interrogate you instead. The core instructions in those five lines are:

• Grill me relentlessly before we reach consensus on the plan
• Follow my train of thought and expose every chain reaction triggered by each decision
• Ask only one question at a time, and always include a suggested answer
• Never sneak off to write code before we've reached consensus on the overall design

Why would an expert specifically write these five lines? It comes back to the essence of software development: writing software is essentially making hundreds of micro-decisions in sequence — how to handle exceptions, what to do with edge-case data, how to deal with extreme scenarios.

If you're in the habit of tossing vague ideas at AI and letting it figure things out by feel (i.e., vibe coding), you're essentially outsourcing all those hundreds of decisions to a black box. Vibe Coding is a concept coined by AI pioneer Andrej Karpathy in early 2025, referring to developers no longer reviewing code line by line, instead describing intent in natural language and fully trusting AI-generated results. This approach is extremely efficient during prototyping but carries enormous risk in production: AI might introduce security vulnerabilities, choose non-scalable architectures, or produce hidden bugs that are nearly impossible to debug. And because AI wants to please you, it typically fabricates whatever architecture is hardest to maintain — a nightmare for production-grade software.

Grill Me has one sole purpose: to seize decision-making power back into human hands. AI is responsible for ruthlessly uncovering blind spots you haven't thought through by following the decision tree — it only provides options; the final call always belongs to the human.

From Consensus to Implementation: The Complete Pipeline

2Spec: Write the Thinking, Not the Code

After being grilled into consensus, the moment you close the conversation, the AI loses its memory. So the second stop uses 2Spec to write the consensus into a specification document and save it. But here, Matt completely forbids AI from referencing or writing any code when writing the Spec.

The reason is a pain point well-known in software engineering: documentation can never keep up with the speed of code changes. If you include code in the spec, when the code changes in the future but the spec doesn't update accordingly, the next time you ask AI to make changes based on the spec, it gets confused by outdated old code, making things worse with each iteration. Specifications should always focus exclusively on "what problem this feature is actually solving." This echoes the concept of "user stories" in agile development — requirement descriptions should focus on user value and acceptance criteria rather than implementation details, so that even if the entire underlying tech stack is replaced, the requirements documentation remains valid.

2Tickets: Split Tasks by Feature, Not Architecture

The third step uses 2Tickets to break the spec into concrete action items, embedding an important methodology. AI has a bad habit when planning tasks: it likes to divide work by technical architecture. Take an e-commerce site as an example — it would first build out the entire database, then write the backend logic, and finally create the frontend — and the worst part is you can't test anything until the UI is done.

2Tickets forces AI to split tasks by "user features" instead: task one handles only member login (including its own database, logic, and UI), task two handles adding to cart. This way, every time a small feature is completed, you can immediately open a browser to test it, rather than blindly writing thousands of lines of code before any review. This method is known in software engineering as "Vertical Slicing," as opposed to traditional "horizontal layering" — it ensures each incremental delivery is a complete, end-to-end verifiable functional unit. It also sequences the tasks so that non-dependent tasks can be dispatched in parallel to multiple AI agents.

Implement + TDD: Preventing AI from Cheating

The implementation phase is handled by Implement, which guides the process using TDD (Test-Driven Development). Why is TDD so important for AI coding? Because AI is fundamentally a cheater at heart.

TDD was systematized by extreme programming pioneer Kent Beck in 2003. Its core cycle is Red-Green-Refactor: first write a test that must fail (Red), then write the minimum amount of code to make the test pass (Green), and finally refactor the code to keep it clean (Refactor). In traditional development, this methodology is primarily used to ensure code correctness, but in the AI coding era it has gained new life — it's essentially a "contract locking" mechanism that constrains AI's output space through pre-defined assertions.

If you let AI write the discount logic for "$100 off orders over $1000" first and add tests later, what if it writes "$200 off" instead? To pass inspection, it will simply generate a fake test that says "amount over $1000 must deduct $200, check passed" — matching wrong logic with a test guaranteed to pass, making it impossible for you to catch the bug.

TDD is specifically designed to prevent cheating: before writing any code, lock down the tests first (over $1000 can only deduct $100). At this point, the program hasn't been written yet, so running the test necessarily fails with a red light. Only after the red light appears is AI allowed to write the actual discount logic, until it turns green. This "tests before code" sequence completely eliminates AI's room to write sloppy code and call it done.

Code Review: Turning Decades of Experience into a Checklist

After code is written, a review skill is automatically triggered. It opens a completely new session to do the code review, keeping the AI in its cleanest state for inspection, avoiding interference from previous memory.

The source code of this skill is very much worth studying. Instead of vaguely writing "help me check for bugs," it takes all the universally recognized "bad code symptoms" from decades of software engineering and writes them into a concrete checklist — 12 items in total, all sourced from the classic book Refactoring. Refactoring: Improving the Design of Existing Code is a seminal work published by Martin Fowler in 1999, which systematically defines 22 "Code Smells" — these aren't bugs, but signals in code structure that hint at deeper design problems. Fowler's insight is that bad code isn't created overnight; it gradually decays through countless small design compromises. Identifying these smells and refactoring in time is key to maintaining long-term code health.

Here are three that beginners most commonly fall into:

• Shotgun Surgery: Changing a button color requires opening a dozen files, indicating that changes are scattered everywhere and need to be consolidated. This smell usually suggests the system violates the "Single Responsibility Principle," with related reasons for change dispersed across multiple unrelated modules.
• Feature Envy: Order processing code keeps reaching into the inventory file to grab data and calculate, indicating the logic is in the wrong place. In object-oriented design, this means the method should be moved to the class whose data it most frequently accesses.
• Data Clumps: Buyer name, phone number, and address always appear together, so they should be packaged into a "Contact" object rather than passed around separately. This pattern not only increases parameter list length but also hides a domain concept that hasn't been explicitly modeled.

The Secret of Conciseness: Three Principles of Prompt Writing

Each of Matt's skills is extremely short and refined, with every word deliberately chosen. There's a skill in the project called writing great skills that hides the secret. The core idea is: in front of AI, every extra unnecessary word you write gives AI one more chance to get distracted.

There's a technical reason behind this: the attention mechanism of large language models distributes computational resources across all input tokens. When a prompt is filled with redundant information, the model's attention gets diluted, and truly important instructions may be "drowned out" by noise. Research shows that shorter, more precise prompts often achieve better instruction-following rates than verbose ones.

Three principles:

1. Pruning: Delete all filler and text that could distract the AI, including instructions that "the model would know even without being told." This is why Grill Me uses only five lines.
2. Cue Words: Use professional terminology that is extremely compressed and information-dense. Saying "Data Clumps" once is equivalent to writing a hundred words of explanation — because these classic terms are deeply embedded in AI's training data. These terms have been repeatedly discussed in academic papers, technical books, and open-source code; the model has already built rich semantic associations during pre-training, and a single word can activate an entire knowledge network.
3. Completion Criteria: Give AI a clear endpoint to avoid infinite divergence.

Deep Modules vs. Shallow Modules: Fighting Fragmentation

Even with the above workflow, projects still have a hidden time bomb: over-fragmentation of logic. AI writes code too fast without any big-picture view, making it extremely prone to producing "shallow modules."

The concept of Deep Modules comes from Stanford professor John Ousterhout's book A Philosophy of Software Design (2018). Ousterhout proposes that a module's "depth" equals the ratio of its functional complexity to its interface complexity. Deep modules have simple interfaces but encapsulate vast amounts of complex implementation; shallow modules have interfaces nearly as complex as their implementation, hiding essentially nothing. This theory directly challenges the dogma of "smaller classes are always better," advocating information hiding as the primary principle of modularization.

What is a shallow module? Imagine a house divided into kitchen, living room, and bedroom — nice and clean — but with no front door. To enter the kitchen you climb through a window; to reach the living room you go down the chimney. When AI writes shopping cart checkout, it loves building houses like this: splitting checkout into five small rooms — calculate discount, validate credit card, create order, deduct inventory — but never building a unified front door to hide the details. The result is that the caller must personally handle data passing between all five rooms.

This architecture is a disaster for AI. Because AI's context window is limited — even though the latest models support 128K or even million-token windows, research shows models exhibit a "Lost in the Middle" phenomenon when processing very long contexts, with significantly decreased attention to information in the middle of the text. When code is scattered across many tiny files, AI has to frantically jump between five rooms when fixing bugs, and once the logic exceeds its memory range, it starts guessing, easily breaking working code.

Truly good architecture uses deep modules: build one extremely simple front door (like a process_checkout function) and hide the complex rooms behind it. The main program only needs to knock once and never needs to know what's inside. A classic example is Unix's file I/O system — using only five basic calls (open, read, write, close, seek), it can operate on any device from local hard drives to network storage, with all internal complexity completely hidden. Because of its strong locality, when AI fixes bugs it only needs to focus on reading one module, with all logic concentrated within its field of view, enabling precise targeting.

Matt developed the Improve Code-Based Architecture skill for this purpose — a "deep cleaning" skill. It performs a "brutal deletion test" on your code: imagine what happens if you rip out a certain module. If removing it causes chaos, it's a useful deep module; if removing it actually makes the code cleaner, it's just an unnecessary shell that should be cleaned up. It also generates an HTML diagnostic report with architecture comparison diagrams, so you can pick a refactoring plan without even looking at the code.

Comparison with Superpowers: Who Gives You Control

Finally, let's compare with another popular toolkit, Superpowers. Its greatest strength is defining the entire workflow very completely — using nine steps to force you to think through your goals and write proper documentation before you're allowed to start coding. In an era when models weren't smart enough and easily went off-track, this kind of "foolproof nanny-level process" was extremely useful.

But if you're now using models at the level of GPT-5 or Claude, Superpowers' rigid rules become a burden. Since models already have extremely strong comprehension, there's no longer a need to fill out forms and walk through nine tedious steps. This actually reflects an important trend in prompt engineering: as model capabilities improve exponentially, the optimal human-AI interaction method also evolves rapidly — from early days requiring detailed few-shot examples and strict format constraints, gradually shifting toward more concise, higher-level intent expression.

Matt's philosophy is the complete opposite: minimalism + modularity, with each skill solving only one problem. If you have a spec in hand (regardless of who wrote it), you can skip all previous steps and toss it directly to 2Tickets for task breakdown — you decide where to start. Simply put, Superpowers gives you a pre-assembled automated pipeline; Matt gives you a box of Lego bricks ready to grab and use, handing control back to the developer. This design philosophy is directly aligned with Unix design principles: each tool does one thing and does it well, and tools combine freely through standard interfaces.

Conclusion: Professional Expertise Is the Key to Mastering AI

Looking back at this entire system, what exactly does Matt rely on to tame an uncontrollable AI? In plain terms, it's his deep software engineering foundation, cleverly applied in two ways:

First is architecture — embedding decades of proven methods like deep modules and code smell detection into skills to regulate AI behavior. Second is communication — using software engineering terminology directly as prompts, where one precise term is worth a hundred words of filler, leaving AI no room to get distracted or diverge.

These two moves shatter a common myth: many people think that with AI, they no longer need to improve in their own domain. But Matt proves the exact opposite — only by becoming an expert in your professional domain can you truly control AI. This principle is known in academia as the "Automation Paradox": the more automated a system becomes, the higher the demand for the operator's professional judgment, because when automated systems fail, only true experts can identify the problem, intervene to correct it, and get things back on track.

What Matt has truly open-sourced for us was never just a few skills — he's teaching us how to use the thinking and language accumulated in your professional domain to truly master AI, this black box.