Will AI make my software project cheaper? Partly
Where AI genuinely speeds up building software, where it quietly costs you more, and the one review rule a supplier should never loosen.
Two suppliers quote you for the same system. One says AI has made engineering nearly free, so the team and the price can be a fraction of what they were. The other says AI output is unusable and they do not touch it. You cannot tell which is right, and each mistake costs you something different.
Believe the first and you budget for a saving that arrives in some places and not others, then find the gap in the final month. Believe the second and you pay full price for work a tool could have done in a day. The worse case is a supplier who uses the tools and stops reading what comes out, because then code nobody understood goes live in your business.
Neither account survives a few months of shipping real systems with these tools in the loop. This is what we see, including the inconvenient parts.
What was actually going on
The gain is real and it sits in the mechanical middle of the work. A new screen that follows the shape of eleven existing ones, the fifteenth test that differs from the fourteenth in three values, a change repeated across six hundred places when a library is retired. The right answer is obvious to whoever reviews it, and checking it is quick, which is exactly what makes it safe to generate.
The largest and least discussed gain is reading old systems. Faced with a two-thousand-line routine written by someone who left in 2011, a tool will produce a readable account of what it appears to do. That is a starting guess, not a finding, and every part has to be checked against the running system. But it turns a week of reading into a day of checking, and it makes modernisation possible where it had stalled because nobody was willing to start.
The gain mostly misses the parts that were always hard. No tool knows that the invoice logic has an exception for one customer because of a contract signed in 2019, or that your operations manager will not use a screen that takes more than four taps. Requirements come from talking to the people who do the work. Design is similar: ask for one and you get a competent, generic answer, the average of everything written on the subject, with no knowledge of your team, your rules or which of your constraints can move.
The dangerous output is code that reads well, passes a glance and is wrong about something only your business would know: rounding on money, tax rules, who is entitled to what. Its surface quality is high, which is exactly why it gets through.
What we changed
The part we will not move on is review. Code written by a person signals its own doubt: an awkward name, a hesitant comment. Reviewers have spent years learning to read those signals. Generated code gives none, whether it is right or badly wrong, so the usual cues for where to look harder do not fire.
So the rule is written down. Every line that ships is reviewed by an engineer who understands it, can defend it, and is answerable for it however it was produced. “The tool wrote it” is not an explanation for a fault in your system.
Two habits follow. Changes are kept small, because the bottleneck moves to review and nobody properly reviews a two-thousand-line generated change, whatever the approval says. And we are more careful, not less, in unfamiliar territory, since that is where generation is most tempting and where we are least equipped to spot what is wrong.
What it did not fix
Delivery is faster, but unevenly, and not by the fraction the first supplier promised. Understanding the problem, choosing between imperfect designs and being sure the result is correct were always the hard parts, and they are still done by people.
A fault that comes from a particular mix of timing, stored copies and clocks is worse with a tool, not better: it will offer confident, plausible causes, and confidence that does not track correctness misleads anyone inexperienced. And nothing here has a figure attached. We have no percentage for time saved and will not invent one.
The pattern, for anyone buying software
Ask your supplier where the tools are used and where they are not, and listen for specifics. Ask who reviews every line and whether that person could explain it to you. Ask what leaves your environment when tools are used. A supplier who answers “everything is faster” has not looked closely.
The shift to watch for is in the ratio of work. Less time typing code and more time reading it is a better use of an engineer, but it is not the same job, and a team that adopts the tools without changing how it reviews is shipping faster in a direction it has stopped checking.
Where this ends up
What this means inside an engagement, where the assistance is pointed, what may leave your environment and who is answerable for each line, is set out under AI-first delivery.