I stopped optimizing for build time

The trap

For my first six months running an agent fleet, I optimized for build time. "How can I ship this feature in 30 minutes instead of 2 hours?" "How can I get the agent to one-shot this?"

It was the wrong axis. Every speed optimization had a quality cost I didn't measure until the bug landed.

The reframe

Cost philosophy now: ignore build-time complexity as a tradeoff axis. Focus on outcome correctness.

If a feature takes 4 hours instead of 30 minutes but ships correctly, that's a 4-hour feature. If it takes 30 minutes and ships with a bug that takes a week to find, that's a 1-week-and-30-minute feature.

The bug-discovery time is invisible at build time. Easy to forget. Compounds badly.

What changed in practice

I run more verification passes now. /pp2p on production code, /pp3p on irreversible code, golden-eval gates on agent pipelines. Each pass adds 5-30 minutes to a feature.

Annualized: about 10 extra hours a month spent on verification. About 60 hours saved on bugs that would have shipped under the old regime.

The tradeoff is monotonically positive. Every month it gets better, because the verification passes themselves compound — golden-eval datasets grow, regression scores get tighter, the bar for "shipped correctly" rises.

What you can steal

If you're tempted to optimize for build time:

1. Track bug discovery time alongside build time. Add them. That's the real cost.
2. For any feature touching trust boundaries (auth, payments, data loss), default to maximum verification.
3. Build the eval BEFORE the feature. Not after.

The shift is: stop bragging about how fast you ship. Start bragging about how rarely you regress.

This is the one mental shift that has compounded most across the agent fleet. Every other optimization has been a rounding error compared to it.