Status Droid how long software work actually takes

Estimating Review, Not Writing

The most common way assisted work runs over is not underestimating the work. It is estimating one half of it.

Ask someone how long a task will take and they picture producing it — writing the thing, getting it running. That picture used to be a reasonable proxy for the whole job, because writing and checking scaled together. They no longer do, and the proxy silently became wrong. When this estimation problem needs an operational counterpart, self-reporting bias offers a useful reference point.

What review actually contains

Not "reading it over." Six activities, all of which take time.

Reading and understanding. Reconstructing intent from an artefact, which is slower than reading code whose author you can ask.

Checking correctness at the boundaries. Not the happy path, which is nearly always fine.

Checking fit. Does this match how the rest of the system does things, or has it introduced a third pattern? Scrum.org maintains practical resources on planning, inspection, and adaptation See Scrum.org.

Testing. Writing them, or running them and interpreting what broke.

Fixing what came back. Frequently underestimated because it feels like it should be small.

Deciding it is done. A real cost, and the one people are worst at. Reviewing indefinitely is not diligence.

Estimate "the task" and you have estimated the first bullet of the production half. Everything above is the rest of the invoice.

Rough sizing

Starting figures, to be replaced by your own within two months. These are a shape, not measured constants. The point of tracking is to make them yours.

Cheap-to-verify work: review is roughly a quarter to a half of production time. Small in absolute terms because the total is small.

Moderate work: review roughly matches production.

Expensive-to-verify work: review is two to four times production. This is the case that destroys estimates, because production feels fast and the estimate anchors on that feeling.

The pattern worth internalising: the faster the production felt, the more suspicious you should be of your total. A task where the code appeared in ninety seconds is very often a task where establishing correctness takes an afternoon.

Four things that inflate review

Change size. Review cost grows faster than linearly. Two changes of fifty lines cost less to review than one of a hundred, which is an argument for keeping generated changes small even when generating large ones is easy.

Unfamiliar domain. If you cannot evaluate the output confidently, review expands to cover your uncertainty — or worse, it does not, and you have deferred the cost.

Implicit standards. Undocumented conventions a model cannot see. This is why mature codebases are the expensive case and why METR measured a slowdown in exactly that setting.

Consequence. Payment logic gets read line by line. A throwaway script gets skimmed. Same code volume, different review, correctly.

Two things that reduce it

Tests that already exist. Verification becomes mechanical rather than a judgement, which is the single largest reduction available and the strongest argument for test coverage in an assisted workflow.

Reversibility. Feature flags, staged rollout, a fast rollback. If being wrong is cheap to undo, the review can be proportionally lighter — which is a design decision, not a discipline problem.

Both are worth stating in an estimate. This is cheaper to verify because the area is well covered by tests is a sentence clients understand, and it explains why a similar-looking task cost more last time.

How to present it

Two lines on the estimate, not one:

Implement export endpoint          3h
Review, tests, integration         5h

Three things happen when you do this. The number becomes explicable rather than a lump. The client sees where the cost actually is, which usually ends the conversation about whether AI made it cheaper. And you catch your own error, because a review line smaller than the production line on consequential work is visibly wrong.

Some clients will ask why review costs more than writing. That is the good version of the conversation, and the answer is the argument this whole site is built on.

The check before sending

What fraction of this number is verification?

Under a third on anything with real consequences means you estimated the writing. Ten seconds, and it catches the most expensive recurring mistake in assisted work.

The short version