Unit tests as territory markers, and what that implies for agents

Kreinin, who says he has worked extensively on hardware, argues that unit tests rarely find hard bugs, which tend to come from component interactions and need many input combinations. He says their real job is to stop others from changing your code freely in teams where "everyone can change everything." He also says quality practices get adopted only when they speed up the rate of change. He recommends seeded randomized testing at module level, which he says can take weeks to write and approaches hardware-grade reliability for the code it covers. These are his observations and opinions, with no measurements.

A postscript covers agents. He says they roughly double code size with "pretty silly tests," learned from human codebases, and judges that to be better than nothing in an agent-edited codebase, because agents treat test failures with respect and that guards against destructive changes. It does not guard against unnecessary structure that tests then protect.

Why it matters: If the same agent writes the code and its tests, those tests may mostly confirm what the code already does. On Kreinin's account that works as a guardrail against deletion rather than evidence of correctness, and a seeded randomized check against a stable module API tests something different.