"Software Fundamentals Matter More Than Ever" — Matt Pocock

The specs-to-code approach promises that developers can describe an application, generate its implementation, and resolve future problems by revising the specification instead of examining the code. Matt Pocock found that repeated generation produced progressively worse implementations. His objection is not to using AI for development, but to treating the underlying codebase as something that can safely manage itself. 0:19

Drawing on John Ousterhout’s A Philosophy of Software Design and The Pragmatic Programmer, Pocock frames the problem in terms of complexity and software entropy. A poor codebase is difficult to understand or change without introducing bugs, while a good one remains adaptable. When each change is made without considering the overall system, the design degrades incrementally—even if individual requests appear to have been fulfilled. 2:31

That degradation becomes particularly costly with AI because the quality of the existing codebase determines how effectively AI can contribute to it. Pocock’s central claim is that quickly producing code does not make code cheap: difficult-to-change software prevents teams from realizing the benefits of AI-assisted development. The practical implication is that software fundamentals become more valuable as implementation becomes easier to generate. 3:35

When an AI system builds something different from what its user intended, Pocock interprets the failure as a familiar requirements-gathering problem. The developer and the model do not yet share the same understanding of the intended outcome. Borrowing from Frederick P. Brooks’s The Design of Design, he describes a design concept as the evolving, intangible understanding held between collaborators, rather than a document that can simply be written once and treated as complete. 4:41

His proposed response is a skill called Grill Me, which has the AI repeatedly interview the developer about the plan, explore branches of the design, and resolve dependencies among decisions. Pocock reports that this process can involve dozens of questions and sometimes as many as 100. The resulting discussion can then be converted into a product requirements document or, for smaller changes, directly into issues for an agent to implement. 5:44

Pocock contrasts this approach with the default plan mode in Claude Code, which he personally considers too eager to create a planning artifact and begin implementation. The distinction is not that plans or requirements documents are unnecessary; it is that a durable plan becomes more useful after the human and AI have developed a shared understanding of what the work is supposed to accomplish. 5:44

Excessively verbose or misaligned AI responses can reflect a language gap rather than a purely stylistic problem. Pocock compares the situation to a developer working with a domain expert: if the two parties use different terminology, the developer may translate requirements into code that neither side fully understands. He turns to domain-driven design, or DDD, and its concept of a ubiquitous language to bring conversations, code, and domain concepts into alignment. 6:49

Pocock’s ubiquitous language skill scans a codebase for terminology and produces a Markdown document containing tables of shared terms. Both the developer and the AI can consult that vocabulary during planning and implementation. Based on his reading of the model’s thinking traces, he reports that shared terminology improves planning, makes the model’s reasoning less verbose, and helps implementations stay closer to the intended design; he also notes that he is still exploring DDD rather than presenting himself as having exhausted the subject. 7:55

Even when the AI understands the intended feature, the implementation may still fail. Pocock recommends feedback loops that include static types, browser access for front-end development, and automated tests. His concern is that AI systems often generate large amounts of code before checking whether the result type-checks, passes tests, or behaves correctly in the browser. In that situation, implementation moves faster than the available feedback can reliably guide it. 8:57

His proposed discipline is test-driven development, or TDD: write a test, make it pass, and then refactor while considering the design. This sequence constrains the model to smaller steps, but Pocock emphasizes that testing remains difficult because decisions about unit size, mocking, and which behaviors to verify are interconnected. Broad tests can become flaky, while narrower tests introduce their own dependency and mocking decisions. 10:04

The effectiveness of those feedback loops depends on the architecture underneath them. Pocock argues that deep modules provide substantial functionality behind simple interfaces, whereas shallow modules offer comparatively little functionality through more complicated or fragmented boundaries. A codebase filled with small, interconnected modules can be difficult for an AI system to navigate and understand; clear, deeper boundaries make it easier to locate relevant behavior and test it through a stable interface. 12:09

Pocock proposes improving an existing architecture by identifying related pieces of code and gathering them behind deep module boundaries. The resulting modules can be tested through their interfaces, creating an architecture that supports TDD instead of fighting it. He also draws a division of responsibility: humans should exercise substantial control over interface design, while AI can take on more of the implementation inside those boundaries. 13:05

This arrangement also addresses the cognitive fatigue that can accompany faster AI-assisted shipping. Pocock describes treating some deep modules as gray boxes: understand their purpose, design and verify the external interface, and avoid scrutinizing every implementation detail. That delegation has limits. He explicitly warns that more critical areas, such as financial functionality, may require greater attention than less critical application modules. 15:17

The strategy only works if the developer maintains an accurate mental map of the system. Pocock argues that modules and interfaces should become part of the team’s ubiquitous language and appear explicitly in product requirements documents, including descriptions of how those boundaries will change. Drawing on Kent Beck, he presents ongoing investment in system design as the essential counterweight to a specs-to-code process that ignores architecture: AI can act as a capable tactical programmer, but the human must retain strategic ownership of the system. 16:27