How to Estimate Software Projects with AI (2026): PERT, Prompts & Sanity Checks

Every estimate is a guess wearing a suit. The problem is not that we guess — we have to — it is that we present a single number (“about three weeks”) as if it were a fact, and then everyone downstream treats it as a promise. Six weeks later, no one remembers it was a guess.

I have estimated, missed, and re-estimated software projects for close to thirty years. The best way to estimate software projects with AI is not a better formula — it is using AI to force the two things humans are worst at during estimation: decomposing work honestly, and stating a range instead of a false single number.

Why single-number estimates fail

Two forces sink most estimates. The first is optimism bias: we estimate the happy path and forget the unhappy ones — the migration, the edge cases, the review cycles, the environment that breaks the day before release. The second is anchoring: someone says “can we do it by the 15th?” and every subsequent estimate quietly bends toward that date.

A single number (“3 weeks”) hides both. A range with a confidence level (“most likely 3 weeks, but 5 if the data migration is messier than we think”) exposes them. The goal of estimation is not to be right — it is to be honest about uncertainty so people can plan around it.

The three-point (PERT) estimate

The most useful estimation tool I know is also the simplest. For each task, name three numbers instead of one:

• Optimistic (O) — everything goes right
• Most likely (M) — the realistic case
• Pessimistic (P) — the things that usually go wrong, do

Then the expected estimate is (O + 4M + P) / 6, and the rough uncertainty is (P − O) / 6. The math matters less than the discipline: naming P forces you to say out loud what could go wrong, which is exactly the conversation optimistic estimates skip.

A worked PERT example

Take a real-ish feature — “add CSV export to the reports page” — the kind that sounds like a day and turns into a week. Decompose it, including the work everyone forgets, and give each task three points (hours):

Task	O	M	P	Expected (O+4M+P)/6
Export endpoint + query	2	4	8	4.3
Formatting & edge cases (encoding, big files)	2	4	10	4.7
Tests	2	3	6	3.3
UI button + wiring	1	2	4	2.2
Docs + rollback plan	1	2	3	2.0
Total	8	15	31	~16.5

Notice what the table gives you that “about two days” never could. The expected total is ~16.5 hours, but the honest range runs from 8 to 31 — and the single riskiest line (formatting & edge cases, P more than 3× its O) is exactly the one to break down further before you commit. You now report “~2 days most likely, up to ~4 if the file-encoding edge cases bite,” which is a plan, not a promise you’ll break.

Where AI genuinely helps

AI is good at the mechanical, forgettable parts of estimation:

• Decomposition — breaking a vague feature into the tasks people forget (tests, migration, docs, rollback, monitoring)
• Surfacing hidden work — asking “what would a senior engineer add to this list?”
• PERT bookkeeping — turning O/M/P into expected values and a total range
• Forecasting — translating a task total into a delivery date given real team capacity

What AI is bad at: knowing your team’s actual velocity, your codebase’s landmines, or which “quick” change touches a fragile subsystem. It will hand you confident numbers with no basis. So the rule holds: AI decomposes and calculates; the human who knows the code decides the numbers.

The prompts that actually work

1. Feature → task breakdown (with the forgotten work)

Act as a senior engineer estimating this feature. Break it into
implementation tasks, and explicitly include the work teams usually forget:
testing, data migration, edge cases, error handling, monitoring, docs,
and rollback. For each task, give an Optimistic / Most-likely / Pessimistic
estimate in hours. Do NOT invent our team's velocity — leave that to me.

Feature: [DESCRIBE THE FEATURE]

2. PERT validation

For the task list below, compute the PERT expected value (O + 4M + P)/6
for each task, sum them, and give the total expected estimate plus a
rough range. Flag any task where the pessimistic case is more than 3x the
optimistic — those are the risky ones to break down further.

Tasks: [PASTE YOUR O/M/P LIST]

3. The optimism check

You are a skeptical delivery lead reviewing this estimate before I commit
to a date. List the assumptions baked into these numbers, the tasks most
likely to blow up, and anything a first-time estimator of this feature
would underestimate. Be specific.

Estimate: [PASTE YOUR ESTIMATE]

That third prompt is the one that saves the most pain. Running your own estimate through an adversarial review before you say a date out loud catches the optimism you cannot see in your own numbers.

→ Get all 14 prompts (decomposition, PERT validation, delivery forecasting, comms)

The mistakes AI makes worse

• Fabricated precision. AI will say “14.5 hours” as if it measured it. Round to ranges; precision you did not earn is a lie.
• Ignoring your context. The model does not know your legacy auth service is a minefield. Override any number that ignores what you know.
• Estimating the happy path. If you do not explicitly ask for the forgotten work, AI defaults to the clean version — the same mistake humans make.

A repeatable workflow

1. Prompt 1 → full task list including the forgotten work.
2. Adjust O/M/P using what you know about your team and codebase.
3. Prompt 2 → PERT totals and a range.
4. Prompt 3 → adversarial optimism check; fix the top risks.
5. Present a range with a confidence level, never a single number.

FAQ

Can AI estimate a software project for me?
No. AI can decompose the work and do the PERT math in seconds, but it does not know your team’s velocity or your codebase’s risks. Use it to structure and pressure-test the estimate; you supply the numbers.

What is a three-point (PERT) estimate?
Instead of one number, you give an optimistic, most-likely, and pessimistic estimate, then compute (O + 4M + P)/6. It forces you to name what could go wrong, which single-number estimates hide.

Why do software estimates always run over?
Optimism bias (estimating the happy path) and anchoring (bending toward a desired date). Ranges with confidence levels and an explicit pessimistic case counter both.

Should I give stakeholders a single date?
Give a range with a confidence level and the key risk that would push it out. A single date reads as a promise and sets everyone up to be disappointed.