Summaries > Technology > Uncle Bob > Why Hardcore Technical Focus Still Matters Big Time | Uncle Bob (Clean Code, Clea...

Why Hardcore Technical Focus Still Matters Big Time | Uncle Bob (Clean Code, Clean Architecture)

https://www.youtube.com/watch?v=rNdfQ6mRXAQ

TLDR AI is shifting engineers from writing every line of code toward understanding customers, shaping products, and directing AI agents. Uncle Bob argues that strong technical skills still matter, but engineers must connect technical decisions to real customer needs and outcomes. AI-generated code should be kept reliable with measurable standards, automated architecture checks, and layered tests, while human engineers focus on system design, sound judgment, and verifying that the software solves the right problem.

Key Insights

Start With the Customer’s Problem

Before estimating or implementing a feature, clarify who it serves, what problem they face, and what outcome would help them. Engineers can build this understanding through direct customer contact, such as observing customers at work or helping with support requests. These experiences reveal practical constraints that are easy to miss from inside a technical team. Clear customer context also helps AI agents produce solutions that address the real need rather than merely satisfy a prompt.

Preserve Customer Requirements as Teams Change

Important customer needs can disappear when engineers change or projects grow, so capture them as explicit, testable requirements. For example, a response-time target should remain visible in documentation and automated checks rather than live only in the memory of early team members. Review these requirements as the product evolves, and investigate when system behavior drifts from them. This keeps technical decisions connected to the people and business outcomes they are meant to support.

Pair Product Understanding With Technical Expertise

AI can take on more implementation work, but engineers still need technical judgment to evaluate the systems it produces. They should also understand the business context, communicate product needs clearly, and question whether a proposed solution is appropriate. Avoid separating technical teams from customer and product concerns; infrastructure and platform work also affects users and business outcomes. Deep specialists remain essential where the work requires advanced technical knowledge.

Set Measurable Standards for AI-Generated Code

Do not rely on prompts alone to keep AI-generated code maintainable, because agents may not consistently remember informal instructions. Use deterministic tools to check code quality and have agents revise their work until it meets defined standards. Useful checks include complexity combined with test coverage, code duplication, and rules for which modules may depend on one another. For example, dependency rules can expose cycles or unwanted relationships before they become difficult to change.

Build Tests at Multiple Levels

Ask agents to create unit tests, acceptance tests, and tests that exercise the product through its human interface. Run these checks automatically, and spot-check acceptance tests to confirm they represent genuine user needs. Mutation testing can reveal weak tests by making small code changes and checking whether the suite catches them. Together, these practices make regressions harder to introduce and encourage code that is easier to test.

Review the System’s Shape, Not Just Its Test Results

Passing tests are valuable evidence, but they do not replace an engineer’s understanding of the system. Spot-check important code and tests, ask agents to explain how components work, and challenge those explanations against your own mental model. Pay particular attention to clear names, module boundaries, function size, and manageable interfaces; for example, an eight-argument function is a strong candidate for redesign. Use engineering judgment to decide when an agent’s output needs further review.

Questions & Answers

How is AI changing the role of software engineers?

AI is shifting engineers’ emphasis from low-level coding toward product engineering. Engineers still need technical skills, but they must increasingly understand customers and business needs, communicate requirements to AI agents, and evaluate whether the resulting software solves the right problem.

Why should engineers spend time directly with customers?

Direct customer contact helps engineers understand how their work affects people using the product. Martin recalls riding with a telephone repairman and later helping customers on support lines; both experiences gave engineers a clearer view of customer needs that could otherwise be missed.

What can happen when engineering teams lose touch with customer needs?

Important product requirements can fade as teams grow or change. For example, a terminal command that once had to respond in under one second came to take three seconds because newer engineers no longer knew why the original response-time requirement mattered.

How should engineers connect technical decisions to product goals?

They should understand the customer problem and desired outcome before estimating or implementing a solution. Technical decisions should be judged in the context of the business and customer need, rather than treated as isolated feature work.

How can engineers maintain code quality when AI writes much of the code?

Use clear standards and deterministic tools to measure code quality, then have agents work in a loop until the code meets those standards. This is more reliable than depending only on prompt instructions that an agent may forget.

What code-quality practices and metrics does Martin recommend for AI-generated code?

He recommends measuring function-level complexity and test coverage with the CRAP metric, aiming for a score below six, and using code-duplication detection. These checks encourage agents to add tests, split complex functions, improve names, reduce repetition, and create appropriate abstractions.

How can teams use tools to enforce architectural rules?

Specify permitted dependencies between modules in a text file and use a deterministic tool to check the code against those rules. Agents can then address violations by changing dependency direction, splitting modules, or removing dependency cycles.

What kinds of tests should AI agents write, and how should those tests be checked?

Agents should write unit tests, Gherkin acceptance tests, and QA tests that exercise the product through its human interface. Engineers can spot-check the acceptance and QA tests, run them with deterministic tools, and use mutation testing to identify tests that fail to catch small code changes.

How does testing help prevent AI agents from breaking existing features?

Three interconnected layers of tests—unit, acceptance, and QA—make it harder for agents to break existing behavior unnoticed. Agents can often write tests first and then make them pass, which encourages more testable code and reduces coupling.

How closely should engineers review AI-generated code and tests?

Martin does not routinely review every test or line of production code. He uses light spot checks and asks agents questions about the system’s structure and behavior to build and challenge his own mental model. He pays particular attention to the names and overall shape of functions, modules, and classes, while relying on tests to provide confidence.

How strict should coding standards be for AI agents?

Agents can sometimes be held to looser limits than humans because they have stronger short-term memory, but standards still matter. Martin generally prefers functions to have no more than three arguments, might accept four or five, and would ask an agent to change a function with eight.

Will AI and accessible programming tools make software engineers unnecessary?

No. AI makes it easier for nontechnical people to contribute, but prompting or building simple tools does not replace engineers’ deep understanding of systems, skepticism, and ability to design challenging tests. Deep technical specialists also remain essential for fields such as AI training, finite element analysis, scientific data analysis, and game-engine physics.

Why are product and design skills useful even for infrastructure engineers?

Product and design thinking help engineers connect infrastructure and platform work to the people and outcomes it serves. Understanding customer and business needs is valuable beyond teams that build visible product features.

Summary of Timestamps

Robert C. Martin (Uncle Bob) says AI is shifting engineers’ focus from writing low-level code toward product engineering. As AI takes on more implementation, engineers still need technical skills—but they also need to understand customers, represent business needs, communicate clearly with AI agents, and evaluate whether the resulting software solves the right problem.

Customer focus has always been part of good engineering and Agile. Martin says teams need close involvement from customers or informed representatives, and engineers can ask managers for time to develop product skills because serving customers is already part of their work. He also notes that organizational changes can create tension when people’s values differ, often leading people and companies to find better-aligned environments.

Martin recalls working as a young programmer on technically demanding assembly-language software that measured telephone-line characteristics and faults. The CEO required project staff to ride along with repair workers; spending a day in a truck with a telephone repairman in Indiana helped Martin understand how his code affected the people fixing lines in the field.

The company also kept engineers connected to customers by having them answer support calls in the lab and help both customers and field-service agents. Although the culture valued engineers’ technical authority, Martin argues that technical skill should go hand in hand with understanding the customer and business needs behind the work—not be isolated in feature-focused silos.

Customer knowledge can disappear as teams grow and employees change. Martin remembers that a terminal command originally had to respond in under one second because customers were busy, highly paid professionals. About a decade later, the response time had drifted to three seconds, and newer engineers had lost sight of the original customer requirement.

Engineers should connect technical decisions and estimates to the customer’s problem and desired outcome. The conversation then turns to how practices from *Clean Code* and *Clean Architecture* apply when AI writes much of the code—a question that leads into ways to make AI-generated software more reliable.

Martin says messy, tangled code confuses AI agents just as it confuses human programmers. Instead of relying only on prompts that an agent may forget, engineers should use deterministic tools to measure quality and keep agents working in a feedback loop until the code meets clear standards.

One useful function-level measure is CRAP, which combines cyclomatic complexity with test coverage and penalizes complex code more heavily when it lacks tests. Martin asks agents to keep the score below six, encouraging them to add tests and break complex functions into smaller, clearly named, loosely coupled pieces. Duplication detection can also prompt agents to reduce repeated code.

Architecture rules can be recorded in a text file that specifies which modules are allowed to depend on one another. A deterministic tool checks the code against those rules, while agents can fix violations by changing dependencies, introducing interfaces, splitting modules, or removing dependency cycles.

Agents should create unit tests, Gherkin acceptance tests, and QA tests that exercise the product through its human interface. Engineers can spot-check the acceptance and QA tests, then use deterministic tools to run them. Mutation testing checks whether tests detect small code changes; if a mutation survives, the agent should add tests to strengthen the suite.

Martin says the combination of unit, acceptance, and QA tests makes it difficult for agents to break existing features. Agents may not follow the fine-grained human TDD cycle, but they can often write tests first and then make them pass, which supports testable code and reduces coupling.

Rather than routinely reviewing every line of code or every test, Martin uses light spot checks and asks agents questions about system structure and behavior. He pays particular attention to names and the overall shape of functions, modules, and classes, using passing tests alongside his own mental model to assess the work.

AI agents may be held to somewhat looser limits than human programmers for function size and testing discipline, but there are still boundaries. Martin generally prefers no more than three function arguments, may accept four or five, and would ask an agent to revise a function with eight.

Deep technical specialists remain essential for fields such as AI training, finite element analysis, CERN data analysis, and game-engine physics. However, most business software does not require that level of specialization, and product and design thinking can also benefit infrastructure and platform engineers.

Martin says AI makes it easier for nontechnical people, including product managers and designers, to help build software—a continuation of tools making programming more accessible. He does not see this as a threat to engineers: prompting or building simple tools does not replace deep systems knowledge, skepticism, or the ability to design demanding tests.

The interviewer describes AI tools as a communication aid that lets product managers and designers show what they mean instead of only describing it. Martin can be found on X as Uncle Bob Martin, at cleancoder.com and cleancoders.com, and has submitted a manuscript for a book titled *Agentic Discipline*.