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.