At AI Engineer Europe, Matt Pocock — founder of Total TypeScript and the educator behind the AI Hero platform — gave a short talk titled "It Ain't Broke: Why Software Fundamentals Matter More Than Ever." For engineers worried that their skill set has been quietly rendered obsolete by AI, his message is unexpectedly comforting: software fundamentals are not in retreat. They matter now more than they ever have.
Matt is not a new face in the developer world. He was previously a Developer Advocate at Vercel, a core team member on XState, and the creator of Total TypeScript — a series widely treated as the industry standard for TypeScript education. Over the past year he has shifted his center of gravity from TypeScript to AI engineering, building out his own platform AI Hero, whose community now counts more than 54,000 developers. His YouTube channel (@mattpocockuk, 175K subscribers) carries a motto that reads almost as a manifesto: "We don't do vibe coding — this is a channel for real engineers." That trajectory — from TypeScript educator to AI engineering educator — places him at the unusual intersection of old-school software craftsmanship and bleeding-edge AI tooling, and it's a large part of why this talk lands with the weight it does.
His thesis is direct: good codebases are more valuable than ever, because AI performs remarkably well in them and remarkably badly in bad ones.
Why Specs-to-Code Doesn't Hold Up
Matt opens by addressing the recently popular "specs-to-code" movement — the idea that you write a specification, let AI compile it into code, and when something breaks you go back and edit the spec rather than the code itself. He admits he tried it. The first run produced mediocre code. The second produced worse code. The third was worse still. Eventually he was left with garbage.
He found a name for this phenomenon in The Pragmatic Programmer: software entropy. Every change made without thinking about the design of the whole system pushes the codebase further toward collapse. The premise behind specs-to-code is that "code is cheap," but Matt pushes back hard on this. Bad code, he argues, has never been more expensive — because a codebase that's hard to change locks you out of every benefit AI could offer.
Failure Mode 1: The AI Built the Wrong Thing → Use "Grill Me" to Build Shared Understanding
Matt draws on Frederick P. Brooks' The Design of Design and its concept of the design concept — when two parties design something together, the thing being designed floats invisibly between them. It's a theory, not an asset; nothing you can put in a markdown file. The core problem between you and the AI, he argues, is that you don't yet share one.
To fix this he wrote a skill called "grill me." Its content is dead simple: interview me relentlessly about every aspect of this plan until we reach a shared understanding; walk down each branch of the design tree, resolving dependencies between decisions one by one. The repository hosting this skill has accumulated tens of thousands of GitHub stars. The few short lines turn the AI into an adversary that fires forty, sixty, sometimes a hundred questions at you before it's satisfied. Matt prefers this flow over the default plan mode in Claude Code, which he finds too eager to generate an asset rather than first reach a shared design concept.
Failure Mode 2: The AI Is Too Verbose → Build a Ubiquitous Language
The second failure mode is the AI talking past you, using too many words to say what it's doing. Matt compares this to the language gap between veteran developers and domain experts — if a domain expert wants you to build something around microchips and you have no shared vocabulary, the translation into code breaks down at every step.
He turns to Domain-Driven Design for the answer: the concept of a ubiquitous language. Conversations among developers, expressions in the code, and conversations with domain experts (or, in this case, with AI) should all derive from the same domain model. He built a skill that scans a codebase, extracts terminology, and emits a markdown file of tables. He keeps that file open during planning sessions. Reading the AI's thinking traces, he noticed that a shared vocabulary not only sharpened planning but also let the AI think more concisely — and produced implementations that hewed closer to what was actually planned.
Failure Mode 3: The AI's Code Just Doesn't Work → TDD Forces Small Steps
The third failure mode is straightforward: the AI built the right thing but it doesn't work. Matt insists on every feedback loop you can get — TypeScript, browser access for front-end work, automated tests. But even with these loops in place, LLMs don't use them well by default. They tend to write huge swaths of code before remembering to type-check or run a test.
The Pragmatic Programmer calls this outrunning your headlights — driving faster than you can see. The book's principle is that the rate of feedback is your speed limit. To force the LLM to slow down and take small deliberate steps, Matt argues for TDD: write the test first, make it pass, refactor with the design in mind, then move on.
Failure Mode 4: The Codebase Isn't Testable → Deep Modules Let AI Navigate
But TDD only works if the codebase is testable in the first place — and good codebases are testable codebases. Here Matt returns to John Ousterhout's A Philosophy of Software Design and its concept of deep modules: a healthy codebase should consist of a relatively small number of large, deep modules with simple interfaces, not a sprawl of shallow modules each exposing complex interfaces.
A codebase of shallow modules is genuinely hard for AI to explore. The AI tries to walk the code, but the structure is too fragmented — it can't find the right module in time, can't trace the dependencies, ends up misunderstanding what's there. A codebase of deep modules gives the AI clear boundaries to work against. You test at the interface, you let the implementation live behind it. Matt has a skill for this too — "improve codebase architecture" — that walks the codebase and wraps related code into deep modules.
Failure Mode 5: Your Brain Can't Keep Up → Design the Interface, Delegate the Implementation
The fifth failure mode is that the feedback loops are working, you're shipping more code than ever, but your brain is fried. Matt asks the room how many people have felt more tired in their development career than they ever have before — including himself.
The deep-module structure turns out to be the cure here as well. You can treat those deep modules as gray boxes: design the interface carefully, but don't review the implementation too closely (with obvious exceptions for high-stakes modules like finance). Hand the implementation to the AI, test from outside, verify against the interface. Matt invokes Kent Beck: invest in the design of the system every day. Specs-to-code, he notes, points the other direction — it's divestment from the design of the system.
The Core Analogy
The most vivid framing of the talk arrives at the end: think of AI as a tactical programmer on the ground — a sergeant making the code changes, hands dirty, fast. What that sergeant needs is someone above, working at the strategic level. That someone is you. And operating at that level demands the same software fundamentals engineers have been using for the past twenty years.
Where This Talk Came From
It's worth noting that the five failure modes aren't a piece of academic taxonomy — they were distilled from a cohort-based course Matt is currently running on AI Hero called "Claude Code for Real Engineers." It's a two-week online course priced at $795 USD, packaged with eight workshop modules, live office hours that span time zones, a Discord community, lifetime access, and a completion certificate. The intended audience is experienced developers who want to integrate Claude Code into a production environment, and the curriculum spans LLM context windows, the Plan/Execute/Clear workflow, AGENTS.md, custom skills, PRD authoring, multi-phase planning, and autonomous agent loops.
Matt's external pitch for the course is faintly provocative: "twenty years of software experience is not for boomers" — meaning these fundamentals are not legacy baggage, they are the precondition for AI engineering actually delivering. The lessons he picked up while building this course are the source material for the talk's five failure modes. In other words, this isn't a retrospective. It's the compressed version of a methodology being actively taught.
Conclusion
The takeaway is unusually clean for a tech talk: code is not cheap, code is important. AI is not a tool for escaping software fundamentals — it is an amplifier that makes those fundamentals more decisive than ever. In a good codebase, AI unlocks remarkable value. In a bad codebase, it accelerates the entropy. For engineers worried that their craft is losing its currency in the AI age, the talk offers a clear inversion: the fundamentals have never been worth more than they are now.
Matt's own YouTube tagline — "We don't do vibe coding, this is a channel for real engineers" — reads, after sitting with this talk, as basically its sequel in slogan form.
Video link: