What AI Changed About Building Software - And What It Did Not

The most repeated claim about AI and software development is that it made building cheap. The more precise version is that it made writing code cheap, and writing code was rarely the expensive part.

That distinction decides whether the tooling actually changes your economics or just relocates your bottleneck.

What genuinely moved

There is a real, large effect, and it is concentrated in a specific category: simple, well-understood, low-risk software.

Internal dashboards. Admin panels. CRUD interfaces over a known schema. Integration glue between two documented APIs. Data migration scripts. One-off reporting tools. Work that is conceptually straightforward and was expensive only because it took someone’s time.

This category has genuinely collapsed. As several build-vs-buy analyses now note, internal tooling that used to take a quarter can ship in days with agentic coding tools. That is not marketing - it reflects the fact that this work was always mostly typing, and typing is what got automated.

The knock-on effect is real too. A company that would previously have bought a $30,000-a-year SaaS product to avoid a three-month internal build now faces a different calculation, because the build is a week. For this category, the build-versus-buy line has genuinely moved.

What did not move

Anything where correctness is legally or financially load-bearing. Payments, authentication, healthcare data, financial reporting, anything under SOC 2 or GDPR scrutiny. The cost in these systems was never generation - it was review, evidence, testing and accountability. All of that still costs what it cost.

Complex domain logic. Software encoding genuinely intricate business rules - insurance underwriting, logistics optimisation, regulatory calculation. The bottleneck there is understanding the domain and getting the rules right, and no tool compresses the process of extracting knowledge from the four people who actually know how the business works.

Maintenance. This is the one that gets forgotten most. Code that is cheap to generate is not cheap to own. Dependency updates, security patches, browser changes, the accumulation of edge cases - all unchanged. Budget 15-25% of build cost annually regardless of how the code was written.

Deciding what to build. Arguably now the dominant cost. When building is slow, scope discipline is enforced by the schedule. When building is fast, nothing stops a team from shipping six features nobody asked for.

Where the bottleneck went

Teams adopting AI agents frequently report less velocity improvement than expected. The usual reason is that generation was not their constraint.

If your team’s pipeline is: write code → review → QA → deploy, and review was already the slowest step, then making the first step 5x faster does not make you 5x faster. It makes the review queue longer.

This is a straightforward queueing result and it catches out a lot of engineering leaders. The organisations getting real compounding gains from AI tooling are the ones that also invested in review capacity, test automation and deployment confidence - the parts that now bind.

There is a second-order version of this in commissioned work. A vendor who generates code faster but has the same review process delivers at roughly the same rate, with more code to review. Speed of generation is not a meaningful differentiator when you are buying an outcome - which is worth remembering when comparing development quotes.

The security question

Reported vulnerability rates in AI-generated code run notably higher than in human-written code - figures in the 40-45% range have circulated in build-vs-buy analyses, and while the methodology behind such numbers deserves scrutiny, the direction is consistent across sources.

The mechanism is not mysterious. These models generate plausible code, and insecure code is frequently plausible. Missing input validation, over-permissive defaults, secrets handled carelessly, outdated patterns learned from years-old training data - none of it looks wrong at a glance.

The practical response is not to avoid the tools. It is to treat generated code as you would code from a fast, capable contributor who has never seen your threat model: dependency scanning by default, security review for anything touching auth, payments or personal data, and test coverage that would catch a plausible-looking mistake.

Teams merging AI output with lighter review than they would apply to a junior developer’s pull request are running an uncontrolled experiment. The tooling choice matters less here than the process - which is the main reason choosing between coding agents is a smaller decision than it appears.

What this means for build decisions

If you were going to build internal tooling: the calculation has genuinely improved. Reconsider things you previously ruled out on cost, particularly integration work and internal dashboards.

If you were going to buy a product to avoid a build: re-run the numbers, but include maintenance. Buying still wins when the product covers 80% cleanly, because you are buying support, security patching and someone else’s roadmap - none of which got cheaper.

If you were scoping an MVP: faster generation genuinely helps, but the discipline matters more than ever. When building is cheap, scope grows silently. Fixing the timeline and flexing scope is a stronger constraint now than when the schedule enforced it for you.

If you are hiring: the shape of the work changed more than the quantity. Review, architecture, debugging and product judgement are now a larger share of the job.

The honest summary

AI took the cost of one input - writing code - and reduced it dramatically. That input was somewhere between 20% and 40% of the total cost of most software projects, and close to 90% of the cost of simple internal tooling.

So: transformative for simple tools, meaningful but modest for serious systems, and roughly irrelevant for the hardest parts, which were always deciding what to build and being confident it works.

Anyone claiming otherwise is either selling a tool or has not maintained the output for a year yet.

The practical test for any specific claim you encounter: ask which part of the cost it applies to. If the answer is generation, it is probably true and probably narrower than stated. If the answer is review, correctness, maintenance or knowing what to build, treat it with considerably more scepticism - those are the expensive parts, and none of them have moved much.