AI can now generate code in seconds. Naturally, clients expect the estimate for a software project to shrink by roughly the same amount. In practice, it doesn’t work that way. 

“AI doesn’t eliminate the work, it changes where the work happens,” says Igor Omelianchuk. 

More effort is moving toward requirements, context, validation, review, and security, toward making sure the result actually solves the business problem.

Estimating a project by the old rules stops producing numbers anyone can trust.

• Yuriy Diachenko, CEO at MIF Projects, has spent 15+ years leading engineering teams through modern technology transitions. 
• Igor Omelianchuk, Co-Founder and CEO at Corsac Technologies, works with AI solutions in production across complex platforms. 

Together, they walk through AI-powered project estimation: how AI actually changes IT timelines and project estimates, and how Corsac rebuilt its own estimation process to keep up with it.

Faster Code Generation Doesn’t Mean Faster Project Delivery

The Parts of Delivery AI Never Touched

Generation stopped being the constraint. Verification became it.

That’s the short version of what Corsac’s engineering team has observed across AI-assisted projects over the past year.

AI cuts the time it takes to write code by most of the clock but writing code is only one part of shipping it. 

Requirements, review, testing, validation, security, and integration don’t shrink just because the code arrived faster. AI doesn’t remove that work, it just moves where it happens.

AI agents now produce code that compiles on the first run, carries decent test coverage, and looks syntactically correct: 

• decoupled structure, 
• modern patterns, 
• modern architecture. 

A lot of the boilerplate and edge cases that a bored developer would quietly push into technical debt get covered immediately instead.

10-Line Pull Request Gets More Scrutiny Than a 400-Line One

“The code generation became cheap, but delivery did not,” says Yuriy Diachenko. 

The reason is structural: the code arrives faster, but it’s still the same amount of code, often more, that has to be reviewed, tested, and integrated. That part of the pipeline hasn’t gotten any faster just because the code showed up quicker.

Yuriy points to a pattern every reviewer will recognize: 

“When you have a ten-line pull request, you’ll get thirty comments on it. When you have a four-hundred-line pull request, you’ll review it very fast and get only ten or twenty comments — because people get tired and want to skip this part of the job and get back to the main task.”

Where the Bottleneck Actually Moved

That’s the uncomfortable part of building any cost estimate in project management terms for AI-assisted work: a smaller, well-scoped diff gets more scrutiny than a bloated one, not because reviewers are careless, but because thorough review doesn’t scale with volume the way code generation does. 

Any project estimate that treats “AI writes the code” as the end of the story is estimating the smallest part of the job.

How Different AI Development Approaches Affect Project Timelines

If the way we build software has changed, can we continue estimating the project in the same manner as we did before?

Not every team uses AI the same way, and the difference changes what an estimate should even look like. Yuriy Diachenko divides current practice into three tiers, or AI scale factors.

The reference point is the classic, non-AI process: requirement solicitation, then writing the code, then code review, then testing and integration, one phase after another. It has a long coding phase and a predictable tail, so the estimate and the actual work are roughly the same shape. AI changes that shape differently depending on which tier a team operates at.

#1. AI-Assisted Development: The Engineer Still Holds the Wheel

The first is AI-assisted development, where the AI era started: code completions, small tweaks made with AI tooling to improve performance. 

A developer typically asks the tool to generate one function or method at a time, then decides whether and how to fold it into the codebase.

“With this approach, we still follow the classic development process; we just accelerate it a bit with code generation,” Yuriy explains. 

Because a person is still writing the surrounding logic and deciding what gets integrated, AI is only speeding up typing, boilerplate, and tests here — not the judgment and integration work an estimate actually has to price. 

The engineer stays in the driver’s seat, and the estimate barely has to change shape.

#2. Vibe Coding: Fast to a Demo, Unpredictable to Production

The second is vibe coding: a live prompting session with an agent, where the result is confirmed by the demo, not by reading the code. 

“It’s a great opportunity to have a quick demo,” Yuriy says, “but a lot of issues arise when you want to change this demo.”

The prompt effectively becomes the spec: there’s no separate document defining the expected behavior, so “done” means the demo looks right, not that the behavior matches a defined requirement. 

A small prompt to fix something as minor as a localization string can quietly bake in the wrong authorization logic, and the next change causes regressions in modules nobody touched, because there’s no persistent memory, no decision log, and no consistent rule set behind the code.

→ In practice, that looks like a back-and-forth conversation with the agent: change this button, move it here, adjust that field, confirmed by how the demo looks, not by what the code actually does. The instability isn’t random. 

It shows up when the context given to the agent is too short, or the instructions aren’t precise enough, and there’s nothing structural in the process to catch that before it ships. It’s exactly this pattern, Yuriy notes, that sent teams looking for a more disciplined approach.

On Corsac’s own internal timeline comparisons, vibe coding’s delivery time lands anywhere from 20% to 120% of a predictable, non-AI baseline — and there’s no way to tell in advance where a given feature will land.

#3. Structured Agentic Engineering: Slower to Start, Finite to Finish

The third tier is structured agentic engineering, and it exists specifically to close the gaps vibe coding left open: a harness that gives agents persistent memory instead of none, a decision log instead of undocumented choices, and, as Yuriy puts it, “a way to verify that the developed result matched the original one” instead of confirmation by demo alone.

This tier is genuinely faster than the manual baseline, but not dramatically so, because the harness itself, the context, the rules, the verification step, is real work that someone has to build and maintain before a single feature ships.

Yuriy and Igor are direct about the trade-off: the outcome is better than the classic approach, but the process isn’t dramatically faster than most teams expect, because setting up that harness is real, front-loaded work, not overhead that quietly disappears once the team gets going.

Coding gets shorter in all three tiers. The feature doesn’t. 

The only segment that got cheaper is the one most project estimation templates still measure.

Why AI Changes the Role of Requirements in Project Estimates

The Question an AI Agent Never Asks

“We’re using a set of AI agents together with human expertise to make estimates more complete, consistent, and reliable,” Igor Omelianchuk said. Requirements are where that partnership gets tested first.

AI agents need far more detailed requirements than a human developer ever did: not just syntactically correct code, but code that covers every edge case a business actually cares about.

“AI agents really need detailed requirements to produce good domain code quality,” Yuriy Diachenko says.

The difference shows up in what happens when something is unclear. A developer working the classic way can walk over to a project manager or a business analyst and ask. An AI agent typically won’t.

“They sometimes do, but basically what they do is take the decision on their own, and it’s not that often that this decision is correct — because they didn’t have enough input,” Yuriy explains.

Where the Estimated Effort Actually Goes Now

That single behavioral difference reshapes pricing and estimating in project management: effort moves from writing code toward preparing requirements, context, and validation. 

Giving agents enough context to implement the right domain logic, staying consistent between iterations, following security and development policy, and validating system behavior after the fact: none of that used to be a separate line item when a human developer could just ask a question and keep going.

Coding, Requirements, Context, Validation: The New Shape of the Work

The mismatch is unintentional. 

Nobody building a project estimate format on purpose is cutting requirements work; teams are estimating a box that quietly stopped being the whole job.

We Tried Letting AI Estimate a Project. Here’s Why We Stopped.

Why the Numbers Came Out Biased

“The quick answer is no — you shouldn’t do this, and don’t even try it,” says Yuriy, describing what happened when Corsac tested whether AI tooling could estimate a software project directly. 

The team cross-checked the results against several other estimation methods, and the numbers AI produced were consistently biased toward a manual coding process: estimating how long it would take a person to type the code, not what it would take to actually ship it.

Two Projects, Two Completely Different Cost Estimates

The bias runs deeper than typing speed. Different software carries different quality attributes, and a general-purpose model doesn’t know which set applies.

Power plant monitoring software and an indie game don’t follow the same instructions, and they don’t answer to the same compliance regime either.

A connection loss that’s an inconvenience in a game is unacceptable in a system monitoring critical infrastructure, and that difference changes how much review, testing, and mitigation work has to be priced in, regardless of how fast the code itself gets written. 

That gap belongs to the domain the software serves, and no general-purpose model carries that context in on its own.

What AI Can’t See About Your Process

On top of that, a model estimating cold has no visibility into how your team actually works. It doesn’t know:

• what AI scale factor your team runs at — manual, AI-assisted, or a fully orchestrated agent harness that still has to be built and maintained,
• what level of expertise and seniority your developers bring,
• which frameworks you standardize on,
• or which modules from previous projects can simply be reused.

An estimate is a commitment made under your constraints, and none of those constraints are in the model.

What Corsac Actually Asks AI to Do Instead of Estimating

Decision Stays With the Engineer

“The main rule is we don’t give AI the ability to judge the decisions and to take the decision,” Igor says. 

Corsac uses AI tooling to analyze the existing system and produce intermediate artifacts, not final numbers, and every process has a checkpoint where an expert validates whether it was done correctly.

That shows up concretely in scope clarification: the team gathers artifacts from the client and asks AI agents to summarize anything that looks missing or overlapping. 

“We never confirm results that it produces without verifying them,” Igor adds.

Three Cross-Check Methods: Requirements-Based, Screen-Count-Based, LOC-Based

The same guardrail applies to the estimate itself. AI doesn’t estimate the artifacts it generates; Corsac’s engineers do. 

AI is used to produce alternative estimates using alternative methods – requirements-based, screen-count-based, lines-of-code-based, purely to see what deviation shows up against the manual estimate. 

“If the deviation is way too big, then this is the signal that we have to check if we missed something,” Yuriy explains, not a number to average into the final figure, but a flag that something in the manual estimate might be wrong.

The One Thing AI Is Genuinely Unmatched At

Where AI is genuinely, unmatchably strong is coverage. “We ask it for the evidence, we do not ask it to estimate,” Igor says. 

AI tooling is built to dig through volumes nobody was ever going to read end to end: presentation decks, source code, specifications, requirements, data exports, applying the same unopinionated criteria to document four hundred that a tired human reviewer stopped applying somewhere around document forty. 

The value is coverage and consistency, not judgment.

For the estimate itself, the goal is the same: minimize the amount of uncertainty by producing an exhaustive list of the requirements a project actually has to build. That set of artifacts is transferred to the expert team and become the evidence it’s built on.

How AI Changes Legacy Modernization Estimates

What a Decades-Old System Hides From Its Own Documentation

Estimating modernization work is its own category of hard, and it starts before anyone writes a line of code. Most systems Corsac is asked to modernize have been in production for decades, carry millions of users and millions of lines of code, with dead regions nobody’s opened in years, and have gone through pivots no single document tracked. 

Documentation is incomplete at best; in the worst cases, the knowledge lives only in the heads of a handful of engineers who have been there the longest.

That’s rarely a documentation failure on anyone’s part. 

The people who built these systems had to work fast, and not every decision gets recorded when the priority is shipping the next release, not writing down the last one.

Why Understanding a Legacy System Used to Cost an Entire Team

“There even was a case where the business logic lived in a script that was started manually by the person after the working day, and the script was left on the person’s local machine,” Yuriy recalls. 

In systems like this, requirements aren’t written anywhere; they’re embedded in stored procedures, cron jobs, and habits nobody documented. And because data loss is unacceptable in a system real users depend on, that history has to be recovered. There’s no room for deviation on the critical path either: users have already built their own workflows around exactly how the software behaves today, undocumented parts included.

The old way to do this meant staffing an entire development team just to read the system: weeks spent rediscovering decisions nobody wrote down, arriving at a partial picture before anyone could commit to a number. 

“With AI tooling we no longer do this,” Igor says. “We start analyzing the system with our requirements archaeology agents,” a set of agents that convert source code back into requirements, so the team understands how the system is supposed to behave without reading it file by file. 

The output doesn’t stop at a summary: it identifies the specific places an expert actually needs to look at, instead of handing back a wall of documentation nobody has time to read either.

How Requirements Archaeology Agents Read a System Nobody Documented

This is the same discipline behind Corsac’s Software Archaeology process: measuring what a legacy system actually is, in file-level evidence, before anyone prices a rebuild. 

On systems Corsac has measured this way, a client’s own line-count estimate has differed from the real in-scope size by a factor of three to ten, in both directions at once, since dead and vendored code inflates the count while hidden structural risk stays invisible to it. 

On one system, this kind of pass recovered 438 numbered requirements, 88 of them flagged as safety-relevant: the kind of detail no estimate can price correctly until it has been surfaced.

Everything that determines the price is invisible from the repository until someone goes looking for it.

From AI-Powered System Discovery to a Reliable Modernization Estimate: How Corsac Actually Builds an Estimate

Directed Assessment vs. Full Discovery – Two Ways Into the Same Process

Not every modernization request starts from the same place, and Corsac’s process branches accordingly. 

“Some can come to us and ask: we have the system, we have the documentation, we understand what we need to do,” Igor says. A client who already knows the target gets a direct, scoped estimate. 

Others arrive with a symptom rather than a plan: the system got slower, compliance is slipping, and nobody’s sure why. 

 That request gets a full modernization assessment instead.

Turning Technical Issues Into a Business Heat Map

A modernization assessment starts with full system discovery: 

• documentation, 
• source,
• structural dependencies, 
• a measurement of the system’s actual size. 

From there, Corsac’s architects translate technical issues into what Yuriy Diachenko calls business cost mapping: a list of findings marked against what each one actually costs the business, and how critical it is, producing a heat map of the whole system. 

A framework version that has fallen out of support, for instance, doesn’t read as urgent on its own, until it’s mapped to the security vulnerabilities and compliance failures it’s quietly creating. None of this runs on one generic, one-size-fits-all model.  

The agents doing this analysis are configured for the specific technology stack and domain in question, which is what makes the resulting heat map something a client’s own architects can act on.

The Final Estimate Still Belongs to Architects

That heat map is what determines the modernization strategy: full rewrite in some areas, module-by-module replacement in others. 

All of these decisions, and the estimates that follow them, are produced by architects, experts, and senior engineers, not by AI. 

Once a client agrees on the approach, the team moves into requirements engineering to surface what’s still hidden, cross-checks the resulting estimate against multiple methods, and delivers the required effort alongside the roadmap to get there.

“For us, AI does not replace engineering judgment,” Igor Omelianchuk says. 

“It gives our engineers better information to make their judgment. If we can understand systems better before we start working on them, we can produce better estimates, reduce uncertainty, and avoid expensive surprises in the process. We can make everything clearer and more predictable, and that’s already half of the success of any modernization project.”

Takeaways: The New Math of an AI-Era Estimate

Pull the thread through all of this, and the estimate itself changed shape in three specific ways. 

→ Code generation got cheap; delivery did not, because the work moved out of the coding box and into context, review, and behavior validation.

→ Estimating the coding step alone now means estimating the smallest part of the job, a mismatch nobody created on purpose, which is exactly why it’s so easy to miss. 

→ And vibe coding isn’t fast so much as it’s unpredictable: quick to a demo, unbounded once it has to survive contact with production.

What AI Is For, And What It Isn’t

On the AI side of the process, the guardrail stays the same regardless of project size. 

Don’t ask AI for the estimate, ask it for the evidence; coverage and consistency are what it’s genuinely unmatched at. 

The decisions stay with engineers: the checkpoints, the domain-specific bias a system like a power plant or a healthcare platform actually requires, and a team whose judgment can’t be replaced by a faster model. And the estimated effort itself has to adjust to the process a team actually runs: harness setup, keeping that harness alive, domain-logic validation, and scheduling around review bottlenecks are real line items now, not overhead someone quietly absorbs.

Legacy systems aren’t estimated. They’re measured, and then the measurements get estimated.