It Ain't Broke: Why Software Fundamentals Matter More Than Ever

Matt Pocock (AI Hero conference talk, AI Engineer) · video · 2026-04-23 Reader 🖥️

Agent Planning Artifacts Code Quality Feedback Loops Software Design Fundamentals Spec-Driven Development Test-Driven Development

Because AI amplifies the cost of bad code through software entropy, investing in software design fundamentals — shared understanding, ubiquitous language, deep modules, TDD, and deliberate architecture — matters more in the AI era than it ever did before.

practical · argumentative — A conference talk structured as a persuasive argument against the 'code is cheap' thesis, with five practical skills/tips drawn from classical software engineering books. Argumentative spine with expository illustrations at each tip.

Structure

Part	Role
Opening thesis: software fundamentals matter more than ever	States the core claim and establishes the speaker's credibility as a teacher building an AI coding curriculum
Critique of specs-to-code movement	Presents the opposing position (code is cheap, just re-run the compiler) and demonstrates its failure through personal experience with entropy
Classical grounding: Ousterhout on complexity, Pragmatic Programmer on entropy	Anchors the observed AI failure in established software engineering theory
Thesis restatement: bad code is the most expensive it has ever been	Inverts the 'code is cheap' claim — good codebases unlock AI's bounty, bad codebases block it
Failure mode 1: AI didn't do what I wanted → Grill Me skill (Brooks' design concept)	Addresses the requirements-gathering gap between human and AI using Frederick Brooks' design tree
Failure mode 2: AI is too verbose → Ubiquitous Language skill (DDD)	Applies domain-driven design's ubiquitous language to human-AI communication
Failure mode 3: AI built the right thing but it doesn't work → TDD and feedback loops	Introduces the Pragmatic Programmer's 'outrunning your headlights' and argues TDD forces small steps
Failure mode 4: Testing is hard because the codebase is bad → Deep modules (Ousterhout)	Argues that testable codebases require deep modules with simple interfaces, not shallow modules
Failure mode 5: Your brain can't keep up → Design the interface, delegate the implementation	Shows how deep modules also reduce cognitive load for the human, enabling gray-box delegation to AI
Closing: Kent Beck's 'invest in design every day' vs. specs-to-code divestment	Frames the developer as strategic thinker above the AI's tactical execution

Key terms

specs-to-code Spec-Driven Development
A workflow where you write a specification, use AI to generate code from it, and when problems arise you modify the spec rather than the code — treating the AI as a compiler from English to code
software entropy Software Design Fundamentals
The tendency of a codebase to degrade with each change when the developer (or AI) focuses only on the immediate change without considering whole-system design; from The Pragmatic Programmer
complexity (Ousterhout) Software Design Fundamentals
Anything related to the structure of a software system that makes it hard to understand and modify; a bad codebase is one that is hard to change
design concept (Brooks) Software Design Fundamentals
The invisible, ephemeral shared theory of what is being built that exists between collaborators; not an asset or document but a mutual understanding
ubiquitous language (DDD) Software Design Fundamentals
A shared vocabulary derived from the domain model, used consistently in code, conversations with domain experts, and conversations with AI; from domain-driven design
deep module (Ousterhout) Software Design Fundamentals
A module with lots of functionality hidden behind a simple interface, as opposed to shallow modules with complex interfaces and little functionality
outrunning your headlights Feedback Loops
Producing code faster than your feedback loops can validate it; the rate of feedback is your speed limit (from The Pragmatic Programmer)
design tree (Brooks) Agent Planning Artifacts
The branching set of design decisions and their dependencies that must be resolved to reach a coherent design
Grill Me Spec-Driven Development
A skill/prompt that instructs the AI to interview the user relentlessly about every aspect of a plan until reaching shared understanding, walking down each branch of the design tree

Propositions

explicitestablishedSoftware fundamentals matter more now than they ever have before.conf: high
supports ←AI Is Changing Software Engineering. The Fundamentals Still Matter. · p14 — Bangser's field-report thesis that engineering fundamentals matter more, not less, in the AI era independently corroborates Pocock's claim that software fundamentals matter more now than ever before.
supports ←The "funhouse mirror": How AI reflects the hidden truths of your software pipeline · p6 — Direct agreement that software fundamentals matter more now than ever; Laycock grounds it in modularity making systems understandable and changeable.
refines ←Fragments: May 5 · p8 — Fowler reopens as an explicitly unresolved question what Pocock asserts flatly: whether internal code quality still matters in agentic programming.
explicit⚡ disputed & corroboratedThe specs-to-code approach produces progressively worse code with each iteration due to software entropy.conf: high
contradictsSam Hatoum's Post · p3 — Hatoum claims the fast spec-to-implementation loop is the win; Pocock claims that same loop produces progressively worse code each iteration due to software entropy.
supports ←Fragments: May 5 · p7 — Both claim unguided AI code accumulates complexity/entropy until progress stalls.
explicitCode is not cheap; bad code is the most expensive it has ever been.conf: high
explicitestablishedAI performs really well in a good codebase but poorly in a bad one.conf: high
supports ←AI Is Changing Software Engineering. The Fundamentals Still Matter. · p15 — Bangser's implicit amplification premise — good structure raises the AI payoff, bad structure raises the cost — restates Pocock's claim that AI performs well in a good codebase and poorly in a bad one.
supports ←LIVE: Uncle Bob on Software Fundamentals in the Age of AI · p3 — Martin's direct observation of agents thrashing on messy code converges with Pocock's own conference claim that AI performs well in a good codebase and poorly in a bad one — independently corroborating evidence from the same host's separate material.
implicitThe communication barrier between human and AI is a requirements-gathering problem, not a technology problem.conf: high
explicitdevelopedAn adversarial interview process (Grill Me) produces better shared understanding than the default plan mode in AI coding tools.conf: medium
extends ←mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? · p4 — Continues the same 'Grill Me' lineage (adversarial interview beats default plan mode); v1.1 refines the grilling step (no self-grilling, no jumping to implementation).
explicitA ubiquitous language reduces AI verbosity and improves implementation alignment with plans.conf: medium
explicitLLMs do not use feedback loops effectively by default; they produce too much code before checking.conf: high
explicitdevelopedTDD forces LLMs to take small, disciplined steps that prevent entropy.conf: high
refines ←LIVE: Uncle Bob on Software Fundamentals in the Age of AI · p11 — Pocock's talk states flatly that TDD forces LLMs into disciplined small steps; Martin's 'impose values, not disciplines' distinction complicates this — he explicitly does not enforce literal line-by-line TDD on agents, achieving the same quality bar (full coverage, low complexity) through a different behavioral path (function-then-test, plus a separate mutation-testing hardener stage).
explicitCodebases full of shallow modules are hard for AI to navigate and understand.conf: high
explicitestablishedDeep modules with simple interfaces make a codebase both testable and AI-friendly.conf: high
extends ←5 Things World-Class Engineers Do That You Don't · p4 — Christopher Brown's 'packaged engineering' (absorb internal complexity, expose a simple customer interface) is the same principle as Ousterhout's deep modules (simple interface, complex implementation), applied one level up — to a product/customer-facing API rather than a code module.
supports ←AI Is Changing Software Engineering. The Fundamentals Still Matter. · p4 — The hallway-track observation that refactoring a single-file codebase into modular files improved token usage and solution quality is concrete empirical support for Pocock's claim that deep, modular structure makes a codebase AI-friendly.
supports ←LIVE: Uncle Bob on Software Fundamentals in the Age of AI · p9 — Both independently describe deep modules with simple interfaces as the key structural property that keeps a codebase tractable for AI agents, not just humans.
explicitDevelopers can safely delegate implementation of non-critical deep modules to AI while retaining control of the interface design.conf: high
implicitcorroboratedAI coding tools are good tactical programmers but bad strategic thinkers; humans must fill the strategic role.conf: high
supports ←LIVE: Uncle Bob on Software Fundamentals in the Age of AI · p16 — Both state the identical tactical/strategic distinction (citing Ousterhout) almost verbatim — this conversation is effectively Pocock re-running his own conference thesis live against Martin for a reality check, and Martin affirms it.
explicitcorroboratedThe specs-to-code movement is vibe coding by another name.conf: high
supports ←When AI Writes the Code, Specifications Need an Exit Strategy · p6 — Both treat large, agent-generated specification-first workflows as vibe coding in different clothing: the underlying code, not the spec prose, remains the real engineering artifact.

Arguments

Software fundamentals matter more in the AI era, not less. strength: high

Explicit premises:

The specs-to-code approach produces progressively worse code through software entropy.
Bad codebases are hard to change (Ousterhout's definition of complexity).
AI performs well in good codebases but poorly in bad ones.
Therefore bad code is more expensive than ever because it blocks AI's productivity multiplier.

Implicit premises:

AI-era development involves more frequent code changes than pre-AI development.
The rate of entropy accumulation scales with the rate of changes made.
Developers who lack software fundamentals cannot recognize or prevent AI-generated entropy.

Inferences:

Good codebases unlock AI's bounty; bad codebases block it.
Therefore investing in software fundamentals (the skills that produce good codebases) has higher return now than before AI.

Requirements elicitation through adversarial questioning (Grill Me) is superior to eager plan generation. strength: medium

Explicit premises:

No one knows exactly what they want (Pragmatic Programmer).
Human and AI don't share a design concept (Brooks).
An adversarial interview forces 40-100 questions before the AI is satisfied.
Plan mode is 'extremely eager to create an asset' before reaching shared understanding.

Implicit premises:

Premature commitment to a plan before shared understanding is reached causes rework.
The quality of a design is proportional to the thoroughness of requirements exploration.

Inferences:

Therefore forcing the AI to interrogate the human before acting produces better-aligned output.

Deep module architecture is the key to making codebases both testable and AI-navigable. strength: high

Explicit premises:

Good codebases are easy to test (stated directly).
Deep modules have lots of functionality behind simple interfaces (Ousterhout).
Shallow modules create a maze of tiny blobs that AI struggles to navigate.
Deep modules provide clear boundaries for testing at the interface level.

Implicit premises:

AI context windows and reasoning have practical limits on how many small modules they can hold simultaneously.
Interface simplicity correlates with test simplicity.

Inferences:

Refactoring toward deep modules simultaneously improves testability, AI comprehension, and human cognitive load.

TDD is the right feedback discipline for AI-assisted development. strength: medium

Explicit premises:

LLMs produce too much code before checking (outrunning headlights).
The rate of feedback is your speed limit (Pragmatic Programmer).
TDD forces small steps: write test, make it pass, refactor.

Implicit premises:

AI-generated code has a higher defect rate than human code at the same volume.
Small-step discipline doesn't emerge from prompting alone; it requires a structural constraint like TDD.

Inferences:

TDD's structural enforcement of small steps compensates for AI's lack of self-regulation.

Narratives

The speaker tried the specs-to-code approach: wrote a spec, generated code, avoided looking at the code, ran it again, got worse code each time, eventually ending up with garbage.
→ Personal experience that falsifies the specs-to-code thesis and motivates the entire talk
Building the 'Claude Code for Real Engineers' course curriculum and having to decide what AI coding principles to teach, discovering that classical software books had the answers.
→ Establishes the speaker's credibility and frames the talk as the product of systematic curriculum research
The Grill Me skill going viral (13,000 GitHub stars) — a few lines of prompt that make the AI ask 40-100 questions before it's satisfied with shared understanding.
→ Social proof that the design-concept approach resonates with a large developer audience
Reading the AI's thinking traces after implementing ubiquitous language and seeing it think in a less verbose, more aligned way.
→ Evidence that DDD's ubiquitous language has a measurable effect on AI reasoning quality, not just output
The deep-vs-shallow modules visual: a codebase shown as many tiny scattered blobs (shallow) vs. the same code organized into bounded groups with interfaces on top (deep).
→ Visual demonstration of the architectural difference, designed for audience photos and retention

Questions addressed

✅ Are software engineering skills still valuable in the AI coding era?
Yes — software fundamentals are more valuable than ever because AI amplifies both the benefits of good design and the costs of bad design.
✅ Does the specs-to-code approach work?
No — it produces progressive code degradation through software entropy because it ignores system design between iterations.
✅ How do you align AI with what you actually want to build?
Use adversarial requirements elicitation (Grill Me) to reach a shared design concept before generating code.
✅ How do you prevent AI from producing too much low-quality code?
Use TDD to force small steps, and structure the codebase into deep modules that provide clear testable boundaries.
✅ How do you manage cognitive overload when AI increases code velocity?
Design interfaces yourself and delegate implementation to AI within deep modules; treat non-critical modules as gray boxes tested from the outside.
✅ What is the developer's role in the AI era?
Strategic thinker and system designer — the AI is the tactical programmer (sergeant), the human is the strategist.

Gaps

incompleteThe talk claims AI performs well in good codebases and poorly in bad ones, but provides no data or examples to substantiate this — it relies entirely on the audience's intuitive agreement.
Read next: Look for empirical studies measuring AI coding tool performance as a function of codebase quality metrics (coupling, cohesion, test coverage).
incompleteThe talk does not address who is responsible for the initial codebase quality when starting a greenfield AI-assisted project. If the AI generates the initial code, the entropy problem exists from day one.
Read next: Investigate AI-assisted bootstrapping practices and whether initial architecture prompting can produce deep-module structures from the start.
incompleteThe 'Improve Codebase Architecture' skill is mentioned but described only as 'quite complicated' — the talk does not explain how to refactor a shallow-module codebase into deep modules, which is the hardest step.
Read next: Read Ousterhout's A Philosophy of Software Design chapters on deep modules; explore the mattpocock/skills GitHub repo for the actual skill implementation.
incompleteThe talk assumes TDD is applicable to all AI-generated code, but does not address domains where TDD is hard to apply (UI, data pipelines, exploratory prototyping) or where the cost of test-writing may exceed the cost of debugging.
Read next: Look for frameworks on when TDD is cost-effective vs. when other feedback mechanisms (type checking, property testing, visual review) are better suited.
unaddressedThe talk does not discuss the feedback loop between AI-generated code and team skill development — if AI handles implementation, junior developers may never develop the fundamentals the talk advocates.
Read next: Investigate how AI-assisted workflows affect developer skill acquisition and whether 'gray box delegation' creates a competency gap.
closed byState Of AI-Assisted Software Development — Beane's cross-occupation research (31+ occupations) directly answers whether AI-mediated 'gray box delegation' creates a competency gap: yes, by default, because experts self-serve with AI and stop creating the hands-on opportunities novices need — with early signs of the same pattern specifically in software engineering.
incompleteThe talk's five tips are presented as independent failure modes, but the dependencies between them are not explored. For example, does ubiquitous language require deep modules to be effective? Does Grill Me only work if the developer already has architectural knowledge?
Read next: Consider whether these practices form a prerequisite chain or can be adopted independently.

It Ain't Broke: Why Software Fundamentals Matter More Than Ever

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents