# Software Fundamentals Matter More Than Ever Matt Pocock | AI Engineer Europe 2026 | 18:26 Source: https://www.youtube.com/watch?v=v4F1gFy-hqg Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/software-fundamentals-matter-more-than-ever Published: 2026-04-23 Tags: agent-skills, agents, coding-agents, context-engineering, testing ## TL;DR - AI coding tools produce better results when engineers keep control of design, feedback, and code quality. - Shared design concepts and ubiquitous language help developers and AI agents work toward the same system. - TDD and deep modules let engineers delegate implementation while retaining control of interfaces and system design. ## Summary Matt Pocock argues that AI has made software fundamentals more important because bad code can now accumulate faster. He tried a specs-to-code workflow that repeatedly regenerated code without requiring him to inspect it, and found that each pass made the system worse. His alternative is an iterative process built around shared understanding, ubiquitous language, feedback loops, TDD, and deep modules. The developer interviews the AI until they share a design concept, documents domain terms, and makes the AI take small steps through tests and other checks. Pocock also recommends designing simple module interfaces while delegating much of the implementation inside those boundaries. This reduces the amount of code a developer must hold in their head, although he says critical areas still need closer review. The AI can handle tactical programming, but the developer remains responsible for the system's design. ## Key ideas ### Repeatedly regenerating code from a specification can make the system worse [00:59](https://www.youtube.com/watch?v=v4F1gFy-hqg&t=59s) Pocock describes the specs-to-code idea as writing a specification, using AI to generate code, and changing only the specification when something goes wrong. When he tried this, each compiler pass produced worse code until he ended up with garbage. He connects this to software entropy from The Pragmatic Programmer: changes made without considering the whole system tend to degrade the codebase. He rejects the idea that code is cheap. Bad code is expensive because a codebase that is hard to change prevents teams from getting the full benefit of AI. ### The developer and AI need a shared design concept before implementation [04:30](https://www.youtube.com/watch?v=v4F1gFy-hqg&t=270s) When the AI builds the wrong thing, Pocock says the problem is a communication barrier. Drawing on Frederick P. Brooks' The Design of Design, he describes a design concept as the invisible theory of what people are building together. The developer and the AI do not automatically share that concept. His 'Grill Me' skill tells the AI to interview the developer relentlessly, walk down each branch of the design tree, and resolve decisions one by one. The resulting discussion can become a product requirements document or a set of issues for an agent to implement. ### Ubiquitous language reduces confusion between the developer and the AI [07:29](https://www.youtube.com/watch?v=v4F1gFy-hqg&t=449s) Pocock applies domain-driven design's idea of a ubiquitous language to AI-assisted development. Developers, domain experts, code, and AI should use terms derived from the same domain model. He describes a skill that scans a codebase and creates a Markdown file containing terminology in tables. He keeps this document open while planning with the AI. In his experience, shared terms make the AI's planning less verbose and make implementation better aligned with the intended design. The language must match what the terms actually mean, then be used consistently in conversations and code. ### The rate of feedback limits how quickly an AI agent should work [09:53](https://www.youtube.com/watch?v=v4F1gFy-hqg&t=593s) Even when the AI understands the goal, it may produce code that does not work. Pocock recommends static types, browser access for front-end work, and automated tests as feedback loops. He says AI agents often produce too much code before checking any of it. The Pragmatic Programmer describes this as outrunning your headlights. Since the rate of feedback is the speed limit, the agent should take small, deliberate steps and check its work as it goes. TDD helps enforce that pattern by having the agent write a test, make it pass, and then refactor the design. ### Testable code depends on making the design easier to test [11:36](https://www.youtube.com/watch?v=v4F1gFy-hqg&t=696s) Pocock says testing is difficult because decisions about unit size, mocks, and expected behaviors depend on one another. A better codebase creates better feedback for the AI. Drawing on John Ousterhout, he recommends deep modules with substantial functionality hidden behind simple interfaces. Shallow modules expose little functionality through complicated interfaces and force the AI to move through many small pieces. Deep modules give the developer a clear boundary for testing and let the AI work within a simpler structure. ### Deep module boundaries let developers delegate implementation safely [13:50](https://www.youtube.com/watch?v=v4F1gFy-hqg&t=830s) Pocock describes a skill called 'Improve codebase architecture'. It searches for related code and groups it behind a deep module with a simpler interface. The developer should design and control the interface, while the AI can handle more of the implementation inside the module. Testing then happens through the interface. Pocock compares the module to a gray box: its purpose and outside behavior must be understood, but its internal details do not always need close review. He limits this delegation for critical areas such as finance, where the implementation needs more scrutiny. ### System design must remain part of everyday planning [16:12](https://www.youtube.com/watch?v=v4F1gFy-hqg&t=972s) As AI increases the amount of code a team can ship, Pocock says developers need to keep the application's module map in mind. That map should be part of the shared language and the planning process. His PRDs describe which modules will change and how their interfaces will be modified. He cites Kent Beck's advice to invest in system design every day. In his view, specs-to-code removes that investment because it treats the specification as the only thing that matters. AI can make tactical changes, but the developer must think at the strategic level. ## Notable quotes - "I believe that software fundamentals matter now more than they actually ever have." (00:07) - "If you can't change a code base without causing bugs, then it's a bad code base." (02:36) - "The rate of feedback is your speed limit." (10:46) - "Design the interface, delegate the implementation." (16:13) - "Code is important." (17:08) ## Tools & references mentioned - Clojure Code for Real Engineers - Philosophy of Software Design - John Ousterhout - The Pragmatic Programmer - Frederick P. Brooks - The Design of Design - domain-driven design - TDD - TypeScript - Kent Beck - macpocockskills - aihero.dev ## Who should watch - You are using AI agents to build applications and need a process that prevents the codebase from degrading. - Your agents produce large changes that are difficult to test, review, or understand. - You want to delegate implementation while keeping responsibility for architecture and interfaces. ## Editor's note From the pack [Coding agents on real codebases](https://aietalks.com/packs/coding-agents-on-real-codebases): Horthy says read the plan. Blum says fund verification before you fund adoption. Both assume you can see what the agent actually did, which is easy in Claude Code and hard when the agent is one you built and shipped to other people. Kitaru is our tool for that: it records agent runs so you can replay one and find the step where it went wrong. It is also why this site exists. Written by the AIE Talks editors (the Kitaru team), not by the speaker.