Matt Pocock on AI Skills and the Software Fundamentals That Still Matter

Matt Pocock talks with The Pragmatic Engineer about his path from voice coaching to software education and about using AI agents without losing sight of software fundamentals.

Pocock began as a singing and voice teacher, studied the field deeply and worked with performers and public speakers. He eventually wanted a career that could give him more flexibility outside London.

He had built software to support teaching and became interested in programming. His experience communicating with students helped him explain his work and navigate interviews as he entered the technology industry.

His early development work exposed him to JavaScript, React and TypeScript, as well as the practical difficulties of team development. He began participating in online technical communities and open source.

At Vercel, Pocock arranged an unusual part-time contract: three days a week initially. That gave him room to explore TypeScript educational material alongside his work.

His TypeScript course presale grew quickly, eventually making it difficult to keep both commitments. He left Vercel to focus on education, building Total TypeScript with support from collaborators.

Pocock describes the work behind workshops, free explanations and paid courses. The host mentions that Total TypeScript reached $2.5 million in total revenue, a milestone Pocock shared publicly.

He sees paid education as a way to fund sustained teaching. The value is not simply a collection of syntax facts, but helping learners understand why techniques matter and when to use them.

AI changes how people access explanations and practice. Pocock argues that teaching still involves selecting a path, building motivation and helping someone connect concepts to their own work.

As coding agents improved, Pocock began experimenting with small loops and pipelines. He noticed that tailored workflows could produce different results from simply accepting the default interaction.

He describes skills as reusable folders of instructions that an agent can invoke when relevant. They package a workflow so it can be repeated, inspected and adapted rather than explained from scratch each time.

Pocock’s talk “Software Fundamentals Still Matter” motivated him to encode established engineering ideas in agent workflows. He expects people to modify skills for their own needs.

The popular “grill-me” skill asks the agent to interview the user about a proposed change. Its questions can expose assumptions about authentication, data, constraints and other decisions before implementation.

The interviewer shares that a simple endpoint prompted dozens of questions and felt intense. Pocock values the friction when it reveals decisions that would otherwise have been made silently by the agent.

Pocock frames this as a communication gap: an agent cannot infer all of a developer’s values or preferences from a short instruction. A structured conversation gives both sides a clearer shared target.

He describes a “smart zone” in which an agent has enough relevant context to work effectively, and a degradation as a long session accumulates material. These are practical heuristics from his experience, not universal model limits.

One response is to split work into smaller sessions and preserve decisions in a spec or in the codebase. A fresh agent can read those artifacts instead of relying on the entire history of a conversation.

Pocock describes a day-shift and night-shift pattern: use active time to plan and align, then let agents execute suitable tasks unattended. The pattern requires choosing work that can be checked and safely delegated.

His more ambitious wayfinder skill helps navigate a larger set of related decisions. He compares it to revealing a map through successive conversations rather than assuming every detail is known at the start.

The pair consider why software is a good fit for agents: code, documentation, tests and diagnostics are text-like artifacts, and execution can provide feedback. That feedback does not eliminate the need to check whether the task itself is correct.

Pocock returns to older programming literature instead of discarding it when models improve. He found that changes made quickly through an agent could still degrade code structure and tests over repeated iterations.

He revisited ideas about software entropy and technical debt: a system can become harder to change as small compromises accumulate. Fast code generation does not remove the cost of poor design.

One useful phrase is “tracer bullet”: build a thin, working path through a system to learn whether the important pieces fit together. That can reveal integration problems earlier than finishing each layer in isolation.

The related idea of a vertical slice delivers a small end-to-end capability. Pocock found that naming such patterns in prompts gave him and the agent a shared vocabulary for the desired approach.

He calls these terms “leading words”: compact cues that point toward established practices. A useful phrase still needs enough context and review; merely naming a pattern does not ensure sound implementation.

Domain-driven design offers another shared language. Pocock describes using explicit names for concepts in the product so that humans and agents can discuss the same entities and transitions.

Developing that language can expose ambiguous cases, such as what changes when a placeholder lesson becomes a real lesson. The agent can propose terms, but the people responsible for the product must decide what they mean.

The host asks how developers can learn fundamentals when architectural mistakes may not become visible for months. Pocock compares strategic programming to adjusting a mixing desk without immediately hearing the long-term effects.

Faster implementation can create more opportunities to learn, but faster output can also spread mistakes. Understanding code, system boundaries and constraints helps developers decide what to keep and what to change.

The discussion considers how to explain investment in software quality to non-engineering stakeholders. Observable outcomes such as change speed, reliability and recurring defects can make the tradeoff more concrete.

Pocock recommends observing agent sessions and learning from where they struggle. Small improvements to instructions, tests or code structure can compound across repeated tasks, although they still need verification.

On local versus cloud agents, he describes moving more work to a remote environment where sessions and schedules can run independently. He recognizes that complex local setups and fast visual feedback can make the choice different for other teams.

Pocock does not use grill-me for every task. A small, easy-to-review change may be quicker to implement and inspect first, while an ambiguous or consequential project benefits more from upfront questions.

The host compares planning with rapid prototyping. With implementation becoming cheaper, teams can sometimes build several alternatives, inspect them and revise the plan, while still retaining enough direction to avoid aimless work.

They discuss test-driven development. Pocock values tests that provide an external signal about behavior and can fail for a meaningful reason, rather than tests that merely repeat the implementation.

A strong test suite can make a codebase easier to change, but AI-generated code and AI-generated reviews can both be wrong. Humans still need to assess whether the tests and the review address the real risk.

Asked about working outside London, Pocock describes valuing proximity to family and building a business that fits his circumstances. He recognizes that career paths and available opportunities differ.

On teaching, he argues that a human educator provides more than answers: they select a sequence, convey enthusiasm and help learners see why the material matters. AI can be a useful supplement to that relationship.

For junior engineers, Pocock emphasizes curiosity and adaptability. Agents can offer explanations and surface possible problems, but a learner still benefits from building things and examining why a suggestion works.

The hosts use a gardening metaphor for maintaining an environment where agents can succeed: watch the stream of changes, notice accumulating problems and improve the conditions around the work.

Pocock says creating workflows and reusable skills can be rewarding engineering work in its own right. The goal is to improve the codebase and the team’s ability to make sound changes over time.

For further reading, he recommends domain-driven design material for its treatment of shared language and modeling. The host closes by returning to the value of established engineering ideas in an age of agents.