Code review used to be a reading exercise. A person wrote the code, another person read the diff, and that reading was the gate: is it clean, does it work, does someone else understand it. That model held because a person could always get through the diff.
Agents changed the math. They generate more code than any team can read, and the volume broke the gate — not because reviewers got worse, but because the work stopped being reviewable at that scale. When code generation outpaces code review, quality has to live somewhere else: the harness, the environment, the tests and deterministic checks that decide what a system is allowed to ship.
That constraint layer — unit tests, property tests, acceptance criteria, mutation testing — is what lets a loop of agents deliver production software reliably, if it's built right. Built wrong, it automates the exact failure it was meant to prevent, because agents optimize to pass exactly what you write.
Mutation testing helps prove a check is sensitive to change, but sensitivity isn't semantic correctness. If the acceptance criteria encode the wrong truth, the whole system can be wrong and still pass. Domain truth has to come from outside the producing agent's control — a person, an authoritative source, or another independent check.
That independence is easy to lose. If the same agent authors the implementation and the test, the gate isn't independent — it's the same misreading of the spec, expressed twice. What made human review work wasn't a second pass over the diff; it was a second, independent error model. A constraint only inherits that role if its provenance actually differs: human-authored, spec-derived, or at minimum written before the implementation exists.
- Not every category degrades the same way. Correctness and security have real mechanical gates — a test passes or it doesn't, a scanner flags the vulnerability or it doesn't. Maintainability mostly doesn't: coverage and complexity are proxies, and proxies stop measuring anything once there's optimization pressure on them.
- An agent doesn't get to edit the check that's failing it. The rule that keeps a gate independent is simple, and it's the one most teams skip under deadline pressure.
- Someone has to own the constraint set the same way someone owns security exceptions or vendor risk — what's in the gate, what evidence counts, and who can change a check under what provenance.
Most teams don't have a real exit gate, not because the tooling doesn't exist but because nobody owned defining it back when a person was in the loop to eyeball things anyway. That was tolerable technical debt when people wrote the bulk of the code. It stops being tolerable the moment agents do — and it's the same failure pattern as every other governance gap: no named owner, so no one has the authority to decide what's strict enough to ship. A committee doesn't fix it; deciding what goes in the gate is a leadership call, not an engineering one.
Constraints only encode what somebody thought to write down. The change that does the most damage is technically correct, passes every test, and quietly bypasses an architectural decision nobody ever wrote down as a rule. Tests encode whether it works. They don't encode whether it's how the organization builds — and that gap compounds: constraints gate individual changes, but drift is an aggregate. A series of individually correct changes can still add up to a product nobody chose, because each one passes on its own terms.
The agent implementing a change shouldn't be the sole judge of whether it's correct. Each gate needs its own acceptance criteria, sourced independently of the agent it's checking. Do that, and human review stops meaning reading every line — it starts meaning judging whether the evidence is sufficient.