# Testing-heavy, no-review workflow

A development process that drops human code review as the primary reliability mechanism and relies instead on heavy randomized testing (fuzzing, property-based testing) to catch defects. The claim, argued by Dan Luu in [[danluu-ai-coding-testing]] from a decade at the CPU-design shop Centaur, is that this produces *higher* quality than review-reliant software processes — and that it's the workflow AI coding agents actually fit.

## The Centaur model

What they did that most software shops consider bad ideas:

- **Dedicated test engineers**, a first-class career path on par with logic design — same pay scale, same promotion rate. Testing is a skill; 20 years of it beats 5% of someone's time on it.
- **No code review by default.** Review was as-needed, for tricky changes, not a gate. They trusted the tests enough that review didn't add much reliability.
- **Virtually no hand-written tests, no unit tests.** Hand-written tests ("hand tests") were the exception.
- **Constant randomized testing** — what software people call fuzzing / property-based / randomized testing, generating and running new tests continuously (~800 of ~1000 machines generating new tests, ~200 running a 3-month regression suite).
- **Regression suite grows forever:** any test that ever found a bug stays in the suite.

Result: fewer than one significant user-visible bug per year, with a team small enough that the company survived the x86 shakeout until 2021. Effort split was roughly 55% testing / 45% development — and Luu argues the *level of effort* isn't what makes the difference, the *methodology* is; fuzzing has low fixed cost and scales to any effort budget.

## Why it fits agentic coding

One person driving agents can generate more code than any ten humans can review by hand. That breaks review as a gate — the review ceiling (~400 LOC/hour, [[code-review-throughput-limits]]) becomes the bottleneck on the whole workflow. Randomized testing has no such per-human ceiling: you point compute at it. So the workflow that was efficient for a small CPU team is the one that lets an agentic "software factories" process ship at volume without quality collapsing.

The load-bearing caveat: **everything not constrained from degrading will degrade** when you ship hundreds of PRs a day. Randomized testing is the constraint. But LLMs are bad at *designing* the tests — LLM-generated fuzzers have poor coverage and miss basic input variations — so the system needs a feedback loop that finds coverage gaps and closes them (human input, or shipping fractionally with staged rollout and monitoring metrics/logs/support tickets). Luu's support-ticket-to-PR pipeline is one such loop: it generates a fix *and* adds test coverage that re-finds the bug on regression.

## Relationship to the review debate

This is one of two opposite responses to "just review the AI's code like an intern's PR":

- [[reviewing-ai-code]] (Depierre): review can't scale, and reviewing LLM code is *harder* (reviewers find fewer defects, more confident) — therefore LLM coding throughput is fundamentally capped.
- This concept (Luu): review was never the right tool for reliability; testing is, and testing scales — therefore drop review, not the agents.

Both agree the intern-review model fails. They agree review tops out around 400 LOC/hour. They disagree on whether that's a ceiling on LLM coding (Depierre) or a reason to stop leaning on review at all (Luu). Note the precondition Luu is honest about: this only works if you actually have a testing methodology good enough to trust, which most software orgs don't — the skill was never developed because testing isn't a first-class career path.

Related: the fuzzing cluster ([[coverage-guided-fuzzing]], [[structure-aware-fuzzing]], [[grammar-based-fuzzing]], [[differential-fuzzing]]), [[llm-output-variance]] (why single test runs mislead), [[agent-failure-mode-skill]].