The Second Half Never Got Cheaper: Estimating Work When AI Writes the First Draft
The first estimate my team got badly wrong in the AI-tooling era wasn't too pessimistic. It was too optimistic, and confidently so. A feature that used to be a two-week ticket got its first working version in an afternoon — the model wrote a draft that compiled, ran, and demoed cleanly — and everyone quietly re-shaped the roadmap around that speed. Then the feature took nine more days to actually ship. Not because anyone was slow. Because the part that got fast was never the expensive part.
The cheap thing now is the first draft. The model is genuinely excellent at the blank-page problem: scaffolding, plausible structure, the seventy percent of code that any competent engineer could have written but would rather not have to. What it does not touch is the second half — making the draft correct for your data, wiring it into a system it knows nothing about, handling the inputs real users bring, reviewing it well enough that a human can own it, and operating it after it ships. That work didn't get cheaper. In relative terms it got larger, because it's now a bigger fraction of what's left.
Estimation drifted because the visible part moved
Software estimates have always over-weighted the part you can picture. "Build the endpoint" is easy to imagine, so it dominates the number; "reconcile the endpoint with the three callers that assumed the old shape" is invisible until you're in it. AI tooling made this bias worse by making the picturable part nearly instantaneous. You watch a working draft appear in minutes and your gut files the whole task under "basically done." The gut is wrong in a specific, repeatable direction: it discounts everything that isn't typing code, and typing code was already the cheapest input we had.
The model compressed the half of the work you could see. It left the half that decides whether you ship completely untouched.
Name the second half so it can be estimated
The fix isn't a velocity multiplier — "we're 1.4x faster now" is exactly the kind of made-up number that got us here. The fix is to make the invisible half legible, so it gets its own line in the estimate instead of hiding inside a suspiciously small one. On my team the questions that actually move a number are: how many existing callers does this touch, and do we control all of them? What does the eval say "working" means here, and who writes it? How big is the diff a human has to read closely enough to own at 3am? What's the fallback when the new path fails, and who gets paged? None of those got faster this year. If an estimate went down and none of those got smaller, the estimate is wrong, and it's wrong in the direction that hurts most — it promises a date the second half won't honor.
This is not a plea to pad. It's the opposite. Padding is what you do when you can't see the risk, so you smear a fudge factor over the whole task and hope. Naming the second half lets you cut the padding, because now the number is attached to real work: integration touching four callers, an eval set for the ambiguous inputs, a review budget scaled to the diff, a fallback path. Some of that turns out to be small and the estimate legitimately drops. Some of it is the whole job. The point is that you priced it on purpose instead of being surprised by it nine days later.
What this changes about planning a team
Once you accept that the draft is cheap and the tail is not, a few things fall out of it. Roadmaps stop treating "AI made us faster" as a flat discount applied to everything — the discount is real for greenfield scaffolding and near zero for work that lives inside an old, load-bearing system, which is most of what a shipping team does. Review capacity, not authoring capacity, becomes the constraint you plan around, because a team can now generate far more code than it can responsibly absorb. And the highest-leverage engineers on the team are increasingly the ones who are fast at the second half — the integration, the edge cases, the judgment about what "correct" means here — not the ones who are fast at producing the first draft, which is now the one thing nobody has to be fast at.
The honest version of "AI made us more productive" is narrower and more useful than the slogan. It made the first draft almost free. It made the second half more of the job than it already was. A team that plans around the free part will keep missing dates and not know why. A team that plans around the part that didn't get cheaper gets to actually spend the speedup — on shipping the tail well, which was always where the work lived.
If you're re-estimating a roadmap after handing your team AI tooling and the numbers feel slippery, I'm happy to compare notes. Reach me at arun@arunjalota.com.