Using AI to Estimate Engineering Work (Carefully)

TL;DR: Estimation prompts AI gives you tend to run short, because the model estimates the scope you described, not the scope you'll actually hit. Testing, review, deployment, and mid-task unknowns get left out unless you name them. Ask for a range with stated assumptions, and supply your own team's history so the model has something real to calibrate against.

Why do AI time estimates for engineering work usually come in low?

Ask a model "how long will this feature take" and it answers the question you asked: how long does the described work take, read as the happy path. It has no visibility into your codebase's actual friction, no memory of the last time a "simple" migration turned into a week of cleanup, and nothing forcing it to price in review cycles, flaky tests, or the meeting that reopens the scope halfway through. The estimate isn't wrong about the words in your prompt. It's incomplete about the job.

That gap has a name outside AI entirely. The planning fallacy, the tendency to underestimate completion time even when you have direct evidence that similar work has run long before, was proposed by Kahneman and Tversky and has been studied in humans for decades. A 2024 large-scale evaluation of cognitive biases in language models tested for an equivalent pattern directly: give a model a project and ask it to allocate time, then separately tell it that comparable past projects ran over by a specific margin, and see whether its estimate actually moves. The paper's own framing of the target behavior is worth quoting directly: it tests whether models "maintain their optimism about the current project in the face of historical evidence to the contrary" (Malberg, Poletukhin, Schuster & Groh, "A Comprehensive Evaluation of Cognitive Biases in LLMs," arXiv:2410.15413, PDF fetched Sept 5, 2026). Across the full study, the authors report "evidence of all 30 tested biases in at least some of the 20 LLMs" they evaluated, planning fallacy included.

Be precise about what that does and doesn't prove. There's no public benchmark that measures how far AI-generated engineering estimates land from real completion times, so nobody can honestly hand you a number like "AI estimates run 40% short." What the research above establishes is narrower but still useful: the structural bias that makes humans anchor on optimistic scope and resist revising it, even in the face of contrary evidence, shows up in language models too, in a setup designed to isolate exactly that behavior. Treat what follows as reasoning about why the failure mode is plausible and how to design around it, not as a measured error rate you can quote.

None of this is unique to AI, either. Software estimation theory has described the shape of the problem for decades under the "cone of uncertainty": uncertainty about a task's real scope is highest at the very start of the work and only narrows as you actually get into it, which is exactly the moment a quick prompt asks for a number. Asking a model to estimate before any real investigation has happened puts it at the widest, least reliable point of that cone, the same spot where human estimates are also least trustworthy. The difference is that an experienced human at least has a felt sense of how wrong their early guesses tend to run; a model has no comparable memory of its own past estimates being wrong unless a prompt supplies that history explicitly.

The practical response to that shape isn't to demand a better single number up front; it's to expect the estimate to move and to re-run the prompt once you actually know more. An estimate given after reading the relevant code, or after the first day of work, is starting from a narrower point on the cone than one given cold from a two-sentence description, and it deserves more weight for exactly that reason. Treat an early AI estimate as the widest, least reliable bound you'll get, not the number that goes into a deadline.

What does a one-line "how long will this take?" prompt actually leave out?

Almost everything that isn't writing the first version of the code. A prompt that just describes the feature and asks for a time estimate skips, by omission, the categories of work that routinely double a "simple" task.

None of these are exotic. They're the ordinary shape of software work, and a model will happily estimate around all of them unless your prompt names them as scope it should account for.

How do you prompt for a range instead of a single guess?

Ask for three numbers, not one, each tied to a stated assumption: a best case (nothing goes wrong, no surprises), a likely case (the normal amount of friction), and a worst case (the assumption that would make it slip badly). Forcing the model to write down what has to be true for each figure turns a single confident-sounding guess into something you can actually interrogate.

Role: Engineering estimator, not a cheerleader for the fastest possible number.

Context
- Task: [describe the feature or fix]
- Codebase/stack: [language, framework, relevant existing systems it touches]
- What's already known to be uncertain: [anything you're not sure about yet]

Task
Give a three-point time estimate: best case, likely case, worst case.

Rules
- State the specific assumption that would have to hold true for each number
  to be right, not just the number itself.
- Explicitly account for: writing tests, code review and rework, deployment,
  and any coordination with other people or teams.
- List anything about this task you don't have enough information to
  estimate confidently, instead of silently assuming the best interpretation.
- Do not compress the range to look more decisive. A wide range on a vague
  task is a more honest answer than a narrow one.

Output
Best/likely/worst case with the assumption behind each · open unknowns that
affect the estimate · what information would narrow the range.

What is reference class forecasting, and why does it fix the anchoring problem?

Kahneman and Tversky's own prescribed antidote to the planning fallacy is what they called the "outside view": instead of building an estimate from the inside, by imagining the steps of this specific task, you estimate from how a class of genuinely similar past efforts actually went. Applied to a prompt, that means you supply the comparables yourself. A model has no access to how long your last three migrations actually took unless you paste that in; asking it to estimate "in a vacuum" just invites it back to the happy-path default. Give it two or three real past tasks and their actual durations, and ask it to place the new task relative to those, not to invent a number from the description alone.

Finding the reference class is the part that takes actual effort, and it's worth doing before you open a chat window rather than trying to recall it from memory mid-prompt. Pull two or three genuinely comparable tickets from your own issue tracker, note how long each one actually took start to finish (not the original estimate, the real number), and note anything unusual that made one run long or short. That short list is more valuable calibration data than a much longer prompt with no real numbers in it, because it's the one thing a model structurally cannot generate on its own: a real record of how your specific team's estimates have historically missed. This is also where AI genuinely earns its place in the process. Reasoning about how a new task compares to stated precedents is something language models handle well, precisely because it's pattern-matching against information you gave them rather than estimating from nothing.

What is AI actually reliable at in the estimation process, and what should stay human?

Decomposition, not duration. Handed a vague feature request, a model is genuinely useful at expanding it into the fuller list of what the work actually involves: migration steps, edge cases nobody mentioned out loud, rollback planning, documentation, the parts of "add a settings toggle" that turn out to touch five files instead of one. That's a real strength, and it's exactly the correction-prompt use of AI worth relying on, similar in spirit to how our PRD and roadmap prompts turn a rough idea into a fuller spec before anyone estimates it, or how a meeting-notes-to-spec workflow surfaces scope that was only said out loud once.

What should stay human is the actual number attached to each item on that list. Your team's throughput, the specific parts of your codebase that are quietly expensive to touch, and the organizational overhead of getting a change reviewed and shipped are calibration data a model doesn't have and can't infer from a task description. The reliable division of labor is: let AI build and stress-test the task list (our software development prompt set has templates for exactly that breakdown step), then let people who've shipped on this specific team attach the numbers.

This division holds up even when you're estimating solo, without a team to consult. The value of running the AI-drafted task list past your own memory of similar work isn't that a second opinion feels reassuring; it's that a model-generated checklist is genuinely good at surfacing scope you'd otherwise only notice mid-task, at the exact point it's most expensive to discover. Treat the model's output as a first pass at "what's actually in this," then apply your own history to "how long each of those pieces really takes," rather than accepting either half of the estimate from the model wholesale.

Putting it together: a before-and-after prompt

Before, the version most people actually type:

How long will it take to add CSV export to the reports page?

After, structured to surface the categories the first version skips:

Role: Engineering estimator working from a real task description, not a
best-case guess.

Context
- Task: Add CSV export to the reports page
- Stack: [your framework/language]
- Comparable past work: [e.g. "PDF export on the same page took 3 days
  including review, no major surprises" — supply 1-3 real examples]
- Known uncertainty: [e.g. "unsure whether the export needs to respect the
  same row-level permissions as the on-screen table"]

Task
Give a three-point estimate (best/likely/worst) for this task, placed
relative to the comparable work listed above, not estimated from scratch.

Rules
- Account explicitly for tests, review, and deployment, not just the
  feature code.
- Name the open unknown(s) that could move the worst-case number, and say
  what resolving them would do to the estimate.
- If the comparable work above doesn't actually resemble this task closely
  enough to anchor on, say so instead of forcing the comparison.

Output
Best/likely/worst case · assumptions behind each · unresolved unknowns and
their estimated impact on the range.

The difference isn't length for its own sake. It's that the second prompt makes the model account for the categories of work a one-liner lets it skip, and gives it something real (your own past task, not a hypothetical) to calibrate against instead of the happy path implied by the request.