Most modernisation quotes aren't wrong about the scope. They're wrong about who — or what — is going to do the work.
Ask five vendors to quote a legacy modernisation project and you'll get five similar scoping documents and five wildly different prices, usually converging on some multiple of engineer-months times a day rate. That arithmetic made sense when the only way to rewrite a decade of undocumented business logic was to pay a team of people to read it, understand it, and reproduce it by hand. It makes much less sense now, and most vendors haven't updated the model — because the model is also how they bill.
A traditional modernisation quote is built on a fairly conservative assumption: humans will read the old codebase, humans will design the new architecture, and humans will write and test every line of the replacement. Padding gets added for the inevitable surprises — undocumented edge cases, silent dependencies, the one integration nobody remembers building. All of that is reasonable given the assumption. The problem is the assumption itself is now the most expensive part of the equation.
AI-native delivery doesn't change what needs to be understood or rebuilt — the business logic still has to be correctly reproduced, the edge cases still have to be found. It changes who does the reading, drafting and first-pass testing, with an engineer directing and reviewing rather than typing every line themselves. That's a genuine change in the unit economics of the work, not a corner cut in the scope.
It's tempting to assume any AI-assisted approach automatically compresses cost, and that's exactly the kind of vendor claim worth being skeptical of. The gains show up specifically where the work is dominated by reading and reproducing existing, well-bounded logic — which describes most legacy modernisation — and they show up much less on genuinely novel design work, ambiguous requirements, or anything that depends on a human negotiating trade-offs with stakeholders. A modernisation project is mostly the former. A greenfield product build is a much more even mix.
The other honest caveat: the quality bar doesn't move. Faster reproduction of legacy behaviour is worthless if the replacement is subtly wrong. The economics only work if the review discipline — tests, staged rollout, a human who actually understands the domain checking the output — is treated as non-negotiable, not as the thing you cut to hit the lower price.