AI Software Estimation: Why PERT Still Matters

Software estimation hasn't died because of AI; the uncertainty has just shifted. Your best-case scenario is now significantly faster, but your worst-case scenario is much harder to quantify. The "most likely" number you quote to clients has become wobblier than ever. This is exactly why you should lean harder into three-point estimation (PERT) rather than abandoning it.

Whether it's a client proposal or a sprint plan, getting the number wrong on the low side eats your margin or your weekends. Get it too high, and you lose the deal. I've used PERT for years, and while AI changes the variables, the logic holds.

The PERT Framework

For those unfamiliar, three-point estimation replaces a single guess with three distinct figures:

• Optimistic (O): Everything goes perfectly.
• Most Likely (M): The typical experience.
• Pessimistic (P): Everything that can reasonably go wrong, does.

The weighted average is calculated as: (O + 4M + P) / 6.

The goal is to avoid the lie of a single number. However, AI has skewed these inputs unequally.

The "Optimistic" Trap

The O value has dropped significantly. Scaffolding, boilerplate, and CRUD layers that used to take hours now take seconds. This makes the optimistic case incredibly seductive. When a PM or client asks how fast something can be shipped, your brain wants to reach for this number.

Resist it. AI makes the best-case scenario faster, but it doesn't make the project risk-free.

The New Pessimistic Reality

AI doesn't eliminate work; it redistributes it. The time saved during generation is often spent on less pleasant tasks: reviewing confident-but-wrong output or untangling code that works in isolation but fails during integration.

The new failure mode isn't just "this is a hard problem." It's "the AI was confidently wrong, it looked correct, and we didn't catch it until the final testing phase." This is a hidden cost. To account for this in your P value, you have to pad for "hallucination debugging," which is a different mental model than traditional debugging.

Practical AI Workflow for Sizing

To keep your estimates grounded, I've adjusted my AI workflow:

1. Isolate the "AI-fast" parts: Identify boilerplate or standard API integrations where the O is truly lower.
2. Buffer the "Seams": Increase the P value for any area where AI-generated code must interface with complex legacy systems.
3. Review Time = Dev Time: When calculating M, treat the time spent auditing AI code as equal to the time it would have taken to write it manually.

By treating AI as a productivity multiplier for the "easy" parts and a potential risk multiplier for the "hard" parts, you can keep your project timelines realistic.