The short answer
AI coding tools have made custom software meaningfully cheaper to build, but the price drop isn't uniform. It concentrates heavily in some kinds of engineering work and barely touches others. That uneven shape — not the vague claim that "AI writes code now" — is what actually explains why a wider tier of businesses can now afford software built around how they specifically operate.
Where the time savings actually land
McKinsey's research on generative AI and developer productivity breaks the gains down by task type instead of reporting one blended number, and the spread across tasks is wide:
- Writing documentation: 45–50% faster
- Writing new, well-specified code: 35–45% faster
- Refactoring existing code: 20–30% faster
- High-complexity, novel problem-solving: under 10% faster
That shape matters more than any single headline percentage. The tasks that speed up dramatically are the ones with well-established patterns — boilerplate, CRUD operations, standard integrations, test scaffolding, documentation. The tasks that barely move are the ones that require understanding a specific business's actual constraints: how a workflow should behave in an edge case, what a client's compliance requirement implies for the data model, how two particular legacy systems need to talk to each other.
What gets cheaper, and what doesn't
The routine-heavy portion of a build — the parts of custom software that resemble work done a thousand times before, just wired to a specific business's data and screens — has genuinely dropped in cost. That's most of the boilerplate in an internal dashboard, most of a standard CRUD admin panel, most of a first-pass integration against a well-documented API.
What hasn't gotten cheaper is figuring out what to build in the first place. Requirements gathering, scoping conversations, and translating "what the business actually needs" into a buildable spec are still fundamentally human work. AI tools don't materially speed this up, because the bottleneck was never typing speed — it was understanding a business well enough to make the right calls about what the software should and shouldn't do.
Why this raises the stakes on scoping, not lowers them
Because the routine-code portion of a project has compressed, the scoping and judgment portion is now a larger share of what's left — proportionally, a project now spends less of its time on typing and more of it on the decisions that shaped what got typed. That means a rushed or vague scoping conversation costs more relative to the total project than it used to — the fixed cost of getting the requirements wrong doesn't shrink just because the code got faster to write.
What this means if you're deciding whether to build
It's now realistic to consider a custom build at a price point that would have been out of reach two years ago, provided the project has real routine-heavy work in it — which most day-to-day business software does: dashboards, internal tools, workflow automation, integrations between systems that don't talk to each other today. What it doesn't mean is that scoping matters less. If anything, a properly scoped project is where more of the value now lives.
Sources:
- A coding boost from AI — McKinsey