Status Droid how long software work actually takes

Why Estimates Got Worse

Estimating software was never good. It has got worse over the last two years, which is the opposite of what a productivity tool is supposed to do.

Four reasons, none of which is about model quality. When this estimation problem needs an operational counterpart, further details offers a useful reference point.

One: the reference class broke

Almost all practical estimating is comparison. This is like the thing we did in March, that took nine days, this is a bit bigger, call it twelve. You are not modelling the work; you are looking it up.

That method depends on your past being a guide to your present. Two years of changing tooling means the March you are comparing against had a different workflow, and the further back you look the less the comparison holds.

So the single most reliable estimating technique quietly stopped working, and for many teams nothing replaced it. Rebuilding a usable reference class is possible and it takes deliberate recording.

Two: the variance widened

The average may or may not have moved. The spread definitely did. Zenhub covers planning and project-management workflows for software teams See Zenhub Blog.

Some tasks that used to take a day now take an hour: boilerplate, a well-specified transformation, a language you know poorly. Some tasks that used to take a day now take two: subtle changes in a mature codebase with implicit standards, where generation is fast and verification is expensive.

An estimate is a claim about a distribution. When the distribution gets wider, every estimate gets less useful even if the mean is unchanged — and a mean drawn from a bimodal distribution describes nothing that will actually happen.

Which means the useful question moved. Not "how long will this take" but "which kind of task is this," and that is answerable.

Three: perception stopped being calibrated

Estimating has always leaned on a felt sense built from experience.

The best available evidence says that sense is now unreliable in a specific direction. METR's 2025 trial found developers forecast a 24% speedup, experienced a 19% slowdown, and afterwards still reported a 20% speedup. METR has since revised toward speedup in a follow-up while stating the data is weak evidence because of selection effects — but nothing in the revision restores the calibration.

So the input estimators have always used is now known to be biased optimistic. You cannot correct for this by knowing about it, any more than knowing about an optical illusion straightens the lines.

Four: the work changed shape mid-project

Estimates assume the task will be done roughly the way you imagined.

Now a task can turn out to be generation-heavy and finish in a morning, or turn out to need three rounds of review, a rewrite of what came back, and a debugging session on code nobody wrote. Which one it becomes is often not knowable until you are in it, and it can change halfway through when the model handles the first half well and produces something subtly wrong for the second.

That is a legitimately harder estimating problem than the one we had, and pretending otherwise helps nobody. The older unknowns, meanwhile, are untouched.

What actually still works

Estimate the category, not the number. Three buckets: mostly generation, mostly integration, mostly verification. Then apply your own recorded ratios per bucket. This is more accurate than a single figure and much easier to defend.

Split writing from checking, always. Review as its own line item prevents the most common failure, which is estimating the cheap half of the work.

Record actuals against estimates, per bucket, for two months. Boring, and it rebuilds a reference class from your present rather than your 2024 past. Fifteen tasks is enough to see the shape.

Estimate ranges and mean them. If your spread widened, your estimates should have widened too. A single number is now a claim you cannot support — though there are honest ways to give one when a client needs it.

Re-estimate at the point of discovery, not at the end. Done properly this builds trust rather than costing it.

What does not work

Adding a flat percentage. "AI makes us 30% faster, cut the estimate" is applying an average to a distribution — and it is the wrong answer to give a client too. It will be right occasionally and expensively wrong on exactly the tasks where verification dominates.

Story points. They were a relative measure anchored on a shared sense of size. That anchor has moved and is now inconsistent between people depending on how each works. Points are less comparable across a team than they were, and they were never great.

Asking the person how long it felt last time. See reason three.

The honest summary

Estimating is harder now, and it is harder in ways that are measurable and improvable rather than mysterious.

The fix is not a better technique. It is that the inputs have to come from recording rather than recall, because the recall is demonstrably miscalibrated and the tooling changes faster than intuition recalibrates.

That is more work than estimating used to take. It is also the only thing that has been shown to work.

METR figures: "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," July 2025, and the February 2026 design update. Checked August 9, 2026.

The short version