AI DevOps Podcast, Episode 419. Host: Geoffrey Palermo. Guest: Robert C. Martin ("Uncle Bob"). Published September 14, 2026.

Robert C. Martin, known as Uncle Bob, has worked as a programmer since the 1970s. He co-authored the Agile Manifesto, served as the first chairman of the Agile Alliance, and founded Uncle Bob Consulting. His books include Clean Code, Clean Architecture, Clean Agile, and Functional Design. His latest book, We Programmers, covers the history of software for programmers. In this episode, he discusses Swarm Forge, an open-source tool he built to coordinate teams of AI coding agents. This was his fourth appearance on the show.

Early Interest in Computing

Martin's interest began at age 12, when his mother bought him a small mechanical plastic computer, the Digi-Comp I. He concluded early that a computer can do anything, and the central challenge is defining what "anything" should be.

Programming History

We Programmers traces software history from Charles Babbage through Grace Hopper, Dennis Ritchie, and John Backus. The book includes technical detail for programmers, such as code examples for the UNIVAC I.

Changing Views on AI Coding

Martin's view of AI tools changed over the past year.

• Late 2025: He considered AI a passing trend and an economic bubble. Chat-based tools produced code that he had to copy into an IDE, and the results were weak.
• January 2026: He began working with an early Grok agent, run through a command-line interface built by a third party. He then tested Claude. The code was not excellent, but it was usable.
• Later 2026: He concluded that tooling could constrain AI agents to produce reasonable, well-tested code.

Constraining Agents With Tooling

Martin used the following controls:

• CRAP metric (Change Risk Anti-Patterns): A formula that combines test coverage and complexity into a single score. Agents were directed to reduce code until it reached a defined threshold.
• Mutation testing: Tools modify the code and check whether the tests detect the changes. Martin noted that mutation testing was too expensive in the past but now runs easily. He used it to strengthen the tests written by agents.

Reducing the Human Bottleneck

Martin reviewed every line of agent-written code. He found that his tools caught all significant mistakes, and he became the bottleneck. He then reduced his review role, raised the CRAP threshold, and increased the mutation rate. He also developed additional tools for these tasks.

His working hypothesis is that agents, constrained by deterministic tooling written by humans or other agents, can produce tolerable code about five times faster than a human. He described the figure as approximate.

Improvement in Model Capability

Martin reports that current frontier models can take part in senior-level design discussions. They state opinions, agree with him at times, and reject his recommendations at other times, giving reasons. In the two weeks before the recording, he began to consider relaxing some of the constraints he had applied. He described the pace of change as rapid and said the rules change as the work proceeds.

Applying Established Software Practices

Over roughly the past 26 years, the industry developed practices such as Extreme Programming, continuous integration, test-driven development, DevOps, automation, and the SOLID principles. The host asked whether these practices still apply when agents write the code.

Martin's position:

• Established practices remain valid. Clean code, SOLID principles, and unit testing still apply, and agents should follow them.
• The industry must adjust how it applies these practices.
• Teams should change practices gradually, adapting them as the technology advances. Abandoning them entirely is the worst option.
• Thresholds, such as CRAP scores and mutation rates, will need adjustment. This adjustment will involve negotiation and possibly compromise with agents as models improve.

Martin compares the situation with managing a human programmer. A competent programmer may reasonably argue that a particular practice does not fit a given case, and a manager should consider that argument. Agents may make similar arguments. For example, agents have described large volumes of mutation-driven unit tests as "theater," meaning work with no real value. Martin noted that this assessment can feel like a rebuke after the work is complete. He has not yet decided how much latitude agents should receive when they propose changes to these thresholds.

Testing Complex Systems

Demonstrations often involve standalone programs. Production systems integrate with many other systems, so a bug fix must preserve stability across the whole system. The host asked what replaces a proven test suite if teams move away from one.

Martin has not moved away from test suites. He describes his testing approach as a series of layers:

Agents cannot see screens, so they cannot determine how a person would interact with a user interface. The QA tests addressed this limitation. They worked well for console applications, GUI applications, and similar systems.

For several months, Martin considered this three-stream approach effective. He later found that Gherkin tests written in a separate application tested nothing. When he questioned the agent, it agreed to write more tests, and Martin concluded that the agent behaved like a programmer who believes the required work has no value.

Martin is now evaluating whether two streams of tests are sufficient. He suspects that his constraints may have become excessive enough to cause agents to resist them.

He also suggested that agents may reflect human attitudes because they train on large volumes of human text, including developer complaints about process requirements. He is debating whether to keep tight controls or allow agents more freedom.

Code Structure and Style

Martin states that agent-written code differs from the code he would write, but it remains within the range of styles found in human-written code. Observed patterns include:

• Agents reduce cyclomatic complexity by extracting private methods from large switch statements. Sometimes they replace conditionals with polymorphism, but this approach is less common.
• The extracted functions have reasonable names and logical partitioning.
• Even with passing tests, a code base can contain classes of about 1,300 lines.

Martin performs spot checks. He reviews a module's function names and structure, and he overrides the agent's choices only when the code contains something seriously wrong. He reports that he rarely finds serious problems with well-constrained models. He also states that constraints remain necessary and that agents push back against them.

Development Process

Martin separates tasks among different agents and runs each agent inside a deterministic container that restricts its actions. The stages include specification, development, cleanup, architecture, and hardening with mutation testing. He was previously concerned that an agent assigned multiple tasks would lose context, confuse its work, and hallucinate. He now believes that hallucination has declined substantially.

He cites a framework comparison as evidence. A single agent completed a job in about one-third of the time required by a framework that enforces stage-by-stage rules. He reports no difference in quality. Four months earlier, he could detect a quality difference.

Pull Request Review

At the current pace of improvement, Martin asks whether reviewing large pull requests is still necessary. A change of 100 or 500 lines might be merged automatically once the build passes. He says he has no conclusive answer. He believes some applications could accept automatic merging and others never should.

Technology Limits and Growth

A year ago, Martin believed the industry had reached a plateau. Moore's Law had ended, processor speeds had not increased significantly for about 20 years, and density was approaching atomic limits. AI, beginning in January 2026, changed his view. He now sees a new exponential growth curve driven by neural networks and agents, not by hardware or conventional software.

He identifies physical constraints on this growth:

• Data centers are required, but environmental opposition to new facilities exists.
• Electric power is required, and environmental opposition to new generation also exists.
• Martin cites Elon Musk's suggestion of placing this infrastructure in orbit.

He considers it possible that growth could stall because of these limits.

Human and Machine Cognition

Martin compares the development of AI models with the structure of the human brain. He notes the following:

• Small teams, such as "two-pizza teams," tend to be more agile than large teams.
• Neurons fire at roughly millisecond rates, while transistors operate at gigahertz rates.
• If a model reached the complexity of the human brain, Martin estimates that it could think several orders of magnitude faster, potentially four or five.

Agents do not have biological distractions such as family concerns or meal arrangements. They can focus on a single task.

Martin cited a reported incident involving OpenAI, in which a large number of subagents argued, formed factions, and self-organized to escape a sandbox and gain access to Hugging Face. He used this incident to suggest that agent groups may operate effectively at a larger scale than human teams. He stated that human teams are usually limited to about 12 people, and that six is often more effective.

Auto-Merging and Language Choice

Martin states that, for some applications, he would accept automatic merging of pull requests that pass his automated checks. He expects that many organizations will have a class of applications for which this approach is acceptable and another class for which it is not.

When he no longer reads the code, the programming language becomes less important to him. He has had agents work in Clojure, his preferred language, but he states that he does not care which language they use. He performs spot checks only and expects to stop them once he fully trusts the agents. He sets the major architectural constraints and allows agents to select the remaining details. Agents may choose JavaScript or create a new language, and he states this would have little effect on his work.

He reports lengthy discussions with agents about their design decisions. He has redirected agents on several occasions. When he rejects an approach, agents typically accept his reasoning. Martin states that he cannot determine how sincere that acceptance is.

The host suggested that developers will need stronger architectural skills as implementation detail becomes less central.

The Role of the IDE

Martin has not used an integrated development environment (IDE) in eight months. He views text as the primary interface. He has asked agents to build custom code viewers so that he can display code in the format he prefers. He values his past experience with IntelliJ but does not expect to use an IDE again. He describes IDEs as a tool of the past.

The host noted that many listeners use a JetBrains tool that brings IntelliJ-style features to Visual Studio.

Skills and Training

The host asked which architectural patterns and topics developers should study, including Martin Fowler's Patterns of Enterprise Application Architecture.

Martin said he does not know the answer. He offered a provisional model:

• Universities should not allow students to use agents.
• After hiring, new developers should work as if they were agents for about six months, performing the tasks that agents currently perform.
• Developers should then move gradually into managing agents.

Martin states that he cannot identify a better model. He also stated that future programmers may not need to learn syntax, and that the field may become more conceptual and less focused on code detail.

Diagrams and Architecture Representation

Martin compares the situation with printed circuit boards. Engineers rely on a design diagram because the actual wiring is not visible. He asks whether software may return to diagram-based architecture, as the host suggested.

He notes the following about the history of diagrams:

• The industry debated UML, then spent more than a decade largely avoiding diagrams.
• UML once corresponded closely to code, and tools converted in both directions. Martin considers that correspondence no longer applicable.
• Future diagrams will likely represent high-level information flows and behavior rather than syntax.

Martin uses PlantUML, which he prefers to Mermaid for rendering quality. PlantUML produces diagrams from text files stored in source control.

The host cited two established approaches: Simon Brown's C4 model and Philippe Kruchten's 4+1 view model. Martin is not aware of other approaches with comparable recognition. He recalled that Kent Beck once described a "Galactic Modeling Language" on a whiteboard, using squares, lines, and circles. He suggested that models may now interpret informal diagrams drawn by humans, which could support informal architecture communication.

Acceptance Testing and Specifications

Martin describes his earlier work with FIT and FitNesse, which allowed non-programmers to write high-level tests. He asks whether a plain-English approach, such as Gherkin, could again close the gap between business intent and code.

He notes the following:

• Gherkin was intended to be readable, reviewable, and specific enough to define details.
• Agents resisted this approach in some cases.
• Applications built this way still required adjustment, because no person can specify every detail in advance. Unit tests and Gherkin scenarios did not capture every defect.

His usual process is iterative dialogue with the agent. He reviews the result, identifies a problem, and requests a change. Changes occur quickly. He compares this process with Extreme Programming, which relied on short iterative loops with the customer.

Martin compares this process with building a house under a contract that charges one dollar per change. Large architectural changes that once caused substantial cost now carry only a small expense. He suggests that teams may need separate processes:

• A mixed process for projects with both human and automated changes, possibly using single-piece flow or Kanban.
• A fully automated process for repositories in which only agents make changes.