Do AI coding assistants make custom software cheaper?

They lower the cost of producing code, not the cost of owning it. Production is one line in a software budget. Review, metered tool usage, and long-term maintenance are the others, and AI assistants push cost into all three.

Why is our AI tooling bill hard to forecast?

Most assistants are priced per request rather than per seat. GitHub Copilot Pro includes 300 premium requests a month for 10 dollars and charges 4 cents for each request beyond that, and some features consume a single request at a 13x multiplier. Spend tracks usage, so it moves with activity instead of headcount.

Does AI-assisted development actually finish work faster?

Not reliably on code the team already knows. In a randomized trial run by METR, 16 experienced open-source developers took 19 percent longer to close 246 issues when allowed to use AI tools, even though they predicted a 24 percent speedup.

What should a business budget for instead of a single build number?

Three lines. A seat and metered usage line with a hard ceiling, a review capacity line for the people who approve what the assistant produces, and a maintenance line sized to the codebase you will end up owning.

AI Cut the Cost of Writing Code, Not Owning It

AI assistants cut the cost of producing code. They did not cut the cost of owning it. Tooling is now priced per request rather than per seat, so spend moves with activity instead of headcount. And in a randomized trial, experienced developers took longer with AI tools while believing they were faster. Budget for review and metering, not just for the build.

Why did the software bill stop looking like a salary line?

For two decades, a custom software budget was mostly a labor forecast. You estimated people and months, added a contingency, and the number held or it did not. The inputs were slow-moving and easy to reason about.

Assistant pricing broke that shape. GitHub's own billing documentation prices Copilot in premium requests: the Pro plan is 10 dollars a month and includes 300 premium requests, Pro+ is 39 dollars a month and includes 1,500, and requests beyond the allowance cost 4 cents each. That last clause is the important one. There is no ceiling in the pricing model, only a rate.

Multipliers make the rate harder to reason about. Each model carries a premium request multiplier based on complexity and resource usage, so a single action does not consume a single request. GitHub documents that starting June 1, 2026, Copilot code review carries a model multiplier of 13. One reviewer clicking one button spends thirteen units of a 300-unit monthly allowance.

None of that is unreasonable pricing. Compute costs money, and heavier models cost more of it. But it converts a predictable fixed cost into a consumption cost, and consumption costs behave differently in a small business. A ten-person team that adopts an assistant enthusiastically in a release week can produce a bill that looks nothing like the month before, driven by a usage pattern nobody chose deliberately.

Does AI actually make the build finish sooner?

The assumption underneath most AI software budgets is that the same scope arrives earlier. The best-controlled evidence available does not support that assumption for the case businesses most often care about.

The research organization METR ran a randomized controlled trial with 16 experienced open-source developers working on repositories they already knew well. The developers were assigned 246 real issues, each randomly designated as AI-allowed or AI-disallowed. When allowed to use AI tools, they took 19 percent longer to complete the work.

The more useful finding is the perception gap. Before starting, the developers forecast that AI would speed them up by 24 percent. After finishing, having actually been slower, they still estimated that AI had sped them up by 20 percent. The measurement and the felt experience pointed in opposite directions by roughly 40 points.

That gap is the budgeting hazard, more than the slowdown itself. Sixteen developers on mature open-source projects is a narrow study, and it does not generalize to every task. Greenfield prototyping, unfamiliar frameworks, and boilerplate generation plausibly look different. But the profile it does describe, experienced people modifying a system they already understand, is precisely the profile of maintaining internal business software. It is the work that fills years two through five of owning a custom platform, and it is the work least likely to get faster.

Where the cost actually moved

Code production was never the expensive part of software. Deciding what to build, verifying that it works, and living with it were. AI assistants compress the one activity that was already cheapest, and they add volume to the ones that were not.

Practitioners describe the shift the same way across developer forums. One widely upvoted comment on r/cscareerquestions put it plainly: "My job got harder and worse because the expected output has skyrocketed and no one is looking at everything they're pushing." Another argued that the visible quality problems come less from the tools than from organizations cutting review and quality assurance while adding AI on top. Both are anecdotes rather than measurements, but they describe a mechanism that matches the trial data: more output arriving faster than the capacity to check it.

For a business owner, the practical version is simple. If an assistant doubles how much code reaches review, and review capacity stays flat, the queue absorbs the difference. The saving shows up in a vendor invoice. The cost shows up as slower approvals, more defects reaching production, and a larger codebase to maintain than the scope justified.

What a defensible AI-era software budget looks like

Replace the single build number with three lines.

First, tooling as metered spend with a hard ceiling. Treat assistant subscriptions the way you treat cloud infrastructure: assume variability, set a monthly cap, and get alerting before the cap rather than after. Ask any vendor or partner which features carry usage multipliers, because that is where a bill goes non-linear.

Second, review capacity as a named cost. If you fund generation without funding approval, you have moved the bottleneck rather than removed it. A rough planning rule is to keep the ratio of review hours to build hours roughly where it was before adopting assistants, not lower.

Third, maintenance sized to what you will actually own. Faster production tends to produce more surface area: more endpoints, more configuration, more code paths that nobody has read closely. Scope discipline matters more when generation is cheap, not less. Our breakdown of what custom software really costs a small business walks through the full ownership picture rather than the build quote alone.

What this changes about build versus buy

The honest read is that AI narrows the gap on production and widens it on ownership. A build that was marginal on cost before is still marginal, because the part that got cheaper was never the deciding factor. What has genuinely changed is that a bad build decision is now faster to execute, which means the decision itself deserves more scrutiny, not less.

The test we apply has not moved: build when the process is a real competitive difference and no configured product fits it, buy when the process is standard and the differentiation lives elsewhere. Assistants change the speed of the answer, not the answer. When the build case does hold, our approach to SaaS platform development starts with the business constraint and the operating cost, then moves to architecture, because the second number is the one that outlives the project.

The companies that will do well here are the ones that stop asking what AI saves on the build and start asking what it changes about the five years after it.