Death by a Thousand Tests
There’s a test that runs on every commit in our pipeline. It takes 4 seconds. It has caught exactly one bug in the last six months. That bug took 20 minutes to fix.
Was the test worth it?
Roughly 1,800 runs over six months. 2 hours of CI time. One bug, probably catchable in code review anyway. That test is not earning its keep.
This isn’t controversial in CI/CD. Nobody runs the full integration suite on every commit at scale — you’d spend more time in CI than in development. The standard solution is tiered validation: fast unit tests on every commit, integration tests on PR merge, full suite nightly or on-demand. The cost of the check, calibrated to the cost of what it checks.
It’s rarely applied explicitly to AI agent guardrails. This is not the same question as whether the guardrail should exist at all — that’s Chesterton’s fence, and it belongs earlier. This is a question about calibration: which checks run synchronously, and which defer.
Every pre-execution check has a cost: latency, compute, UX friction. Every uncaught failure has a cost too. The right amount of enforcement isn’t the maximum — it’s the point where those costs balance. Approximately:
f × C_check >> C_fix → skip synchronous enforcement, rely on async audit
(f = run frequency; C_check = cost per check; C_fix = cost to fix the failure asynchronously)
If a check runs frequently and is expensive, but the failure it catches is cheap to fix asynchronously — skip the synchronous gate. Defer to periodic audits. If the check is cheap and the failure is catastrophic — enforce synchronously, every time. The calculus shifts depending on what you’re protecting.
Every safety mechanism has the same calibration problem. It was designed to prevent a specific failure. But if the mechanism’s own cost — in latency, compute, and UX friction — grows past what it’s protecting against, the check has inverted. It’s now costing you more than it saves. The right time to revisit a gate isn’t “when it breaks.” It’s “when the cost of having it exceeds the cost of what it prevents.”
This matters specifically for AI agents because the iteration rate is different. A human developer might trigger a check five times per day. An agent might trigger it five hundred times. The synchronous overhead that was negligible at human scale becomes a bottleneck at agent scale. The infrastructure needs to be calibrated for the speed it’s actually running, not the speed it was originally designed for.
Scaling problems aren’t new. AI just makes scaling easier, and problems more silent.
Related reading:
- Most Rules Exist for a Reason — on why the guardrails are there in the first place
- Oops I Did It Again, I Forgot –dry-run — on the guardrails that earn their keep every time