AI Skills with Matt Pocock

From voice coach to educator

Before he was a developer, Matt Pocock spent six years as a voice coach, teaching singing, accents, and public speaking in London and at university [04:05]. He left because doing it seriously meant living in London, which he did not want. To get work he could do from the countryside, he became self-taught in JavaScript, motivated by building tools for his own students. His first real project was a web audio spectrogram analyzer that inspected the resonant frequencies of a voice. It "ran terribly" but made his lessons a little better, and it taught him to build ambitious things badly, fast. He landed his first developer job around 2017, when the UK market still gave motivated career-switchers a chance, and his background talking to people turned out to be an unfair advantage in interviews and on teams.

His way into open source was through XState, the state-machine library. Needing a state machine for a complex real-time application (a video call where two people navigate around a house together, via a Matterport integration), he used XState, then built tooling around it. That work caught the attention of the library's creator, David Khourshid, and Matt joined the XState core team, where he worked alongside developers like Andarist (Mateusz Burzyński) who operated at a level he had never seen [10:08]. He still rates state charts highly for certain work, though he has "ridden back" on them a little in the AI age.

That open-source visibility led to Vercel, where he worked under Jared Palmer and wrote some of the earliest Turbopack documentation, flying to San Francisco for the Next.js Conf announcement [13:10]. But his side project, teaching TypeScript, was already climbing. A pre-release sale earned roughly thirty to forty times his monthly Vercel salary, and leaving became the only rational choice.

That side project was Total TypeScript. Built with course veteran Joel Hooks, it reached seven figures fast and Matt has publicly shared a milestone of about $2.5M in total revenue [20:17]. What matters for the rest of the story is the model he chose: no sponsored content, a very generous refund policy, and a straightforward "here is a product you can buy from me." Much of that money came from company education budgets, a market Joel pushed him toward. It was, in his words, an honest model: people pay because they get value, and ask for a refund if they do not.

When knowledge got cheap and wisdom did not

Then AI happened. Matt splits what a course teaches into two layers: the syntax (the "what") and the reasoning around it (the "why"). His key claim is that knowledge is now very cheap to acquire (you can just look it up, or have an agent teach it to you) but wisdom has gotten no easier to earn [23:19]. You will still hit the same problems you would have hit without it. Total TypeScript revenue fell as a result, and he expects anyone still teaching pure tactical material to struggle.

It took him a long time and several wrong bets (including two years putting AI into applications) to find where he fit. The turn came around last December, when a stretch of time off let people hammer on the newly capable models. His realization: the AI was now good enough to delegate to. That maps onto a distinction he takes from John Amster's guest and from John Ousterhout's work: tactical programming (the moment-to-moment "what") versus strategic programming (the long-term shape). AI has largely eaten the tactical layer, he argues, and it is up to humans to own the strategic one. That is the course, and the skill set, he decided to build.

Skills as a way to package a workflow

The technical seed was the Ralph loop, a technique from Geoffrey Huntley: give the agent a goal, tell it to make the smallest possible change toward that goal, then clear your context and start again [26:22]. You are not truly starting fresh, because state lives in the file system and the codebase, just not in the model. Matt's years of piping data into agents inside applications made this feel natural: he was used to thinking about where state lives and what shape it takes when it passes into a model.

He needed a way to share these processes, and landed on skills as the distribution mechanism. A skill is really just a folder of markdown files an agent can read. Some are model-invoked (the agent decides to use them); some are user-invoked, where you trigger them yourself with a slash command [29:24]. He published his and moved on; when he checked back, the repo had more stars than anything he had ever made, purely by word of mouth. That, plus a conference talk titled "Software Fundamentals Still Matter," told him there was real hunger here, and he doubled down.

The most popular skill is grill me, and it is tiny. It just tells the agent to interview you relentlessly about what you are building. The emergent behavior is startling: the model starts thinking outside the box and throwing ideas back at you. Matt (crediting the original idea to Thariq, who works on Claude Code) describes asking for a simple API endpoint and being asked about bearer tokens versus JSON, rate-limit thresholds, and edge cases he had not considered. It felt like the involved design review you only get from a senior engineer with deep domain knowledge.

Why does such a small skill work so well? Because there is a communication gap between you and the agent that people badly underestimate [36:00]. However smart the model, it cannot read your mind; if you just say "build this," it produces something misaligned because it does not know what you consider important. Grilling does two jobs: it surfaces implementation detail, and it establishes what is in scope and what is not, letting the agent get to know your values. (Gergely adds his own rule here: as long as you keep learning from the exchange, you are fine; the danger is outsourcing the learning itself.)

From grilling, Matt built the next pieces. You turn a grilling session into a destination document (what he used to call a PRD, now just "a spec": the thing that declares when you are done). Then you break that spec into individual tickets, one ticket per session, and run an implement loop over them until a large chunk of work is finished [41:52]. He designed this to run unattended, around the idea of a day shift and a night shift: you plan during the day, the agents work away from the keyboard at night, and you wake up to clean code to review. The goal is to escape the constant terminal-to-terminal context switching and instead do focused planning in short chunks while agents grind.

Keeping work in the smart zone

The constraint that shapes all of this is context. Matt leans on Dex Horthy's idea of the smart zone versus the dumb zone [40:55]. Every token you add is another voice shouting for attention, and the more voices in the room, the harder it is for the model to hear the important ones. There is a portion of the context window where the model is simply better, and Matt puts that at roughly the first 150,000 tokens of a frontier model, regardless of the advertised window size (a one-million-token window does not change the raw amount of attention available). So the engineering problem becomes: how do you take work bigger than 150k tokens and portion it out over multiple sessions? Ralph loops were one answer; spec-plus-tickets is a more stable one.

For work too big even to plan in one session, he built the wayfinder skill [44:04]. The metaphor is a map with a fog of war: you vaguely know your destination, there are milestone points you know you must decide, and each grilling session opens up more of the map. Tickets on the map can be different types (grill, prototype, research, provision infrastructure). It lets grilling run to effectively infinite length across sessions. He has used wayfinder for maps with 50 to 100 tickets, and, tellingly, for non-technical projects too, including planning a garden office in his actual garden. Once you see it, you notice how easily these "engineering" processes map onto any domain that is really just structured decision-making.

Why agents are good at software

Agents are unusually good at software for one reason: in software, all of the inputs and all of the outputs are text based [47:02]. The code, the documentation, the instructions are text; and the outputs (test suites, type checking results, linting) are text too. The thing agents struggle with is anything non-text. His example is a UI interaction problem: if a hover animation does not feel right, how do you convey that to an agent? You can record a video, but model vision is not good enough at that yet, so non-text feedback is largely "garbage" to the agent. The lesson: the more of your work you can turn into text, the better agents perform, which is why he is trying to plug every service he uses into his agents.

This connects to a question Gergely raises from Hillel Wayne, who interviewed engineers in other fields to ask whether software is real engineering. One difference stood out: other engineering disciplines work with physical materials that have tolerances and variance, whereas software is deterministic (run it a thousand times, get the same result). Matt's take is that LLMs may reintroduce exactly that variance into software, which could make cross-pollination with other engineering disciplines newly useful.

Leading words, and going back to the classics

This is the heart of the episode. When Matt tried spec-driven development ("English is the new programming language"), he kept getting worse results than coding by hand, and the code got worse each loop. Chasing why, he opened a book that had sat shrink-wrapped on his shelf, The Pragmatic Programmer, and found a chapter on software entropy: the idea that things tend toward disorder, and that agents produce disorder faster than ever [52:40]. Almost every line felt written for today: outrun your headlights, programming by coincidence, tracer bullets.

The breakthrough was noticing what happened when he used the book's phrases in his prompts. He would say tracer bullet and the model would repeat it back in its reasoning traces ("okay, I'll turn this into a tracer bullet"). He calls this a leading word (a leitwort, a literary term for a phrase you repeat to guide a text): a simple phrase you repeat a couple of times to shift the model's behavior [53:40]. It works because these concepts are already deep in the model's training data.

The specific fundamentals he mines this way:

• Tracer bullets and vertical slices. The failure he saw with agents (including Ralph loops) was that they build the entire database layer, then the entire application layer, then the entire component library, and only plug things together at the very end, when integration problems finally surface. A tracer bullet is a thin path that works end-to-end and gives feedback fast. A vertical slice cuts through every layer at once instead of building complete horizontal slice layers in isolation.
• Deep modules, from John Ousterhout's A Philosophy of Software Design [55:00]. A massive leading word for him.
• Domain-Driven Design and its idea of a ubiquitous language [56:07]. This became the skill grill-with-docs (a domain language built as you go) and a domain-modeling skill. Getting the agent to speak your codebase's own terms is night-and-day: you describe changes in far fewer words, and the agent can navigate the codebase with a simple grep. His example of a coined term is the materialization cascade: in an app with ghost lessons inside a ghost section inside a ghost course, turning a ghost lesson real cascades up and makes the section and course real too. The agent, he notes, is actually good at inventing these terms with you.

Underneath all of it is a memorable frame for why clean code matters more now, not less: Memento-driven development [59:39]. An agent is like the character who cannot form new memories; it starts fresh every single session. A human can grind against a bad codebase until they build up mental memory of it, but an agent cannot. So you are optimizing your codebase for new starters who arrive with no context, every single time.

Learning strategic programming

If strategic judgment is what matters, how do you learn it? Matt admits it is genuinely hard, because its feedback loop is long: a strategic mistake might not catch up with you for nine months, long after the person who made it moved on. His metaphor is a mixing desk covered in sliders [1:00:42]. One slider is how many deployable units you have: turn it up and you get microservices, turn it down and you get a monolith. You are mixing something, but you cannot hear what is wrong until nine months later when the mistakes come get you.

The one thing that speeds that loop is moving faster, and AI lets you move faster, so strategic mistakes come back at you quicker. The reframe that follows is the practical core: your code is the environment the agent operates in, and you should constantly be improving that environment. Reading the classics helps mainly because it gives you the language to reason at that level.

He is blunt about training the next generation. He quotes Uncle Bob's advice to just hire someone and treat them as an agent for a while, keeping them in the tactical mindset until their mistakes surface, but calls that an enormous waste when tactical work has dropped below minimum wage in many places. Strategic understanding is now more valuable than it has ever been.

For teams, step one is observability over every single agent: what each is doing and its success and failure rate [1:06:14]. That level of monitoring would be invasive for human developers but is entirely fine for agents you are paying for. Then teams need a common set of skills so people can contribute back, run A/B tests, and compare approaches. He calls this an experimental mindset: how do we get more out of the tokens we spend? A lot of this needs no human in the loop. He runs an improve codebase architecture skill every morning that hands him a proposal, which he can turn into tickets with one button. He suggests spending maybe 20% of your time on the factory that builds your software, not just the software, as an investment in future output.

Local versus cloud, planning versus course-correcting

Matt is moving off his local dev setup and calls keeping everything local "wasted compute" [1:09:17]. The driver is collaboration: skills become collaborative when more than just you and your terminal are involved, so he wants those interactions to live where teams already work (Slack, Discord, Linear). He runs against a remote box (a Hetzner box he chats to over Discord from the train) that is always on, where he can set schedules, including a morning routine where the agent plans his day from his Discord history. The front-end is the main exception, because you still want the tight local feedback loop and low latency for UI work. The upside of cloud is that platform teams can provision the resources on demand instead of every developer juggling Git worktrees and five Docker containers locally.

On planning, there is a real tension: agents implement so fast you could just course-correct as you go. Matt's rule is that it depends on the work. Grill me is for work that is large and hard to row back from, where wrong code sitting in the context window would poison everything after it. For small changes ("move this button three pixels to the left"), you can align afterwards: shift right as much as possible [1:12:20]. He has a feedback button in his video editor that files a change as a GitHub issue, which is picked up by an implement agent, reviewed by a code review agent, and only then does he do his alignment.

That gives a clean decision treeif it is small enough to align after, skip grilling; if it fits a single session, use grill me; if it spans multiple sessions, use wayfinder. It rhymes with how mature teams already scoped work around a product requirements document.

He heads off the obvious objection that this is just waterfall. His defense is aggressive prototyping: agents make prototypes nearly free, so you build three or four versions, pick one, and iterate, which was never affordable before. And on the waterfall criticism itself, both he and Gergely note (crediting Grady Booch) that waterfall's real failure was never short planning; it was planning for a year and building for three. Short "mini-waterfall" cycles were always fine. The metaphor Matt prefers for the agentic era is agile, because the cost of change has dropped so far.

TDD, tech debt, and the gardener

On test-driven development, Matt has a TDD skill he recommends but a genuinely mixed relationship with it [1:17:30]. His argument, sharpened by talking to Kent Beck: TDD optimizes for a small working memory (a failing test reminds a distractible human where they are), but agents already have a large working memory, so classic TDD aims at the wrong problem for them.

What agents genuinely do need is feedback loops. So even when he is not doing strict red-green-refactor, he tells the agent to "provide proof that your change does the thing it is purported to do; give me TDD evidence that it would fail without this change" [1:19:55]. The other reason to force this is that agents write bad tests, especially tautological tests that just assert the implementation back at itself (declare a constant, then assert the constant equals that value). Building the failure first makes it much harder for the agent to cheat.

All of this is really about tech debt, which Matt defines simply: anything that makes the codebase harder to change over time [1:21:00]. Quoting a Jared Friedman tweet ("tech debt used to be something you lived with in a large codebase; now you can live with it even in a tiny one"), he notes agents produce rubbish easily even in one-line changes. His main defense is automated review: one agent implements, a second review agent imposes coding standards and hunts for tautological tests, improving the suite over time. It is a constant battle, not a solved problem.

This leads to the metaphor Matt most endorses, from a tweet by an engineer named Lauren: every team needs a gardener, someone watching the stream of PRs for the weeds (the lint suppressions creeping across the codebase) [1:30:51]. Matt would go further: the only thing your team needs are gardeners. We are now our agents' platform team, building the environment in which they can succeed, and diagnosing entropy before it becomes a problem may be the essential skill.

Asked what makes a great engineer now, his one word is introspection [1:32:23]. The ability to look at what you do and put your process into words the AI can work with, which is exactly what his skills are. He points to Lars Grammel, who works on the Vercel AI SDK and is building an entire software factory for his heavily-used open-source library.

Teaching, advice, and the books

Matt does live outside London, away from Silicon Valley, and treats that as a feature: he cannot predict the future or get privileged access to what the labs are doing, so he just plow[s] my own furrow and focuses on what works right now, from the countryside where his family is [1:22:32]. The narrowed scope, he thinks, is part of why his approach works.

On teaching, the durable value is curation, which is itself strategic and not something AI is good at. He thinks of information as a graph where each piece depends on others, and his job as finding Dijkstra's shortest path through that graph so you learn it in the most sensible order [1:25:34]. An agent that just "teaches you everything" misses that human curation.

He is candid that his own success is largely luck and timing: the industry shifted in about seven months, faster than ever, and his pivot from tactical TypeScript to strategic work happened to land at the right time [1:26:20]. He resists narrativizing it as cleverness.

His advice for juniors is directuse agents as much as possible, because that is how people now work, and stay curious and adaptable [1:29:21]. He would love to be a junior today. The people thriving now are the same ones who thrived ten years ago: the naval gazing programmers who are endlessly interested in their own process and in making better software.

And the closing recommendation, which is also the episode's thesis in miniature: read the classics. His recommended first three chapters of Eric Evans' Domain-Driven Design (for ubiquitous language and domain modeling), plus A Philosophy of Software Design, The Pragmatic Programmer, and, waiting on his shelf, The Mythical Man-Month [1:33:51]. The irony Gergely draws out at the end: the best practices documented 20-plus years ago do not just still work, they matter more when you write code with agents, because the agent has no long-term memory and reads your codebase fresh every single time.

Tools and resources

Claims to verify

• Total TypeScript reached seven figures quickly; Matt has publicly cited about $2.5M total revenue.
• His skills repo has grown extremely large (he cites a very high star count and a top-25 all-time ranking); the exact figure is worth checking against the live repo.
• His "Software Fundamentals Still Matter" talk (AI Engineer, London) is cited at over a million views.
• The origin of the "interview the user" idea is credited to Thariq (Claude Code); the name is a lower-confidence transcription.
• The claim that most developers at companies like RAMP, Stripe, and Uber voluntarily choose cloud agents (70-80%), except for front-end work, comes from the conversation and is not independently verified here.

Glossary

• skill: A folder of markdown instructions an AI agent can load to perform a defined workflow.
• model-invoked skill: A skill the agent itself decides to use based on the task.
• user-invoked skill: A skill you trigger yourself, usually with a slash command.
• slash command: A typed command (e.g. /grill) that invokes a skill or built-in action in an agent tool.
• harness: The software layer wrapped around a model (tools, memory, context management, loop) that turns a raw model into a working agent.
• context window: The total amount of text a model can consider at once, measured in tokens.
• token: The unit models read and generate; a chunk of text roughly a few characters long.
• smart zone: The early part of the context window (Matt: ~first 150k tokens) where the model reasons most reliably; the "dumb zone" is the degraded remainder.
• Ralph loop: A pattern (Geoffrey Huntley) where the agent makes the smallest change toward a goal, then clears its context and repeats.
• spec: The destination document that declares what "done" means for a piece of work.
• PRD: Product requirements document; a spec of what a feature must do, used to align a team before building.
• ticket: One scoped unit of work, sized here to fit a single agent session.
• grilling: Having the agent interview you relentlessly to surface decisions and scope before it writes code.
• wayfinder: Matt's skill for running grilling across many sessions using a map with milestones and a "fog of war".
• leading word (leitwort): A term you repeat in prompts to steer the model's behavior, drawn from vocabulary already in its training data.
• tracer bullet: A thin end-to-end path built early to get fast feedback, instead of finishing each layer in isolation.
• vertical slice: A feature built through every layer at once (vs a horizontal slice, which builds one complete layer across the whole system).
• software entropy: The tendency of a codebase to drift toward disorder over time; agents accelerate it.
• deep module: A module with a simple interface hiding significant functionality (from Ousterhout); a sign of good design.
• Domain-Driven Design (DDD): An approach (Eric Evans) that models software around the business domain and its language.
• ubiquitous language: A shared vocabulary used consistently by people and in the code, central to DDD.
• domain modeling: Defining the core terms and relationships of a problem domain so code and conversation match.
• materialization cascade: Matt's coined domain term for a change that propagates up a hierarchy (a "ghost" child becoming real makes its parents real).
• TDD: Test-driven development; write a failing test first, make it pass, then refactor.
• TDD evidence: Proof the agent provides that a change would fail without it, even when not doing strict TDD.
• tautological test: A worthless test that asserts the implementation back at itself rather than real behavior.
• tech debt: Anything that makes a codebase harder to change over time.
• idempotency: The property that repeating an operation has the same effect as doing it once; a classic reliability concept Matt cites.
• finite state machine: A model of computation with defined states and transitions; the basis of XState.
• XState / state chart: A JavaScript state-machine library and the visual formalism it implements.
• Turbopack: Vercel's build system, a successor effort to Webpack.
• AI SDK: Vercel's toolkit for building AI features into applications.
• git worktree: A separate working directory tied to one git repo, letting you run parallel branches/agents.
• AFK: Away from the keyboard; running agents unattended.
• day shift / night shift: Plan with agents during the day; let them execute unattended overnight.
• compaction: Compressing or clearing an agent's context to stay within useful limits.
• platform team: The team that builds the internal environment and tooling others (or agents) build on top of.
• observability: Instrumentation that shows what a system (or agent) is doing and how often it succeeds or fails.
• spec-driven development: Writing an editable specification and having the agent produce code from it.
• shift right: Deferring alignment/decisions until after implementation when the work is small enough to correct cheaply.
• tactical vs strategic programming: Ousterhout's split between short-term "get it working" coding and long-term codebase shape.
• coding agent: An LLM-driven system that reads and writes code, runs tools, and iterates toward a goal.
• Memento-driven development: Matt's framing that agents have no memory between sessions, so codebases must be optimized for perpetual new starters.