← narwal.one/Second Brain
SecondBrain
Ask the Brain
Index/Sourceupdated Sat Sep 26 2026 08:00:00 GMT+0800 (Philippine Standard Time)

Software Fundamentals Matter More Than Ever (Matt Pocock, AI Engineer)

software-fundamentalsai-codingspecs-to-codetddddddeep-modulesubiquitous-languagematt-pocockai-engineer

Software Fundamentals Matter More Than Ever (Matt Pocock, AI Engineer)

Matt Pocock at AI Engineer World's Fair 2026 (~18 min, video pre-recorded per the intro). Follow-up to his earlier "Missing Manual" talk on skills — and the codebase-side argument that pairs with it.

The thesis in one sentence

"Bad code is the most expensive it's ever been… good code bases matter more than ever, which means software fundamentals matter more than ever." — Matt Pocock

The specs-to-code movement (write a spec → let the AI generate code → don't look at the code → change the spec → recompile) says code is cheap. Pocock's counter: code is not cheap. AI in a good codebase is extraordinary; AI in a bad codebase compounds entropy — every recompile makes the code worse. He ran the experiment ("I did it, got worse code, ran it again, got even worse code, ended up with garbage") and locates the failure in the Pragmatic Programmer chapter on software entropy — every change made without regard to whole-system design degrades the whole system.

Failure-mode → old-book prescription (the five moves)

Structured as: "the AI didn't do the thing I wanted" → look up an old book → build a skill.

# Failure mode Old-book prescription Pocock's skill
1 AI didn't build what you wanted Brooks: design concept — the ephemeral idea you share with your collaborator Grill Me — interview-me relentlessly, walk down each branch of the design tree, resolve dependencies one by one. "13,000-star" viral skill; ancestor of the Herk/Shihipar interview idioms
2 AI is way too verbose / talks past you DDD: Ubiquitous Language — one markdown table of the terms you + agent + code all use the same way ubiquitous-language skill — scans the codebase for terminology, produces a markdown table, kept open during planning
3 AI built the thing but it doesn't work Pragmatic Programmer: don't outrun your headlights. Rate of feedback IS the speed limit → static types + browser access + automated tests + TDD to force small steps (No new skill named; TDD as method)
4 AI-generated code is untestable Ousterhout: deep modules — few large modules with simple interfaces, hiding complexity. Testable at the interface improve-codebase-architecture skill — reusable steps to convert shallow-module sprawl into deep modules
5 Your brain can't keep up with the AI's output rate Deep modules again, treated as gray boxes — design the interface, delegate the implementation. Not everything; not finance-critical code (No new skill; a working discipline)

Wrapped by Kent Beck's frame: invest in the design of the system every day. Specs-to-code divests from design. Pocock's alternative: AI as tactical programmer (sergeant on the ground), you as the strategic level. That requires 20+ year old software fundamentals.

warning Contradicted in part by AI Skills with Matt Pocock (The Pragmatic Engineer): Pocock later says TDD "optimises for a very small working memory… agents don't need that… it's aiming at the wrong problem." What survives is the feedback-loop principle — he now asks agents for proof / "TDD evidence" that a change would fail without it, rather than strict red-green-refactor, and still recommends his TDD skill for human confidence. Row 3 above should be read as feedback loops, not TDD specifically.

note Venue: in the Pragmatic Engineer interview Pocock places a talk titled "Software Fundamentals Still Matter" at AI Engineer London (April) with ~1.2M views; this page labels its recording as World's Fair 2026. Possibly the same talk given twice — unverified.

Two lines worth pinning

  • "Rate of feedback is your speed limit." — the operational form of TDD-as-agent-discipline. The reason the LLM does "way too much at once" (producing huge chunks of code before typechecking) is that it doesn't naturally throttle to feedback cadence; TDD forces it to.
  • "Design the interface, delegate the implementation." — the practical version of Pocock's Skill Checklist (Pocock) applied to code, not skills. The interface is where the human review invests; the module interior is where the AI can move freely because the boundary contains the blast radius.

Convergence with Shihipar's Fable talk (same conference, next day)

Pocock and Thariq Shihipar (Anthropic Claude Code) independently converge on the same core move for Fable-class models:

  • Both cite Brooks's design concept as the shared invisible artifact you need to match with the model before code gets written.
  • Both build the same skill — an "interview me until we share the map" pattern (Pocock's Grill Me; Shihipar's "ask the model to interview me").
  • Both frame the risk as the map is not the territory — Shihipar names unknowns as the decision points where the AI meets territory not in the map.

Same conference, same design-concept-first prescription, arrived at from opposite ends (Pocock from the codebase-quality side; Shihipar from the model-capability side). That convergence upgrades Pocock's argument from "one educator's opinion" to a cross-vendor pattern worth building into the vault. See Field Guide to Fable (Thariq Shihipar, Anthropic).

Books cited (worth adding to the reference shelf if a second source cites them)

  • John Ousterhout — A Philosophy of Software Design — complexity definition ("anything related to structure that makes the system hard to understand and modify"), deep modules
  • The Pragmatic Programmer (Hunt & Thomas) — software entropy, "outrunning your headlights"
  • Frederick P. Brooks — The Design of Design — the design concept + design tree
  • Kent Beck — "invest in the design of the system every day"

Cross-links

Source