Matt Pocock: Faster AI Coding Needs Stronger Engineering Fundamentals

Original video: AI Skills with Matt Pocock

The Pragmatic Engineer · 2026-09-17 · 96 minutes 36 seconds

Host: Gergely Orosz · Guest: Matt Pocock, creator of Total TypeScript and AI Hero

Supporting primary sources: Official episode and transcript · Matt's skills repository

This article draws on the complete English automatic captions, cross-checked against the publisher's transcript. Timestamped links point to the original video. The guest's practical judgments retain their stated limits.

Gergely Orosz wanted a small API endpoint. An event organizer with an authorized credential would check whether an email address belonged to a paid subscriber, allowing subscribers to receive priority access.

He invoked Matt Pocock's grill-me skill and received 35 questions. Authentication, credential placement, rate limits, and the strictness of those limits all became explicit design decisions.

Orosz found the discussion irritating and useful. It had been a while since someone had examined a seemingly simple feature so closely. Crucially, the questions brought important choices back to his attention.

That experience runs through the interview. AI can generate code quickly, while engineers still need to clarify the goal, assess the evidence, and maintain the environment in which the next change will be made. Pocock is packaging those activities into small, editable skills.

Knowledge is cheaper; judgment still takes practice

Pocock spent 6 years as a voice coach, teaching singing, accents, and Shakespeare, as well as public speaking at consulting firms. Wanting work he could do outside London, he taught himself JavaScript and made tools for his students. An early project was a voice spectrogram analyzer that worked poorly but improved his lessons.

He entered the software industry around 2017, later contributed to XState, worked at Stately, and joined Vercel. His communication and teaching experience remained useful as he learned to explain technical ideas and build courses.

At Vercel, he negotiated a contract for 3 days a week, keeping the other working days for Total TypeScript. Strong course presales eventually persuaded him to pursue education full time. The episode discusses a cumulative revenue milestone of $2,500,000, before revenue sharing and expenses. It was not his personal net profit.

AI subsequently reduced revenue from that course. Pocock does not quantify the decline, but he acknowledges that demand for syntax instruction has changed.

He sees technical education as teaching both how to write something and why it should be written that way. The former is increasingly easy to look up or delegate. The latter involves tradeoffs, constraints, and consequences that still require experience.

Drawing on John Ousterhout's distinction between tactical and strategic programming, Pocock argues that AI can handle much of the implementation while people pay more attention to how software evolves. This is his assessment of the work, not evidence that every engineering task can be automated.

grill-me exposes the communication gap

In the discussion of reusable skills, Pocock returns to a simple limitation: a capable model cannot know priorities that its user has never expressed.

A request can conceal many assumptions. Who may call an endpoint? What latency is acceptable? Which features are outside the scope? How much complexity is justified by an edge case? An agent that starts coding immediately will fill those gaps somehow.

grill-me moves that discussion forward. It directs the agent to keep asking questions until the goal, scope, and consequential choices become clear. Pocock credits Anthropic's Thariq Shihipar with the inspiration: having the agent interview its user can work better than expecting a complete specification in the first prompt.

Orosz's subscriber endpoint illustrates the value. Questions about authentication and rate limiting let him choose which complexity to accept and identify knowledge he needed to acquire. The model surfaced decisions for a person to make.

Pocock reports roughly 230,000 repository stars and 1,200,000 views for a related talk at the time of the interview. These are his distribution figures from that period, not measures of productivity improvement.

His design criteria for skills are more actionable: keep them small, understandable, editable, and composable. A process that users can inspect is also a process they can repair.

Specifications and tickets divide work across sessions

Once a goal is clear, the next problem is completing work larger than a single useful conversation.

In the context discussion, Pocock uses Dex Horthy's smart-zone and dumb-zone framing. As a conversation grows, old debates, irrelevant files, and failed attempts compete for attention, making important connections easier to miss.

He estimates that the more reliable working region of frontier models at the time extends through roughly the first 150,000 tokens. That is a practical estimate, not a measured threshold shared by all models. Advertised context capacity does not guarantee equally reliable use of everything it holds.

His workflow separates information into two levels. A specification describes the destination and what completion means. Tickets describe the smaller pieces that individual sessions should implement. One specification might cover 30 to 40 tickets, with each session receiving the information relevant to its task.

Clearing a conversation does not erase the code, documents, or task state stored outside it. The next agent continues from those organized artifacts instead of depending on an increasingly long chat history.

Pocock calls the rhythm a day shift and a night shift. People concentrate on planning and decisions, agents receive uninterrupted execution time, and people review the result. The aim is to reduce terminal switching and interruptions so delegation actually releases attention.

Wayfinder keeps a map of decisions

Sometimes the planning itself is too large for one session.

Wayfinder maintains a shared map of the destination, decisions already made, dependencies between decisions, and unresolved questions. Each session handles a node, records the result, and helps determine the next step.

A node can be an interview, research, a prototype, or infrastructure preparation. Pocock describes maps containing 50 to 100 tickets and says he has also used the approach for course design and planning a garden office. These are examples from his own practice.

The map leaves room for uncertainty. An untested idea can remain unresolved until research or a prototype supplies evidence. The eventual specification incorporates what the exploration discovers.

Pocock explicitly rejects a lengthy interview before every change. The cost of correcting a misunderstanding determines how much alignment should happen first:

He also prototypes extensively before settling a specification, comparing alternatives through working examples. Planning and experimentation can alternate. The process should be proportionate to the problem.

Established engineering terms make intent easier to express

Pocock experimented with repeatedly editing a specification and having an agent revise the implementation to match. The code became harder to maintain. Weak tests then supplied weak feedback to subsequent work.

Revisiting The Pragmatic Programmer gave him a vocabulary for the behavior he wanted. His concrete example in the interview is a tracer bullet: establish a minimal, real path through the system that actually runs.

Agents had been building a complete database layer, then an application layer, then frontend components, connecting them only near the end. Problems with interfaces and data models emerged late.

A vertical slice implements a small part of the database, business logic, and interface together. Feedback arrives earlier, allowing the next increment to build on connections that have already been exercised.

Pocock found that terms such as tracer bullet, vertical slice, and deep module changed how agents approached a task. He calls them leading words. The conversation suggests they may activate concepts already learned by a model, but it does not establish particular training data or offer a controlled comparison.

He also borrows shared domain language from Eric Evans's domain-driven design. In his course management application, turning a placeholder lesson into a real file can require its containing section and course to become real too. He and an agent named the related behavior the materialization cascade.

Subsequent discussions can refer to that same behavior by name. The grill-with-docs skill incorporates naming and documentation into the design conversation, bringing the language of the code, documents, and people into alignment.

A term earns its value through a shared definition. A name saves explanation when everyone connects it to the same behavior.

A codebase should make sense to a new colleague

Pocock uses Memento as an analogy: what working environment would help someone who wakes up unable to remember the previous day?

A longtime contributor may remember why a module behaves strangely or why a test regularly fails. A fresh agent session usually lacks that tacit knowledge. Even products with memory features need relevant context to be preserved and supplied.

Clear names, sensible module boundaries, trustworthy tests, and recorded design decisions reduce repeated rediscovery. The codebase becomes the environment that enables the agent's next piece of work.

Pocock attributes part of agents' usefulness in software to the availability of textual input and feedback. Source code, documentation, type errors, test failures, and checking results can all be read and used in another attempt.

Subtle interaction problems are harder. Whether a hover animation feels right or an interaction behaves as intended requires observation. His remarks describe his experience with the tools at the time, not a universal claim that visual models cannot handle interface work.

An editorial lesson follows from these examples: an agent needs the conditions to observe a failure, understand it, and try again, alongside the task itself.

TDD can be debated; evidence still matters

Pocock holds two positions together in the TDD discussion. He still recommends test-driven development, while questioning whether an agent needs to copy every part of a human working rhythm.

Writing a failing test, implementing the behavior, and then refactoring can help a person with limited working memory who gets interrupted. The failing test preserves a reminder of unfinished work. An agent can hold more information within a session, prompting Pocock to reconsider that part of the rationale.

He has not abandoned testing. Increasingly, he asks for evidence that a change produces the intended behavior and that the relevant check would fail if the change were absent.

That is more specific than reporting that the test suite passes. A test that merely duplicates the implementation, such as checking a constant against the value just assigned to it, does not establish the behavior a user needs.

Pocock puts a review agent after an implementation agent to look for ineffective tests and code quality problems. He immediately raises the next question: how does anyone establish that the reviewer is doing a good job?

Automated review adds feedback without removing responsibility for acceptance. After generation, someone still has to examine what the software does and which failures its verification can actually detect.

Teams need shared practices and visible failures

Pocock suggests recording what agents do, which tasks succeed, and which fail. Teams can compare repositories and workflows, then incorporate effective practices into shared skills.

These are proposed improvements rather than results from a controlled organizational study. They do make the discussion more concrete: did a task fail because the requirement was unclear, the context was confused, the environment was broken, or the check was unreliable?

He is also moving work to remote agents. On the train to record the episode, he used Discord to communicate with an agent on a Hetzner server, improving course tooling and addressing student feedback. A machine that remains online can keep executing tasks and scheduled work.

The larger attraction is collaboration. Colleagues can enter the same discussion, understand decisions already made, and help continue the work. Processes confined to individual terminals make that harder.

The conversation retains practical qualifications. Reproducing complex local environments, maintaining timely frontend feedback, and dealing with latency can all affect the choice. Pocock describes his own direction of travel.

Juniors need practice; teachers need to organize the path

Strategic judgment is difficult to learn because consequences can emerge much later. A decomposition that initially seems sensible may become a burden only after a system evolves. Faster code generation does not automatically shorten every feedback cycle.

Pocock offers no complete answer to how junior engineers will acquire years of experience. His advice to newcomers is to use the tools on real projects while remaining curious about both the code and the process that creates it.

Design questions can become learning opportunities. Difficulty explaining an authentication choice, a data relationship, or the purpose of a test reveals a specific topic to investigate. The useful part is participating in the judgment and following its consequences.

This also explains his continuing belief in teaching. Knowledge forms a graph of dependencies. Teaching organizes it into a path: what to understand first, what to practice next, and which misconceptions need attention.

Models can provide many explanations, while the selection and sequencing of a course retain value. Pocock's move from TypeScript syntax toward AI workflows shifts his teaching toward that work.

Engineers also tend the environment their agents work in

Near the end, the conversation turns to the gardener in a codebase: someone who watches incoming changes, notices tangled dependencies, weakening rules, and modules that are becoming difficult to modify, then acts before the problems spread.

Pocock likens engineers to an agent's platform team. Alongside queuing the next feature, people maintain the execution environment, decide which feedback deserves trust, identify reusable practices, and recognize shortcuts that create future costs.

His reading recommendations follow the same themes. The Pragmatic Programmer offers ideas about feedback and software entropy. John Ousterhout's A Philosophy of Software Design addresses complexity and module design. The early chapters of Eric Evans's Domain-Driven Design help establish shared language.

The interview suggests a practical sequence: scale discussion to the task, preserve agreed goals and decisions, expose implementations to feedback early, check real behavior, and keep improving the codebase and the process.

AI increases the speed of code generation and the speed at which poor decisions can be repeated. Skills can preserve engineering experience. Their value ultimately needs to show up in easier subsequent changes, earlier detection of errors, and a team that understands its system more clearly.