A human engineer making a risky change has a built-in brake: hesitation. They pause, re-read the diff, maybe ask a teammate to sanity-check it before merging. An agent making the same change doesn't have that instinct — it makes the edit, and unless something concrete stops it, it moves on to the next one. That's not a flaw to be fixed with a better prompt. It's a structural difference that changes what actually keeps a codebase safe.
The pause was never a real safety mechanism
It's tempting to think of a human's hesitation as some kind of quality gate, but it never scaled particularly well even for humans — plenty of confident, wrong changes get merged by people who felt certain about them. What made changes actually safe wasn't the pause itself, it was whatever evidence the pause prompted someone to gather: running the tests, checking the diff against the ticket, tracing through an edge case by hand. An agent can gather that same evidence — faster, in fact — but only if it's told to, and only if the evidence-gathering mechanism (the test suite) is actually there to run.
A codebase without tests is a worse fit for agents, not a free pass
There's a version of this that gets it backwards: "the AI is smart enough to figure it out, we don't need heavy test coverage." That inverts the actual dependency. A human working in an undertested codebase compensates with domain knowledge built up over months — they know which corner of the system is fragile, even without a test telling them. An agent, especially one new to a given task, has no equivalent instinct. Without tests to run, its only feedback signal is "did the code compile," which catches a small fraction of the ways a change can be wrong.
What this changes in practice
The practical shift isn't "write more tests because AI is scary." It's that tests stop being a nice-to-have quality practice and become the actual mechanism doing the job human hesitation used to do informally: catching regressions before they ship, on every single change, not just the ones that felt risky enough to double-check. A fast-moving agent making dozens of small edits an hour needs that mechanism running constantly and automatically — a human reviewing after the fact, at agent speed, isn't a substitute for it.
The takeaway
Agents don't need less rigor because they're fast. They need the rigor to be automated, because the thing that used to provide it — a person pausing to think twice — isn't part of how they work. A repo with a thin test suite was already a liability; it's a much bigger one once the rate of change goes up and the thing making the changes doesn't get uneasy.
