How Long Will It Take?

"When will it be done?" is the wrong question

Picture this: you ask your tech lead "when will the new onboarding flow be done?" They say "two weeks." You commit it to leadership in the next status update. Five weeks later, the team is still finishing it.

Nobody lied. You asked the question PMs ask the way you'd ask a barista when your coffee is ready. They answered the way a weather forecaster would answer "will it rain on September 14th?" — except they collapsed the forecast into a single number, because that's what the room wanted.

The mismatch isn't because engineers are evasive or PMs are unreasonable. It's that an estimate is a forecast, not a promise — and a forecast made at kickoff is made when you know the least. Treating the number as a commitment is what creates most of the friction between PM and eng around dates.

Why estimates lie (and engineers know it)

The cone of uncertainty

There's a well-known idea in software estimation called the cone of uncertainty — meaning that an honest estimate range is widest at kickoff and narrows as the work progresses. At the start of a project, the range is roughly 4× wide: if the true cost is 4 weeks, the honest estimate is "somewhere between 1 and 16 weeks." By the time you're halfway through, the range has narrowed to maybe 1.5× wide.

A team I worked with estimated 2 weeks for migrating customer accounts to a new identity provider. Eight weeks later they shipped. Three of those weeks were the migration tooling for customers with multiple linked accounts — a class of user nobody had remembered at kickoff. The estimate wasn't bad. It was given at the moment the team knew the least about what they were estimating.

Two consequences fall out of the cone:

• The worst moment to ask for a precise estimate is the moment most stakeholders demand one — kickoff. Anything tighter than a 4× range at kickoff is either a guess or a lie.
• The only work that produces reliable estimates is work very similar to work the team has already done. New work is genuinely uncertain, and the uncertainty doesn't go away because the calendar needs a date.

When an engineer hedges, they're not being unhelpful. They're refusing to convert uncertainty into false precision — which is exactly the right instinct, even when it feels inconvenient.

The math of "almost done"

The 90/90 rule

There's a folk rule in software: the first 90% of the work takes 90% of the time, and the last 10% takes the other 90%. It's a joke engineers tell each other because it keeps being true.

The reason isn't laziness or bad planning. It's that the visible part of the work — the part you can demo — is the happy path (meaning the version where the user does what's expected and nothing breaks). Once that's working, the remaining work is everything else: error states, edge cases, real (messy) data, real load, accessibility, monitoring, the customer with the weird config, the integration test that flakes, the security review, the rollout plan. Each of those costs real time. None of them show up in a demo.

A useful translation table for what engineers actually mean when they describe progress:

• "It's basically done" → roughly 70% complete.
• "We just need to clean up a few things" → roughly 50% complete.
• "It's working end-to-end" → the happy path runs in development. The shipping work is still ahead.

The remaining work is the work that doesn't look like work — and that's where estimates rot.

How to read an engineering estimate

Engineers rarely give you a number; they give you a phrase. Each phrase carries a specific shape of uncertainty. The five recurring ones, with what they actually mean and the follow-up that gets you to firm ground:

1. "A couple of days"

Usually 3–7 working days, and almost never includes code review, QA, or shipping. Add roughly 50% for the work to actually reach users. Follow-up: "days of work, or days until customers can use it?"

2. "By next week"

Means "I think next week, but I haven't checked against everything else on my plate." A real commitment requires the engineer to look at their queue. Confirm capacity before you commit publicly. Follow-up: "have you checked that against the rest of your sprint?"

3. "It depends"

The estimate isn't ready yet — the work hasn't been broken down enough to have a real number. Push for the breakdown, not for the number. Follow-up: "what would we need to figure out before you'd give me a range?"

4. A single tight number with no range

Be suspicious. Either the work is genuinely repetitive and the engineer has done it before (good — confirm by asking) or they're giving you the answer they think you want (bad). Follow-up: "have we built something like this before?"

5. An order-of-magnitude answer ("days vs weeks vs months")

Often the most useful estimate — it's the level of precision the engineer actually has, and it's almost always enough to make the next decision. Don't push for tighter precision than the underlying uncertainty supports.

How to ask for a useful estimate

The shape of the question determines the shape of the answer. Four prompts that consistently produce more honest, more decision-ready estimates:

1. "Give me a range, not a number"

A range carries the uncertainty information you actually need. A single number throws it away. You can always negotiate down to a number after you understand the range; you cannot recover the range after the team has given you a number and the room moved on.

2. "What's the 90% case?"

If you have to commit to a date externally — a launch, a customer, leadership — ask for the date the engineer is 90% confident in, not the date they're hoping for. The 50% case is the team's median; the 90% case is what survives the bad week. Leadership wants to hear the second.

3. "What could make this slip?"

The list you get back is the real estimate. If three of the five items feel likely, your true estimate is the worst case, not the best. This question reliably surfaces concerns the engineer hadn't been planning to raise — and turns the estimate from a guess into a list of risks you can manage.

4. "Have we built something like this before?"

If yes, the estimate is probably trustworthy. If no, treat it as a guess and plan for re-estimation once the team has actually started. Novel work and familiar work have completely different estimate accuracies, and the answer to this one question tells you which posture to take.

None of this gets you a tighter number. What it gets you is a number you can defend — which is the actual job.

What changes when AI is in the loop

The question: How much faster — and where?

What's changed. Engineering velocity is genuinely shifting, and the gut-feel estimates that PMs and engineers have built up over years are getting stale. Concretely:

• Boilerplate, scaffolding, and well-trodden patterns (CRUD pages, basic API endpoints, form wiring, simple data transforms) are dramatically faster — a day's worth of work in an hour.
• First-draft writing — code, tests, documentation, even commit messages — has a much lower floor. Engineers spend less time staring at a blank file.
• Translating between languages and frameworks is faster, so engineers context-switch across stacks more cheaply than they used to.
• Code review has a partial assist (linting, common-mistake catching) that takes some load off the human reviewer, but doesn't replace them.

What hasn't changed. The parts of an estimate that were already the long pole are the parts AI moves the least:

• Integration with other systems — auth, billing, third-party APIs, mobile release pipelines — is roughly as slow as it ever was.
• Debugging novel issues is often slower with AI in the loop, not faster, because plausible-but-wrong suggestions can send you down rabbit holes.
• Code review by a human who has to actually own the code is still required for any non-trivial change.
• The last 20% — production hardening, edge cases, real load, real data, the messy real customer — is barely touched. The 90/90 rule from Section 3 still applies.
• Estimating genuinely novel work is still mostly fiction. AI doesn't make the cone of uncertainty narrower; it makes the median faster, but the variance stays.

What to watch for. A few traps that show up specifically when AI is being used to estimate or accelerate work:

1. Stale heuristics

"A CRUD page is three days" was a useful rule of thumb. It's now wrong in both directions — sometimes much faster (with AI), sometimes much slower (when the AI confidently produced something subtly broken and the engineer is debugging it). Old gut estimates need recalibration. Ask explicitly: "is this estimate based on how long this used to take, or how long it takes now?"

2. Demo speed vs ship speed

"I tried this with AI and it took an hour" describes a working demo, not a production-ready feature. Ask explicitly which one is being talked about — the same words mean wildly different things.

3. The bottleneck has moved

Typing code is no longer the slow step for most work. Reading code, integrating it correctly, and reviewing it carefully are. If your team's process still treats coding as the long pole, your estimates are anchored on the wrong thing.

4. Per-engineer variance is up

Some engineers are 3–5× faster with AI on certain kinds of work. Others are roughly the same speed, or slower, because they spend the time they save on better tests or cleaner code. Don't average across the team — ask the specific engineer doing the specific work.

5. Confidence inflation

Working with AI can make people feel faster than they are. The dopamine hit of generated code is not the same as the code being correct. Be slightly more skeptical of AI-assisted estimates, not less.

The honest read: AI changes the slope of the line, not the shape of the curve. Some work is genuinely faster; the long pole has shifted; the cone of uncertainty is just as wide as before. Update your priors on individual estimates, but don't assume the team's overall throughput is doubling — usually it's a real but modest speed-up, masked by a louder narrative.

PM Playbook — Questions to ask

The next time you ask "how long will it take?", try these:

• Give me a range, not a number. — the range carries the uncertainty info; a single number throws it away
• What's the 90% case, not the hopeful case? — the date you can commit publicly vs the date the team is wishing for
• What could make this slip? — the list you get back is the real estimate
• Have we built something like this before? — calibrates whether to trust the number or plan for re-estimation
• When you say "almost done," what specifically is left? — forces the last-10% list out into the open
• Is this estimate for code-complete or for shipping? — catches the QA, review, and rollout gap
• Is this estimate based on how long this used to take, or how long it takes now? — recalibrates against the AI-era productivity shift
• If we're 2× over, what do we cut? — pre-commits the trade before the slip arrives

These eight questions alone will turn most estimate conversations from a guessing game into a planning one.