With these rapid changes in delivery practices, it is important to examine where estimation methods are falling short. This article examines why traditional estimation fails in AI-native delivery and proposes a model that matches actual work patterns.
Why traditional estimation breaks in AI-native delivery
The software development industry has reimagined roles and redefined what "done" means. But when it's time to answer, "How long will this take?" — the same spreadsheets appear. Decompose into components. Get specialist opinions. Add a risk buffer. Sum it all up.
This estimation approach assumes each feature takes a predictable amount of effort, components are mostly independent, and that risk is evenly spread. AI-native delivery breaks all three hypotheses. The results will continue to differ from real project outcomes until estimation methods change.
How AI rewrites the rules of software delivery
1. Effort is no longer tied to feature size
Story points work when similar features require similar effort. That's the entire premise of calibration. In AI-native delivery, the same feature can cost 8 hours or 30 minutes — depending on when you do it, who does it, and what tools they're working with.
A senior engineer who has mastered AI partnership will deliver in a fraction of the time a traditionally skilled engineer needs. A more capable model with better context handling changes the equation again. And even the same person with the same model gets dramatically faster as the project matures, because accumulated context makes every subsequent task cheaper.
The relationship between work and effort isn't stable anymore. It's a curve formed by at least three variables.
2. Sequence now changes the total cost
In traditional development, features are treated as independent. Feature A takes 40 hours, Feature B takes 20 hours, and the total is simply 60 hours—order doesn’t matter.
In AI-native delivery, order matters a lot. If the user management module is built first, it helps the AI learn the system’s patterns and conventions. That knowledge then speeds up all later work.
As a result, the same type of module can take two days the first time, but only a couple of hours once the system is established.
3. Risk is no longer evenly distributed
The classic “+20% buffer” assumes that risks are evenly distributed across the project.
AI-native delivery has a different risk pattern. When AI makes an error, fixing it can take anywhere from minutes to several hours. This uncertainty is highest early in the project, when work is still being shaped, and context is limited. As the project progresses and context builds up, mistakes become easier and faster to fix. A flat risk percentage doesn’t capture this changing reality.
Step 3: Estimate Operate with confidence
By the time you reach Operate, context is fully built, and your acceleration curve has plateaued at its fastest. This is where AI-native delivery becomes more predictable than traditional, because the cost of change is low and stable. Bug fixes, enhancements, and configuration changes — these benefit from everything you invested in Build.
Estimate Operate as a steady-state rate derived from the tail of your Build curve. If your last features in Build took 20% of the traditional effort, Operate tasks will fall into the same range.
The key insight: Operate estimation is the one place where your historical Build data directly transfers. Track it, and you’ll have your most reliable numbers within the first month.
Where the AI-native estimation model breaks down
This framework has real limitations, and it is better to make them explicit upfront than discover them during a project.
First, it requires calibration data that may not be available initially. In a first AI-native project, the team’s acceleration curve is unknown. The appropriate approach is to estimate conservatively, track performance closely, and treat the first project as a calibration phase rather than as model validation.
Second, it assumes a team operating in an AI-native way. An engineer using AI mainly as autocomplete will not follow the same productivity curve as someone treating AI as a delivery partner. If a team is still in an AI-augmented stage, traditional estimation with cautious adjustments is more accurate than assuming full curve effects.
Third, the model is best suited for greenfield development. Legacy systems, complex integrations, and regulated environments behave differently: the acceleration curve is flatter, and context investment is higher. Greenfield assumptions should not be applied directly to brownfield projects.
Even when these factors are considered, there is still one additional gap the model does not address on its own.
Related Insights
The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.
Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.
ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.
