> ## Content Index > Fetch the complete content index at: https://productengineers.com/llms.txt > Use this file to discover other available public pages before exploring further. # Why Hardcore Technical Focus Still Matters Big Time | Uncle Bob - URL: https://productengineers.com/episodes/season2/why-hardcore-technical-focus-still-matters-big-time-uncle-bob/ - Published: 2026-09-29T09:15:06.000Z - Updated: 2026-09-29T09:15:06.000Z - Description: Robert C. Martin, author of Clean Code and Clean Architecture, explains how engineers can use static analysis, testing and technical judgement to steer AI coding agents towards better software. - Author: Robert C. Martin - Tags: #season-2 Robert C. Martin, also known as Uncle Bob, is the author of Clean Code and Clean Architecture and one of the original authors of the Agile Manifesto. In this episode, we explore why hardcore technical focus still matters big time when AI can write the code, and where engineers should apply that expertise as more implementation moves to agents. Robert walks through the static analysis tools, dependency checks and testing practices he uses to steer agents towards better software. We discuss how clean code helps AI work with a codebase, how he stays technically involved while reading less code, and why understanding customers remains essential to making sound engineering decisions. --- Listen on [YouTube](https://youtu.be/rNdfQ6mRXAQ?ref=productengineers.com), [Spotify](https://open.spotify.com/episode/5fM55PZbT0SSIy2uqEYpoy?si=Ceky64U0RXaUs49akA4wzw&ref=productengineers.com) or [Apple Podcasts](https://podcasts.apple.com/us/podcast/why-hardcore-technical-focus-still-matters-big-time/id1836853484?i=1000792147726&ref=productengineers.com) --- ### In our conversation, we discuss: 1. Why clean code and clean architecture still matter when AI writes the code 2. How static analysis and dependency checks help steer agents towards better software 3. How Robert combines acceptance tests, QA tests and mutation testing to check AI-written code 4. How engineers can stay technically in control without reading every line of code 5. Why understanding customers leads to better technical decisions ### Where to find Robert C. Martin: - X: [@unclebobmartin](https://x.com/unclebobmartin?ref=productengineers.com) - Website: [The Clean Coder](https://cleancoder.com/?ref=productengineers.com) - Videos: [Clean Coders](https://cleancoders.com/?ref=productengineers.com) --- ### Lessons Learned - **Keep technical judgement at the centre of your work.** Robert sees engineers spending less time on low-level implementation and more time directing agents. That still requires understanding the system, questioning its behaviour and deciding whether the technical choices serve the product. - **Keep the code understandable for agents.** Tangled dependencies and poorly organised code make an agent's job harder, just as they do for a human. Robert still cares about clear names, manageable functions and coherent modules because they make the code easier to work with. - **Turn standards into executable checks.** A reminder in a prompt can be forgotten as an agent focuses on a task. Robert writes deterministic tools that measure the code and report failures, then asks the agent to keep working until it meets those standards. - **Use complexity and coverage together.** Robert uses the CRAP metric to give agents feedback on both cyclomatic complexity and test coverage. Reducing the score can require better test coverage and splitting complex functions. His thresholds describe his workflow; they are a starting point for discussion, not a universal target. - **Check for duplication.** Robert also uses tools that detect repeated code, including near-duplicates. He finds agents effective at extracting shared behaviour once the duplication is made explicit. A concrete diagnostic gives the agent a specific structural problem to solve. - **Make dependency rules explicit.** Robert records which modules may depend on others and in which direction. A checker compares the code against those rules and reports violations. That gives agents feedback they can use to break dependency cycles or introduce an interface, while the engineer retains control over the intended architecture. - **Check behaviour through several kinds of tests.** Robert asks agents to write unit tests, Gherkin acceptance tests and QA tests that exercise the human interface. He reviews or spot-checks the latter two to see whether they make sense, then has the agents run all three streams. - **Test whether the tests catch mistakes.** Mutation testing deliberately changes the code and checks whether the tests fail. When a change survives, Robert asks the agent to improve the tests. This gives him evidence about what the suite detects beyond whether it passes against the current implementation. - **Keep the design pressure of tests written first.** Robert has not found a reliable way to make agents follow the tiny steps of human TDD. He still asks them to write tests before implementation, because making the code testable pushes them to address coupling and structure. - **Build a mental model and challenge it.** Robert describes reading less production code while making occasional spot checks and questioning agents about the system. He uses those explanations to develop a model he can challenge with technical questions and tests. The reduced reading is part of his wider checking process. - **Learn how customers actually work.** Riding along with a telephone repair technician helped Robert understand the people affected by his code. Answering field-service calls kept that contact alive. Direct exposure gives engineers context they can use when deciding which technical trade-offs matter. - **Preserve the reason behind technical requirements.** Robert recalls a response-time requirement slipping from under one second to three seconds as newer engineers lost the customer context behind it. Passing on the reason for a constraint helps future engineers understand its importance when they change the system.