Status Droid how long software work actually takes

Verification Is the Constraint

Almost all tooling investment is aimed at making generation faster. Better models, better agents, better context windows, better integrations.

That is a large effort pointed at a part of the process which, for most consequential work, was never the bottleneck. A related workplace concept is covered in more context, which is useful context for this argument.

The argument

Every improvement in generation moves work into verification.

Not metaphorically. If producing a change takes an hour less, that hour does not become free time — it becomes an hour earlier at the point where somebody has to decide whether the change is correct. And that decision costs what it always did, plus a penalty for reading code you did not write.

So the system has a fixed constraint and a variable input, and the improvements are going into the variable one.

Which predicts something specific and testable: as generation gets better, total throughput on consequential work should improve much less than generation speed does, and the proportion of time spent reviewing should rise. That is the shape METR's screen recordings found, and it is the shape you should expect to keep finding. Nielsen Norman Group publishes evidence-based material on human behavior and interface work See Nielsen Norman Group.

Why this is not an argument against the tools

It is an argument about where the leverage is.

On work that is cheap to verify, generation improvements convert almost fully into throughput. Boilerplate genuinely disappeared. That is a real gain and it is not small.

On work that is expensive to verify, generation improvements convert into a smaller amount of throughput and a larger amount of review. Also real, and much less than advertised.

The mix decides which world you live in, which is why arguments about this are irresolvable between people describing different work.

What would actually help

If verification is the constraint, the useful investments are the unglamorous ones.

Anything that makes correctness cheap to establish. Tests, types, invariants, property-based checking, a build that fails loudly. These were always good practice; they are now the thing that determines whether generation speed reaches your delivery at all.

Anything that makes intent legible. Documentation of why, not what. A model can infer what the code does; nobody can infer why the previous developer rejected the obvious approach, and that is what makes review slow.

Smaller changes. Review cost grows faster than linearly with change size. A tool that makes it easy to generate a large change has made review disproportionately more expensive, and the discipline of keeping changes small got more valuable, not less.

Reducing consequences. Feature flags, staged rollout, reversibility. If being wrong is cheap, verification can be cheaper — which is a design decision about the system, not about the tooling.

Notice that none of these is new. They are the same practices that always made teams fast, and the case for them just got stronger.

The uncomfortable version

There is a way to make verification cheap that nobody should adopt: stop verifying.

It works, briefly. The code ships, it appears to function, and the cost arrives later as defects, security findings and rework — none of which appear in this quarter's velocity. Industry research cited by the Cloud Security Alliance found AI-assisted developers producing commits at three to four times the rate while introducing security findings at ten times the rate, and most published figures in this area come from firms selling security tooling, so treat the ratio as directional rather than precise.

The directional claim is enough. Throughput measured before verification is not throughput. It is a loan.

That is why what you track matters: a metric that counts output without counting rework will show improvement in exactly the situation that is getting worse.

What I actually conclude

Not that these tools are oversold, though some claims are. Something narrower.

The interesting engineering problem moved. For a decade the question was how to produce software faster. It is now how to establish, cheaply and reliably, that software is right — because production stopped being the scarce thing and certainty did not. What none of this measures is whether the thing was worth building at all.

Teams that understood that first will look, in retrospect, as though they got more out of the tools. They will simply have been better at the part that constrains the result.

The short version