Three numbers, with their sources
Three studies from the past two years describe the same picture from different angles. Harness reported in 2025 that 72 % of surveyed teams had already had a production incident caused by AI-generated code. Faros AI found in 2026 that 31,3 % of pull requests were merged without any review. GitClear measured in 2025 that duplicated code blocks had become four to eight times more common than before AI. And DORA’s 2025 report put the mechanism in one sentence: AI amplifies the engineering culture that is already there.
These are other people’s numbers about other people’s teams. They say nothing about our gates. What they do say is where to look.
Four shapes of the same debt
The duplicated block
An agent that cannot see a helper writes its own. Then another. Three months later there are five ways to format a date, each slightly different, each with its own bug. Nothing is red. The gate that catches it: static analysis with duplication detection turned on, blocking above a threshold rather than reporting.
The test that proves nothing
A test that calls the code, checks that no exception was thrown, and goes green. Coverage goes up. Safety does not. The gate that catches it: mutation testing on every new test. The test has to go red when the code it tests is changed, or it does not count.
The merge nobody read
A pull request that looked fine, from an agent that sounded confident, merged on a Friday. The gate that catches it: a sceptical second agent reviews before a person does, and the merge button only works when the gate is green, never on confidence.
The secret in the history
A working connection string pasted into a config file to get a test green locally. The gate that catches it: a secret scan on the pre-commit hook and again on push, blocking, naming the file and the line.
Why it is worse than ordinary debt
Ordinary technical debt announces itself: the code is ugly, the tests are slow, someone complains. Agentic debt is polite. It follows the linter, it has a test, it reads well. The person who would once have noticed (the one who wrote it) did not write it. So the only defence is structural: checks that run on every change, whatever anyone feels about it, and a rule that every mistake found becomes a check that finds it next time.
Where to start
Look at the last twenty merges on your busiest repository. Count how many were reviewed by a person, how many new tests would survive a mutation, and how many helpers exist twice. That is a morning’s work and it usually settles the discussion. If you would rather have us do it, a Hardening Audit reads your app the way an attacker and an auditor would, ranked by what hurts first, and tells you what to fix.