AI didn't kill software estimation. It moved the uncertainty somewhere new. Your best-case number got really better, which feels great. Your worst-case number got much harder to pin down. And the middle, the number you actually quote to clients, got wobblier than ever. That's not a reason to abandon three-point estimation. It's the reason to lean on it harder.
Every project starts the same, someone needs a number. Doesn't matter if it's a client waiting on a proposal or your own team sizing up the next feature for sprint planning.
How long will this take, and what will it cost. Before I write a line of code, before I know half of what I'll run into, I have to commit to a figure. Sometimes that figure goes into an offer and eventually a contract. Sometimes it goes into a sprint plan, or a roadmap slide someone already showed to a VP. Get it wrong on the low side and you eat the difference, whether that's your margin or your team's next few weekends. Get it wrong on the high side and you lose the deal, or you watch the feature get bumped for something that promised to ship faster.
For years I've done this with three-point estimation. It's an old, boring, reliable technique (known as PERT). Lately I've been wondering whether it still holds up now that AI writes a big chunk of the code.
The quick reminder
If you've never used it, three-point estimation is simple. For any task you come up with three numbers instead of one.
Optimistic (O). Everything goes perfectly, no surprises.
Most likely (M). What usually happens, based on experience.
Pessimistic (P). Everything that can reasonably go wrong, does.
Then you weight them: (O + 4M + P) / 6. The most likely case counts the most, but the extremes still pull the number in their direction. The whole point is that a single guess lies to you, and three honest guesses lie less.
That formula worked because I had done enough similar work to calibrate each number from memory. I knew what "everything goes fine" felt like, and I knew what "the third-party API is undocumented and the requirements shift twice before I ship" felt like.
Now AI messed with all three of those numbers. But not equally.
The optimistic number got better
This is the part everyone notices first. With AI in the loop, the best-case scenario is really faster than it used to be. Scaffolding, boilerplate, the boring CRUD layer, a first pass at a test suite. On a good day it's not close.
So your O drops. Fair enough. That part is real.
That fast, clean best case can be seductive, and it's the number your brain wants to reach for when someone is asking "so how quickly can you implement this?" A client chasing their own deadline. A product manager who already told their VP this is already done.
Don't quote that optimistic number. You never did before, and AI didn't change that rule. It just made the optimistic number more tempting.
The pessimistic number got harder to set
Here's where it gets interesting. AI doesn't remove work. It redistributes it.
The time you save generating code comes back to you somewhere else, and usually somewhere less pleasant. Reading code you didn't write. Reviewing output that looks confident and correct and is quietly neither. Untangling something that ran fine on its own but breaks the moment it touches the rest of the system.
That last one is the real killer. AI-generated code has a habit of working beautifully until it doesn't. Especially in isolation but then creating friction at the seams, the exact place where problems are expensive to find.
So your pessimistic case now has to hold a new kind of failure. Not "this is hard and might take a while," which I know how to price. It's "the AI got this confidently wrong, it looked right, and nobody caught it until integration testing." That's a worse failure mode, because it hides. Setting a P that accounts for it means padding for a category of bug I couldn't have written by hand.
The middle is now the hardest number of all
Most likely used to be the easy one. It's the number you anchor in experience, and I have a lot of experience.
But my experience is mostly pre-AI. I have fifteen years of internalized data for how long things take when I (or a human) writes them. I have maybe a year of messy, inconsistent data for how long they take when AI writes them and I review them. Some tasks fly. Some turn into a review grind that would have been faster to write myself.
So the number I used to trust the most is now the one I trust the least. That's a strange place to be.
About the data, briefly
You'll see a lot of confident statistics thrown around on this topic. Be careful with them.
The one study I'd actually put weight on is the METR randomised controlled trial from 2025. They took experienced developers, gave half their tasks AI tools, and measured the result. The developers predicted AI would make them faster. They felt faster afterwards. They were measurably slower.
That gap between how fast AI feels and how fast it actually is should make anyone pause before pricing a discount into an offer.
But here's the problem. Even METR later revoked that result back somewhat, called it historical, and started redesigning the study because the tooling kept changing under them. The ground is still moving.
That uncertainty isn't a reason to throw up your hands. It's an argument. When you really don't know, a single confident number is the worst possible answer. A range is better.
What I actually do now
Two small changes.
First, I split the estimate. Generating the code and reviewing or integrating the code are now two different jobs with two different risk profiles, so I give each its own three points. The generation step gets an optimistic best case. The review and integration step gets a fat pessimistic tail. Bundling them into one number hides exactly the risk I most need to see.
Second, until I have real data from finished AI-assisted projects, I keep my pessimistic case deliberately conservative. Even when the optimistic case looks fast enough to be embarrassing. The speed is real, but the risk of getting it wrong is mine, or my team's, not the AI's.
So, do we still need three-point estimation in the AI age?
More than before, I think.
The uncertainty didn't go away. It moved. Three-point estimation is still the tool that lets me point at it honestly and say: somewhere in here. Probably.
Top comments (0)