Reviving Impractical Quality Tools

Sources#

• Uncle Bob on Software Fundamentals in the Age of AI
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering

Summary#

Robert C. Martin (Uncle Bob on Software Fundamentals in the Age of AI, 2026-08-19, practitioner-opinion) supplies the most concrete account in the corpus of what specifically agents change about code quality, and it is not the part most discussions reach for. It is not that agents write better or worse code. It is that two quality techniques he judged correct but unaffordable twenty-five years ago became affordable, without the techniques changing at all.

The two he names:

Technique	What it does	Why he shelved it (~2000)
CRAP score	Combines test coverage with per-function cyclomatic complexity into a single "how crappy is this function" number	Detection was cheap and the report was accurate. "It took me forever to go through every one of those functions and try and fix them and rewrite the tests."
Mutation testing	Flips operators throughout the source (<→>, ==→!=, sign flips); every flip should break the suite, and a flip that does not is a "surviving mutant" that must be killed	On a project whose suite ran four minutes, several hundred mutations meant an overnight run. "I could not put that as part of a normal build scenario."

Both are diagnostic tools whose cost lived almost entirely after the diagnosis. That is the structural feature that made them impractical, and it is exactly the feature agents dissolve.

The mechanism, in his words#

"These guys are fast and they don't care how boring the work is and they will do what I tell them to do. So why don't you run CRAP over everything you've just done — and it would run CRAP and then it would clean up the code… And why don't you run mutation testing too? Maybe it took it 30 minutes instead of an overnight run and then it would plug all the holes and make sure there were tests covering everything."

Three properties are doing the work, and none of them is intelligence:

1. Speed — the overnight mutation run compresses to about thirty minutes.
2. Indifference to tedium — the remediation queue that defeated him is not aversive to an agent.
3. Compliance under a gate — the technique becomes a loop condition: "you must change the code until this tool says that it's okay."

The third is what converts a report into an enforcement mechanism. See Latent vs. Deterministic Space for why he puts quality in a checker rather than in the prompt, and Loop Engineering for the loop shape itself.

The general form#

The interesting claim is not about these two tools. It is a re-audit criterion: a technique shelved because its remediation cost exceeded a human's patience is a candidate for revival, and the shelving decision carries no information about whether the technique was right. Martin's own framing of the whole interview runs on this: "These ideas have been good for a long time. We've just never had the labor available to actually push through them."

Techniques in the corpus that fit the shape and have not been re-audited under agent labor: exhaustive property-based test generation, full-codebase invariant checking, systematic fault injection, and — his own current example — architectural dependency-rule enforcement across every module boundary rather than the handful a human would police (see Deep Modules for Agents).

Where it is not free#

He is explicit that the gates are bought with throughput, and that a ceiling exists even if he has not found it:

"Obviously there has to be a case where there's too much, right? Eventually you will slow the agents down to the point where they're slower than humans. And at that point you've lost the game."

His self-reported margin under the full gauntlet is "a factor of two or three or four" over a human, with a task a bare agent finishes in five minutes taking about an hour through the gates. That is a real price paid for the revival, and the only stated stopping rule is the human-parity floor — which is a floor, not an optimum.

What this does and does not establish#

It is one practitioner's account with no measurement, and it grades favourably a set of tools he wrote himself. What it does supply is a falsifiable structural claim with a cheap test: if agent labor is what revived these techniques, then mutation-testing and complexity-gate adoption should rise with agent adoption in a way it did not with CI adoption, and the gate-passing loop should show up as a distinct cost line rather than as better code. Nothing in the corpus measures either yet.

It also sits at an angle to the measured picture of agent testing. Agent-Generated Test Quality finds that agents' tests are broad but poorly targeted — half of code-changing PRs carry no test change, and error-handling constructs go unexercised up to 86% of the time. Mutation testing is the exact instrument that would catch that class of gap, because a surviving mutant is an untested branch. Martin's hardener stage is, in effect, the remedy for the deficiency those studies measure — proposed independently, and never measured against them.

The revival outside one practitioner's toolbox (September 2026)#

Martin's account is one veteran re-auditing tools he already owned. Stolze & Strässle (ESEM 2026 SEIP, case-study) interviewed five unrelated practitioners — a CTO, an engineering manager, a team lead and two senior engineers, across enterprise software, a utility, an agency and industrial technology — and four of the five independently describe the same motion under the same pressure: executable enforcement expanding in scope because AI-generated volume made it the only layer that scales. Two report extending existing checks to catch architectural violations, code duplication, dependency misuse and deviations from organizational implementation constraints; two describe the build system becoming the arbiter, so violations break the build instead of reaching a reviewer.

The stance on the economics is the same one as Martin's, stated by someone who does not know him. On declining to relax an automated convention in his own monorepo even though it would have been easy: "as long as I can do it automatically it costs me nothing. .. I really want this convention to be strictly upheld" [P5]. That is this page's mechanism restated as a decision rule — once the labor is the agent's, the gate's cost is no longer a reason to remove it — and it is the first non-Martin voice in the corpus saying it.

What the source does not supply is this page's specific tools. Nobody mentions mutation testing, CRAP score, or any complexity gate by name; the checks described are architectural-conformance and policy checks, which is an adjacent revival rather than the same one. And it prices nothing: no gate count, no runtime, no remediation volume. Its own limit on the general form is P4's, and it is qualitative — contextual interpretation, architectural tradeoff reasoning and long-term maintainability assessment "frequently could not be checked automatically", so executable guardrails "carried part of the supervision load but did not replace human oversight." Full treatment at Layered Supervision.

Connections#

• Layered Supervision — the revival observed outside this page's single practitioner: four unrelated practitioners expanding executable enforcement under AI-volume pressure, with the same never-relax-a-free-gate stance arrived at independently, plus the promotion rule that decides what enters the stack. Adjacent rather than identical — the checks are architectural-conformance and policy rules, not the mutation and complexity tools named here

• Impose Values, Not Disciplines — the companion principle: the gates enforce the value the discarded ritual used to deliver

• Spec-Driven Development as the New Waterfall — the gates are what make cheap, unplanned change safe rather than merely cheap

• Deterministic Engineering for Agent Code Review — the measured cousin: determinism injected into a review pipeline, and the gate-vs-instruction arm this practitioner account informally supplies

• Review as the Control Point — the control point relocated from a reviewer with skill to a criterion that executes

• Parallel Agent Orchestration — the cleaner and hardener stages are where these tools run in his pipeline

• Context Window Smart Zone — the decay argument for putting durable rules in a checker instead of the prompt

• Robert C. Martin (Uncle Bob) — whose practice this is, and whose bias is worth reading alongside it

• The Code-Quality Payoff Is Token-Indexed — the labor-side twin: DHH prices quality in tokens, Martin prices it in the agent's own ability to keep working

• Agent-Generated Test Quality — the measured coverage-targeting gap that mutation testing is built to close

• Latent vs. Deterministic Space — why the revived tools belong in a checker, not in a context file

• Verification as the New Bottleneck — this is one concrete answer to it: automate the verification rather than reading the diff

• Agentic Technical Debt — the failure mode the revived tools are aimed at

• Deep Modules for Agents — the architecture-level version he has only partly automated

• Loop Engineering — "change the code until the tool says it's okay" is the loop condition

Open Questions#

• Does mutation-testing or complexity-gate adoption actually track agent adoption, or is Martin's revival idiosyncratic to a practitioner who already owned the tools? Partially answered 2026-09-22 by When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering (case-study, five unrelated practitioners, ESEM 2026 Software Engineering in Practice) on the idiosyncrasy half only. Four of the five describe executable enforcement expanding in scope specifically because AI-generated volume outran review — extended checks for architectural violations, code duplication and dependency misuse; the build system as arbiter — and one states the economic stance independently of Martin: "as long as I can do it automatically it costs me nothing. .. I really want this convention to be strictly upheld." So the revival is not one practitioner's habit. The adoption half is untouched and arguably not addressed at all: none of the five names mutation testing, CRAP score or a complexity gate, the checks described are conformance and policy rules rather than the remediation-heavy tools this page is about, and five interviews cannot establish a trend in any case. The question still wants a population measurement — mutation-testing or complexity-gate presence in repositories, stratified by agent-authorship share.
• What is the real ceiling on gate stacking — at what number of must-pass gates does the agent's throughput advantage over a human disappear? Martin says he has not found it.

Sources#

• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering — Stolze & Strässle (OST Eastern Switzerland UAS / smartive AG, arXiv 2608.26316, 2026-08-26, ESEM 2026 SEIP), case-study: §4.3 (executable guardrails expanding, the build as arbiter, P5's monorepo stance and P4's limits) and §5.6 Pattern 1 (promotion of recurring review findings into linting rules). Five interviews, no measurement — evidence notes at Layered Supervision
• Uncle Bob on Software Fundamentals in the Age of AI — Robert C. Martin with Matt Pocock, 2026-08-19, practitioner-opinion