AI Skills with Matt Pocock

Before software, Matt Pocock spent years teaching voice, singing and public speaking. Building tools for his students, including an ambitious but poorly performing audio-analysis application, helped lead him toward a career he could pursue outside London.

His engineering path included agencies, TypeScript, XState and Stately, followed by a short part-time period at Vercel while testing a course business. He describes Total TypeScript's success as a way to do work with more lasting value and spend time with his family. The revenue discussed in the interview is gross business revenue with a partner split and expenses, not his personal take-home income.

That background matters because teaching and explaining remained central. His later AI skills are an attempt to express a process clearly enough for other people to inspect, modify and use, rather than distribute an opaque piece of automation.

Pocock distinguishes teaching what to write from teaching why a design makes sense. He says AI has made access to syntax and tactical knowledge cheaper, while longer-term judgment remains difficult to acquire.

His own experiments putting agents inside applications initially did not become the business he expected. They did teach him to think about data flow: where state lives, what shape enters a model, which instructions have priority and what survives a cleared context.

When he began building agent loops, that experience transferred. He saw a process that could be described in terms of states, events and information moving between steps. Skills became a way to distribute those processes. His account of what became possible with particular models is historical personal experience, not a guarantee that every agent can now run unattended.

The host describes using Grill Me for a seemingly simple subscriber-checking API. Questions about authentication, rate limits and scope turned it into a deeper design discussion than he had expected.

Pocock explains the skill as a small instruction to interview the user persistently. The benefit is not a required number of questions. It is exposing decisions the person knows how to make once they stop to consider them, and identifying questions that need research.

He emphasizes a communication gap: a model cannot automatically know the user's priorities. Clarifying what belongs in scope and what matters is as important as implementation detail. The host values remaining responsible for those choices instead of handing over an underspecified goal and discovering the decisions afterward.

Pocock's planning process separates a description of the destination from the units of implementation. The specification says what reaching the end means; tickets divide the work into pieces that can be handled in separate sessions.

His reasoning is that more context competes for attention and can degrade performance. The interview includes a numerical estimate of a useful context region, but it is his working heuristic, not a measured universal limit for every model or task.

A new session is not starting with nothing: the repository, documents and environment preserve state outside the model. He wants substantial planning to permit longer blocks of implementation and later review, rather than constant terminal switching. That workflow preference does not imply permission to publish unreviewed changes or skip the original task's constraints.

A single clarification session can also outgrow its useful context. Wayfinder introduces a map of decisions, known destinations and still-unexplored questions. Each session needs its own purpose and enough knowledge of decisions made elsewhere.

The tickets need not all be conversations. A question may require a prototype, research or a practical provisioning task. Those activities expose more of the map and can change what should be decided next.

Pocock has used the approach for course planning and a garden office as well as engineering. The transferable idea is visible shared state and deliberate uncertainty reduction, rather than a claim that any project can be solved by writing a sufficiently long initial plan.

Pocock says a specification-only approach disappointed him when repeated edits produced worse code. Bad tests gave the agent poor feedback, and building complete database, application and UI layers before connecting them delayed discovery of integration problems.

He returned to The Pragmatic Programmer and concepts such as tracer bullets and vertical slices. Instead of completing each layer in isolation, build one working path through the necessary layers, observe it and expand from there. What happens in the database may change what the interface needs to show.

He calls phrases such as “tracer bullet” leading words: concise terms that seem to bring useful concepts into the model's work. That is his observation about prompting, not proof of the exact books in a model's training set. Repeating the words is useful only if the agent actually changes its behavior and receives meaningful feedback.

Pocock draws another idea from domain-driven design: use a shared language for the application. The vocabulary should appear in the conversation, documentation and code so that the agent can find the relevant concepts.

His example concerns a draft lesson inside a draft section and course. Making the lesson real may require making its parents real too. Calling that a materialization cascade gives the participants a compact name for a complicated behavior.

The goal is a precise connection between a term and the underlying rule, not jargon for its own sake. He compares a fresh agent session to a new starter who needs a navigable codebase. That metaphor explains the importance of structure without asserting that every tool lacks every form of persistent memory.

Pocock compares architecture decisions to a mixing desk whose result cannot be heard until months later. Moving a slider toward more services or toward a monolith is easy; learning the consequences can take much longer.

He thinks faster agent-assisted production can make mistakes visible sooner. The host asks whether easier repairs might also make the learning less memorable than a serious failure. The conversation does not resolve how organizations should train the next generation of engineers under those conditions.

Pocock admits uncertainty about junior hiring and development. His stronger claim is that understanding code, consequences and the longer view becomes more valuable when a person can direct more production. That is a reason to inspect the environment the agent works in, not to abandon tactical understanding altogether.

Asked how to justify investment in fundamentals, Pocock proposes observing what agents do and where they succeed or fail. Differences among repositories may reveal useful practices that can be shared.

A common workflow and skill set can make experiments comparable. People can try variations and contribute what they learn. The host adds the human loop: colleagues still need to discuss what worked, what did not and where people should retain full responsibility.

Automated architecture proposals are one of Pocock's examples, but their presence is not evidence that every proposal should be accepted. Time spent improving the production process needs results, just as feature work does. The interview does not establish a universal percentage of engineering time for that investment.

Pocock is exploring a remote machine accessed through Discord, where he can work away from his laptop and run scheduled processes. His larger argument is that a team's agents and planning conversations should be accessible to colleagues, rather than isolated in one person's many terminals.

The host raises replication of complicated development environments and frontend feedback as practical concerns. Latency-sensitive work and interaction problems can make the arrangement less straightforward. A forwarded development server may help, but neither speaker demonstrates that it removes every exception.

This is an account of his setup and direction of experimentation, not a universal claim that local development is obsolete or that a cloud machine automatically provides a secure, collaborative workflow.

Pocock explicitly says not to use Grill Me for everything. A small, obvious change can be implemented and checked afterward. A larger choice that would be expensive to unwind benefits from alignment before the wrong code influences later work.

His rough distinction is a small change that can be inspected directly, a clarification task that fits in one session, or a larger planning effort that needs Wayfinder. The boundary is the nature of the work, not a ceremony every change must pass through.

He also emphasizes aggressive prototyping before committing to a specification. Cheap prototypes can expose what a solution should look like. Planning in this account includes learning from those experiments; it is not a defense of a fixed multi-year plan immune to new evidence.

Pocock has a mixed view of TDD. He values the feedback of seeing a failure first and the evidence that a change addresses it, while questioning whether a workflow designed around a human's small working memory is always the right fit for an agent.

Even outside a strict red-green-refactor sequence, he asks for evidence that would fail without the change. A test that repeats a constant or simply restates the implementation supplies little confidence about useful behavior.

The important distinction is the quality of the signal. A test suite can guide an agent badly as well as well. The interview does not prove an agent cannot game a test; it argues for examining the evidence rather than counting tests as an automatic quality improvement.

Pocock defines technical debt in terms of making future changes harder. An agent can introduce it even in a small repository or a tiny patch. A separate review process may help identify poor tests or standards violations.

He immediately asks how one knows that reviewer is doing a good job. Adding a review agent does not remove the need to evaluate the review. The recurring task is to keep the codebase understandable and changeable as output increases.

The same judgment appears in his view of education: arranging a graph of ideas into a useful learning path is curation. He credits timing and luck in his business transition rather than claiming that success proves he can predict the industry's future.

For people learning now, Pocock encourages building real things with agents while remaining curious about both the code and the process. His old audio application would have benefited from help investigating performance, but understanding why it was slow would still matter.

The gardening metaphor brings the conversation together. Someone needs to notice accumulating suppressions, confusing boundaries and fragile workflows before they overwhelm the repository. Pocock describes engineers as the platform team for their agents: they shape the conditions in which work succeeds.

His final emphasis is introspection: examine what you do, put the process into words, try an improvement and assess the result. The skills are one expression of that practice, not a replacement for the judgment that makes the process worth repeating.