Software Fundamentals Matter More Than Ever

An eighteen-minute conference talk by Matt Pocock, a developer educator who has spent the last year and a half teaching developers to work with coding agents. The thesis is in the title and is aimed at people who fear their skills stopped mattering: every failure mode he saw in students' AI-assisted projects has a fix in a software design book written before LLMs, and most of the fixes are packaged as short agent skills. The talk is a sequence of failure, book, fix, repeated five times.

Against specs-to-code

He opens on the idea that you can write a specification, have an AI compile it into code, and when something is wrong edit the spec and recompile without reading the code. He tried it. Each run produced worse code than the last, until it was garbage, and he calls the approach "vibe coding by another name" (01:37).

His diagnosis comes from two books. John Ousterhout's A Philosophy of Software Design defines complexity as whatever makes a system hard to understand and change, so a bad codebase is one you cannot change without causing bugs. The Pragmatic Programmer calls the process software entropy: every change made without thinking about the whole design makes the system a little worse (02:39). Recompiling from a spec is that process on a loop.

The slogan behind specs-to-code is that code is cheap, and this is the claim the talk exists to reject. "Bad code is the most expensive it's ever been," because an agent does very well in a codebase that is easy to change and cannot help you in one that isn't (03:43).

The failure modes

The AI builds something other than what you wanted. The Pragmatic Programmer says nobody knows exactly what they want, and Fred Brooks' The Design of Design names what is missing: a design concept, the shared, invisible idea of the thing being built that no markdown file contains (04:51). His fix is the Grill Me skill, a couple of sentences telling the agent to interview you relentlessly and walk each branch of the design tree, resolving dependencies between decisions one at a time. It routinely asks forty to a hundred questions, and the resulting conversation becomes a PRD or, for small changes, issues for an unattended agent to pick up (05:57). He prefers it to Claude Code's plan mode, which he finds too eager to produce a plan document before any shared understanding exists (07:04).

The AI is too verbose, as if the two of you were talking at cross purposes. The analogy is working with a domain expert in a field you don't know, and the fix is domain-driven design's ubiquitous language: one set of terms used in conversation, in code and with the experts (08:07). His skill scans the codebase and writes that glossary as markdown tables. He keeps it open while planning and says the agent's thinking traces got shorter and its implementation closer to the plan (09:14).

The AI builds the right thing and it doesn't work. Feedback loops are the obvious answer — static types, browser access for front-end work, automated tests — but an agent uses them badly, writing a large batch of code before thinking to type-check it. The Pragmatic Programmer calls that outrunning your headlights: "the rate of feedback is your speed limit." Test-driven development forces small steps, so TDD is the third skill (10:19).

Testing is hard, though, because the decisions about unit size, mocking and which behaviours to cover all depend on each other, and they only get easy in a codebase that is easy to test (11:32). That leads back to Ousterhout's deep modules: a lot of functionality behind a small interface. AI tends to generate the opposite, many shallow modules with wide interfaces, which the agent itself then fails to navigate (12:35). An "improve codebase architecture" skill looks for related code and wraps it in deep modules, and the boundary that results is where the tests go (13:53).

The last failure is human. You ship more code than ever and your brain can't keep up. Deep modules help here too, because a module with a well-designed, tested interface can be treated as a gray box. His rule is to design the interface and delegate the implementation, reviewing the inside less, with the explicit exception of critical areas such as finance (15:04).

The strategic layer

For that to work, the module map has to be part of the ubiquitous language and of every plan; his PRDs name which modules change and how their interfaces move. The principle he borrows is Kent Beck's: invest in the design of the system every day. Specs-to-code is the opposite, divesting from design (16:32). The closing image puts the AI as a tactical programmer, a sergeant making changes on the ground, with the engineer above it at the strategic level — which is the job the fundamentals were always for (17:35). The skills are published in his GitHub skills repository.

Relation to other pages

The Grill Me skill has already travelled. llm-critics-are-right-use-anyway describes Jeremy Theocharis using an adapted /grill-me for everything, down to writing the article sentence by sentence, and ai-assisted-workflow says Barbero's planning-first workflow was adapted from Pocock's framework. This talk is where he lays out the reasoning behind those skills.

"Code is cheap" has a page of its own on the other side. disposable-code argues that cheap code changes which projects are worth starting; Pocock's reply is that writing it got cheap while owning bad code got dearer, and both can be true at once. His rejection of never reading the code lands where cult-of-vibe-coding does, from a teacher's rather than a maintainer's angle. The spec camp he argues against is mapped in how-do-we-stop-vibe-coding and specsmaxxing, and the latter's acceptance-criteria IDs are an attempt to keep the spec and the code tied together rather than regenerate one from the other.

The gray-box advice deserves the most scrutiny. reviewing-ai-code argues that careful review of agent output does not scale, and Pocock agrees in practice by reviewing less; what he adds is the condition that makes that defensible, a narrow tested interface. The tiredness he describes is the same shift programming-differently-difficult grounds in memory research: the load moves from producing code to judging it.

The captions garble several names — Claude Code comes out as "Clojure Code", Ousterhout is spelled two ways, and the repository name is unreadable — and the talk's own numbering of failure modes and tips skips in the transcript. The quotes on this page come from YouTube's automatic captions in software-fundamentals-matter-more-than-ever and have not been checked against the audio. A corrected transcript is linked from the talk's page on ai.engineer.