It Ain't Broke: Software Fundamentals in the AI Era

There's a pattern that keeps showing up in conversations about AI coding tools.

Someone gives the AI a vague spec. The AI generates something. It doesn't quite fit. They adjust the prompt. The AI regenerates. Now it's worse. They adjust again. Now nothing works and the code looks like it was written by three different people who never met.

Matt Pocock — TypeScript educator and one of the more clear-eyed voices on AI-assisted development — gave a talk at AI Engineer Europe 2026 called "It Ain't Broke: Why Software Fundamentals Matter More Than Ever." His thesis: AI coding tools are both overhyped and genuinely powerful. The difference between those two experiences isn't the tool — it's the process.

The "Specs to Code" Loop Is a Trap

Pocock identifies what he calls the dangerous "specs to code" loop: when there's no clear shared understanding of the problem, the AI just keeps regenerating. Each iteration diverges further from what you actually want, because neither you nor the AI have established a common language for what "right" looks like.

He breaks this down into five specific failure modes:

1. AI doesn't do what you mean — No shared design vocabulary. The AI interprets vague guidance vaguely and gives you vaguely wrong output.

2. AI is too verbose — AI-generated code tends toward comprehensiveness over clarity, creating a communication gap between developer intent and what actually got written.

3. Code doesn't work — Direct consequence of the above. Without a feedback loop (static types, automated tests), nobody catches the drift until it's a pile.

4. AI does too much — Asked to solve a problem, the AI invents complexity. The simple solution doesn't get generated because the prompt didn't constrain the search space.

5. AI doesn't understand your codebase — Shallow modules, tangled interfaces, no clear separation of concerns. The AI can't navigate your architecture, so it invents its own on top of it.

None of these are problems with the model. They're process problems, and they have process solutions.

Three Techniques That Actually Work

1. Build a Shared Language First

Pocock draws from Eric Evans' Domain-Driven Design: when there's a ubiquitous language — a shared vocabulary between developers and expressed in the code — the model used in conversation and the model in the codebase are the same thing. AI can navigate that.

In practice, this means using commands like /grill-me to have AI ask clarifying questions before writing anything. Or /write-a-prd and /write-issues to force AI into planning mode before implementation mode. The point is the same: shared understanding before delegation, not after.

This isn't bureaucracy. It's the difference between briefing a junior developer for five minutes versus handing them a ticket and hoping for the best.

2. Deep Modules — Simple Interfaces, Complex Internals

Pocock borrows John Ousterhout's concept of "deep modules": the best module is one that offers a lot of functionality through a simple interface, hiding the complexity inside.

This matters for AI for a concrete reason: AI interacts with your codebase through its interfaces. If your interfaces are tangled — if understanding what a function does requires reading its entire call stack — the AI can't reason about it effectively. It will either get it wrong or produce something unnecessarily complex.

Deep modules also force code to be testable. And code that's easy to test, Pocock argues, is fundamentally good code. Not because tests are intrinsically valuable, but because testability is a proxy for clarity of interface, separation of concerns, and predictable behavior — all the things that make a codebase navigable by humans and AI alike.

3. Test-Driven Development

TDD forces you and the AI to move in small, deliberate steps. You define the expected behavior first. The AI implements against it. You know immediately whether it worked.

Pocock's framing: "The rate of feedback is your speed limit."

Without tests, the feedback loop is deploy-and-see, or worse, user-reported. With tests, the feedback loop is seconds. That speed limit isn't just about catching bugs — it's about keeping AI-assisted development from drifting into incoherence over multiple iterations.

Bad Code Is Now More Expensive Than Ever

This is Pocock's sharpest claim, and it's worth sitting with.

The common assumption is that AI makes bad code cheap — you can generate slop faster, iterate faster, throw things away faster. But Pocock inverts this: bad code is now the most expensive it has ever been, because it's the thing that prevents you from capturing AI's benefits.

A messy codebase doesn't just slow down human developers. It actively degrades AI output. The AI can't reason about what it can't navigate. It can't build on patterns it can't see. It compensates by generating more complexity, which makes the codebase worse, which makes the next AI interaction worse.

Companies that invest in clean architecture and senior engineers who enforce it will extract compounding value from AI. Companies that treat code as a disposable byproduct will find that their AI investment delivers diminishing returns — and they'll blame the model.

The Practical Takeaway

The developers who are winning with AI aren't the ones who found a better prompt. They're the ones who realized that all the things that made software development hard before AI — clear problem framing, good architecture, fast feedback loops — matter more now, not less.

The AI handles tactical implementation. The engineer handles strategic architecture. That division only works if the architecture is worth handing off to.

Summary and Key Takeaways

✅ The "specs to code" loop is a trap — vague prompts produce iteratively worse output
✅ A shared language (ubiquitous language, PRD, clear issues) is the foundation of effective AI delegation
✅ Deep modules with simple interfaces help AI navigate and reason about your codebase
✅ TDD creates fast feedback loops — the rate of feedback is your speed limit
✅ Bad code is more expensive than ever — it prevents you from capturing AI's compounding value
✅ Companies investing in codebase quality and senior engineers will pull ahead; those treating code as disposable won't

Final Thought

If your AI agent keeps producing garbage after multiple iterations, Pocock's advice is counterintuitive: don't look at the prompt first. Look at the codebase.

The AI isn't getting worse. It's struggling to work with what it's been given.

The fix isn't a better prompt. It's a better foundation.