A few months ago I wrote about a habit I'd fallen into and had to break: asking AI how long a task would take, and trusting the number that came back.
The number was always huge. It never mentioned headcount. And for a while, I couldn't figure out why.
The problem with asking AI to estimate
Here's the answer, once I actually sat with it: an AI model has no idea who's on your team, how well they know the codebase, or what "done" means in your specific context. Ask it for an estimate and it defaults to a padded, generic, worst-case guess — because that's the safest answer it can give without any of the information that actually determines a real timeline.
Your own judgment, built from your team's actual context, is more reliable than anything a model will hand you. The fix isn't a better prompt. It's a better method — one where your judgment is the engine, and AI is a multiplier you apply to it, not an oracle you defer to.
The method, briefly
The framework has four moves:
- Estimate the work as if there were no AI. This is your anchor — the number you'd trust from experience alone.
- Split the work into three tiers, because AI does not speed up every kind of work equally:
- Mechanical / boilerplate — scaffolding, CRUD, wiring a component from a clear mockup. AI is genuinely fast here, often 3-5x.
- Integration with existing code — matching your patterns, working around your stack's quirks. AI helps, but you're spending real time reviewing and correcting. More like 1.5-2x.
- Novel, ambiguous, or judgment-heavy work — the spec isn't fully decided, the design isn't settled. AI barely moves the needle here. Roughly 1x — sometimes slower, because the bottleneck is thinking, not typing.
- Add back what AI does not compress: code review (which grows, since more code gets produced faster), scoping and discovery, and the friction of integrating with a system nobody fully mapped out in advance.
- Convert effort into a timeline separately. Engineer-weeks is not calendar-weeks until you know what can actually run in parallel — and even then, apply an efficiency factor, because two engineers rarely deliver twice the throughput of one.
The honest result, most of the time, is a real 1.5-2x speedup on the whole project. That's excellent. It's just nowhere near the "AI makes this instant" fantasy that sets teams up to look like they're failing at succeeding.
Why I turned it into a tool
The first version of this was a spreadsheet — genuinely useful, downloaded and used by a fair number of people. But a spreadsheet has friction built in: download it, open it, trust that the formulas are intact, figure out which cells to touch.
So I rebuilt it as something you can just open and use. No download, no email wall, no signup. Enter your baseline, adjust the tiers and multipliers to match your own team's reality, and watch the estimate — and the honest calendar range — update as you type.
What to actually do with the number it gives you
Two things, regardless of what the tool outputs:
Report a range, not a single number. A single number gets treated as a promise the moment it leaves your mouth. A range signals, correctly, that this is an estimate grounded in judgment, not a guarantee extracted from a formula.
Recalibrate the multipliers as you gather real data. The defaults (4x, 1.75x, 1x) are starting points from general experience, not laws. If your team's actual numbers look different after a few sprints, change them. The tool is a calculator for your judgment, not a replacement for it — and it gets more accurate the more honestly you feed it what's actually happened on your team.
This is the same estimation method I originally shared as a spreadsheet, now rebuilt as a live tool. If you use it and your team's real multipliers end up looking different from the defaults, I'd genuinely like to hear about it — that's exactly the kind of data that makes a framework like this better over time.