▶ YouTube Summaries

Matt Pocock — voice coach turned developer turned educator, creator of Total TypeScript and now of the widely-used grill-me skill — talks through how he builds workflows for coding agents. The throughline: when he went looking for what makes agents produce good code, what worked was not novel AI technique but 25-year-old software engineering books, used as a shared vocabulary between him and the model.

From voice coach to developer

Six years teaching singing, accents, and public speaking in London, including a master's in it. Left because doing it at a decent level required living in London, which he hated, so he taught himself development as something he could do remotely from the countryside. His first app was a web-audio spectrogram analyzer for checking students' resonant frequencies — hardcore, and it ran terribly.

Got a job in 2017 when the UK market was still easy. The communication background was an unfair advantage: near-zero technical knowledge but the ability to explain technical things, so he rose quickly. Bounced through agencies doing TypeScript and React, pushed TypeScript hard on a team whose backend kept silently changing contracts, and the velocity gain got people moved off the team.

Open source brought him into contact with David Khourshid (XState); he joined the XState core team, then Stately, which was his first job paid in American money. From there a contract at Vercel under Jared Palmer — deliberately three days a week for three months, because he was already hedging on the course idea.

Total TypeScript

Two-minute TypeScript tips on Twitter took off; follower count jumped from 4k to 10k. He partnered with Joel Hooks, did a pre-release sale while still at Vercel, and it earned 30–40x his Vercel salary immediately. The full course launched early 2023 and hit seven figures fast, later $2.5M total. Model: no sponsored content, extended refund policy, a lot of it bought through corporate education budgets. The goal throughout was high-leverage work that lets him step back to his family — he is emphatic about not working weekends and openly contemptuous of 996.

What AI changed about teaching

Knowledge is now very cheap to acquire; wisdom is exactly as hard as it ever was. Total TypeScript revenue is down because the "what" — syntax — is what agents now supply for free. He spent 2023–24 making courses about putting AI into applications, which turned out to be the wrong bet.

The turn came in December, when models got good enough to delegate to. Borrowing John Ousterhout's framing: AI has largely eaten tactical programming, and the strategic layer is what's left for humans. That is where he found a course.

Skills as a distribution mechanism

Skills are just a folder of markdown files, either model-invoked or user-invoked. He published his workflow as a skill set, didn't promote it, and came back to find it more starred than anything he'd ever done — now ~230k stars, the second most-starred skills repo and roughly the 20th–25th most-starred repo of all time. His AI Engineer London talk, "Software Fundamentals Still Matter", is at about 1.2M views.

grill-me

The most popular one and deliberately tiny: tell the agent to interview you relentlessly about the topic. The emergent behaviour is that models start thinking outside the box and throwing ideas back. Gergely's own experience — 35 questions for a simple authenticated API endpoint — was "annoying and it forced me to think more", the most involved design discussion he'd had in a long time.

The deeper point: there is a communication gap between you and the agent that everyone underestimates. However good the model, it cannot read your mind, so "just trust the model" produces work misaligned with values you never stated. Grilling is as much about establishing scope and priorities as implementation details — it is the agent getting to know you.

Splitting work across the smart zone

Following Dex Horthy's smart zone / dumb zone idea: roughly the first 150k tokens of any frontier model are the good zone, regardless of advertised context size, because every extra token competes for attention. So work larger than 150k tokens has to be portioned across sessions. Ralph loops do this by giving the agent a goal, having it make the smallest change toward that goal, then clearing context — state lives in the filesystem, not the model.

His stable version needs two document types: a spec (the destination, what used to be a PRD) and tickets broken out of it, one per session. Grill → spec → tickets → implement loop, which can span 30–40 tickets. Designed to run AFK: plan on the "day shift", let agents work the "night shift", wake up to reviewable code instead of context-switching between a dozen terminals all day.

wayfinder

For when the grilling itself exceeds one session — you cannot plan "build me a Stripe clone" in 150k tokens. The metaphor is a map with fog of war: each grilling session opens more points on the map, and tickets on it can be grilling, prototyping, research, or arbitrary tasks like provisioning infrastructure. Maps of 50–100 tickets. He has used it for course planning and for building a garden office, which raises the question of how transposable this is to non-engineering domains.

Leading words and old books

Spec-driven development gave him worse results than coding by hand, and the code degraded with each spec-change loop. Looking for why, he opened The Pragmatic Programmer — still in its plastic wrap — and found the chapter on software entropy. Agents produce entropy faster than anything before.

Then the insight that shapes everything after: those books are 25 years old, so they are in the model's priors. Repeating a phrase like "tracer bullet" a couple of times in a prompt makes the model use it in its own reasoning traces. He calls these leading words. Tracer bullets and vertical slices fixed a real failure mode — agents building the whole database, then the whole application layer, then the whole component library, only integrating at the very end, when integration is exactly where the feedback is.

From Ousterhout's A Philosophy of Software Design he mined "deep modules". From Eric Evans' DDD, ubiquitous language: a grill-with-docs skill builds a domain vocabulary as you design. Once the agent speaks your domain language, "the difference is night and day" — fewer words to describe a change, and the agent can grep the codebase for its own terminology. His example: "materialization cascade" for turning a ghost lesson inside a ghost section inside a ghost course into real ones.

Gergely's parallel: this is jargon, and jargon exists because it makes communication faster with fewer misunderstandings. Also Kent Beck and Ward Cunningham keeping a thesaurus on the desk while inventing design patterns — another full-circle moment on words mattering.

Momento-driven development

An agent is a colleague who wakes up every morning with no memory of who they are. A human can brute-force a bad codebase by accumulating scar tissue; an agent starts fresh every session. So you optimize the codebase for the permanent new starter — which is what software fundamentals were telling you to do all along. "We are our agents' platform team."

Which fundamentals, and how to learn them

Strategic programming has always been hard to learn because the feedback loop is long — people who quit after six months never meet their own strategic mistakes. The mixing-desk metaphor: sliders like how many deployable units you have (up = microservices, down = monolith), and you cannot hear what's wrong until nine months later. The one thing that shortens that loop is moving faster, which AI does — your strategic mistakes now arrive sooner. Your code is the environment the agent operates in.

The uncomfortable corollary for juniors: if strategic knowledge is now the high-leverage thing, why hire someone without it? Uncle Bob's answer was to hire them and treat them as an agent until their mistakes catch up — which Matt calls an enormous waste of money now that tactical work has gone below minimum wage in many countries. He has no answer, only the observation that the strategic layer has never been more valuable.

Selling fundamentals to non-engineering stakeholders

The same question as "how do I get time to pay down tech debt", asked ten years ago. His answer is measurement: get observability over every agent in the organization and its success/failure rate — invasive for developers, entirely fine for agents you are paying for. Someone's job should be reading that data. Some repos will have better success rates than others; propagate what they do. Organizations also need a common set of skills so teams can A/B test process changes and contribute back. Everyone working with agents needs an experimental mindset.

He runs a loop that every morning proposes an architecture improvement to his codebase, which he can one-click turn into tickets. Investing ~20% in the factory rather than the product is enormous future leverage — though you may need to hide that work until you can show results.

Local vs cloud

He is moving off his local dev setup. Collaborative grilling needs more than your terminal: you want to tag a colleague into a session, which means Slack, Discord, Teams, or Linear rather than a laptop. On a remote box he can schedule things — a morning standup with an agent that reads his Discord and plans his day — and port-forward the dev server. An expensive laptop doing this feels like wasted compute. Local is now only for debugging the remote box.

Gergely adds that Ramp, Stripe, and Uber have platform teams moving full local setups into the cloud, seeing 70–80% voluntary adoption — with front-end work the notable exception, where the feedback loop still wants to be local.

When to plan and when not to

Not everything needs grilling. Use it where the work is large and hard to roll back, because wrong code in the context window poisons everything after it and after-the-fact alignment is expensive. For a five-line fix or moving a button three pixels, shift alignment right — his video editor has a feedback button that files a GitHub issue, an implement agent picks it up, a review agent reviews it, and he aligns at the end. The decision tree: small enough to align afterwards → no grilling; fits one session → grill-me; spans sessions → wayfinder.

On the "isn't this waterfall" objection: he does aggressive upfront prototyping, which agents make cheap — build three or four versions and pick one. Gergely relays Grady Booch's point that big tech has always done mini-waterfall in two-week to three-month chunks; waterfall's actual failure was a year of planning and three years of implementation, and nobody has done that for decades.

TDD with agents

TDD optimizes for small human working memory — the failing test reminds you where you were after a coffee break. Agents have much larger working memory, so TDD aims at a problem they don't have. What agents do need is feedback loops, and a failing-test-first flow is hard for them to cheat: it forces them to build their own feedback loop and produces proof the change does what it claims. Even outside strict TDD he asks for "TDD evidence" — show me this would fail without the change. The failure mode is tautological tests that assert the implementation back at itself. Verdict: mixed, still recommended for human confidence.

Tech debt and gardening

Quoting Jared Friedman ("tech debt used to be something you had to live with in a sufficiently large codebase — no longer"), Matt's reply was "yes, now you can live with it even in a tiny codebase". Tech debt is anything that makes a codebase harder to change; agents produce it easily because they cannot think strategically. Automated review agents that enforce coding standards and catch tautological tests help — but then who reviews the reviewer.

On Lauren's "every team needs a gardener" post, his reply was that gardeners are the only thing a team needs. Diagnosing entropy before it becomes a problem may be the essential skill now.

Closing

Asked what makes a great engineer now, he answers: introspection — looking at what you do and being able to encode it into something an agent can work with. The people thriving are the same ones who were thriving ten years ago, because they were always interested in their own process.

• Books recommended :: The Pragmatic Programmer, A Philosophy of Software Design (Ousterhout), and the first three chapters of Evans' Domain-Driven Design for ubiquitous language.