What Changes When Code Gets Cheap

At the end of January 2026 the open-source project curl shut down its bug bounty, the program that paid outsiders for reporting security flaws. Its lead developer, Daniel Stenberg, gave the reason plainly: a flood of low-quality reports, many of them generated with AI, that the project's small security team had to evaluate one by one.

Writing a report had become nearly free. Evaluating one had not. The evaluators ran out of time first, and a program that had worked for years stopped.

That small story has the shape of what is happening to software in general. Writing code has become much cheaper, and the popular prediction stops there: software gets cheap, so everything made of software gets cheap. The prediction skips a step. Writing is one line on the bill for a piece of software. The other lines, deciding what to build, checking that it works, running it and changing it for years, fell by much less. So cheap code lowers the bar for which software is worth starting and leaves the bar for owning it almost where it was. The result is more software, more to keep alive, and a new bottleneck in the people who can check and maintain it.

Six lines on the bill

A piece of software costs money in six places.

Someone works out what it should do and writes that down precisely enough to build from: specification. Someone writes the code. Someone reads and tests it and judges whether it does the right thing safely: verification. Someone connects it to logins, data and the systems around it: integration. It has to run, be monitored and be fixed when it breaks: operation. And it has to keep changing as requirements move, dependencies update and the world shifts: maintenance.

AI coding tools act on these lines very unevenly. Writing has collapsed, and that is where all the excitement comes from. Specification got somewhat cheaper, because a model drafts a spec and a working prototype is a fast way to learn what people want, but the facts still live in people's heads and contracts. Verification got partly cheaper, because models write tests and first-pass review comments, but judging stays with a person and there is now more to judge. Integration glue is cheap; permissions, approvals and the undocumented habits of other systems are not. Operation barely moved, because someone is still accountable when it breaks. Maintenance got cheaper for mechanical edits and not for deciding what to change.

The catch is that the lines that moved least were always the big ones. Robert Glass's well-known collection of software engineering facts puts maintenance alone at 40 to 80 percent of a system's lifetime cost. Even inside the build, Fred Brooks's old rule of thumb gave only a sixth of a schedule to coding; the rest went to planning and testing. The code is the small part and the years are the large part.

One tool, before and after

Take an approval-tracking tool for an operations team. The numbers are illustrative, chosen to be plausible, so you can swap in your own.

In 2022 one engineer builds it in 30 person-days: 5 specifying, 15 writing, 5 testing, 5 integrating and deploying. Afterward it needs about a day and a half a year of operation (access requests, questions, the odd incident) and six days a year of maintenance. Over five years that is 67.5 person-days, about $47,000 at a fully loaded $700 a day.

In 2026 the person who needs the tool builds it, steering a coding agent, in two days. Operation stays the same. Maintenance halves to three days a year, because upgrades and small changes go faster.

About 2.8 times. The five-year total falls from 67.5 days to 24.5, from about $47,000 to about $17,000. Building used to be 44 percent of what the tool cost over its life. Now it is 8 percent, and running and maintaining the tool is the other 92.

Scroll sideways to see the whole figure

Now change one assumption, which is the most useful thing to do with any example like this. Suppose only the writing line falls, and specifying, testing and integrating take as long as they did in 2022. The build then takes about 15 days instead of 30, twice as cheap, and the five-year cost improves by only 1.3 times. The headline fifteenfold depends on the other lines shrinking too, and they shrink for two different reasons.

Specification and integration shrink mainly because the handoff disappears. When the person who needs the tool builds it, there is no requirements document to write, no meeting to explain it, no waiting for someone else's queue. That is an organizational change more than a technical one, and it works only when the builder already understands the problem: common for small internal tools, rare for products with many stakeholders.

Verification shrinking from five days to under one means something less comfortable. Either generated tests are standing in for careful review, or the team accepts a lower standard of checking because the tool is internal. Either can be reasonable. Either is exactly where the quality risk of the cheap build enters.

And the halved maintenance is the most optimistic number in the example. Nobody typed this code, so whoever has to change it in year three understands it less well than its author would have. There is no good measurement of that extra cost yet, so the example leaves it out, which flatters 2026.

Writing got much cheaper. Deciding, checking, running and changing the result got cheaper by much less.

Why there will be more software, not less

If each tool costs less, does an organization spend less on tools? Usually not, and the reason is more than 160 years old.

In 1865 the economist William Stanley Jevons argued that burning coal more efficiently would make England burn more coal, not less, because cheaper power made engines worth using everywhere. That is the Jevons paradox, and it has a condition people often forget: total use rises only when a lower price unlocks proportionally more demand. Where demand is already met, efficiency simply shrinks the bill.

Software is a strong candidate for unmet demand, because the jobs it could do form a long tail. Every organization has a handful of processes where a tool would pay for itself many times over, and a much longer list where a tool would barely pay back what it costs to build and keep. At 2022 prices the second list stayed a wish list.

Scroll sideways to see the whole figure

Rank every possible internal tool by what it would be worth over five years, best first, and draw a line at what a tool costs to own. With the illustrative curve in the figure, about 21 projects clear the 2022 line. When the lifetime cost falls from about $47,000 to about $17,000, about 90 clear it. Each tool is 64 percent cheaper, and total spending on tools still rises by about half. Most of the projects that newly make the cut are small.

How big that effect is depends on how fat the tail is, and nobody has measured real backlogs well. With a thin tail the number of tools still grows, but total spending falls. My bet is that internal tools and niche products have fat tails, because every organization has a huge number of small, specific jobs that nobody ever automated.

The early signs point that way, with a caution: more supply does not prove demand. App releases in the first quarter of 2026 were up 60 percent on a year earlier across Apple's and Google's stores. About a third of the builders surveyed by Retool, which sells tools for building internal software, said they had already replaced at least one bought product with something they built. Whether anyone still uses all that new software six months later is the number that would settle it.

The upkeep arithmetic

Here is the consequence most plans miss, and it falls straight out of the same example.

At the 2022 bar the organization owns 21 tools, each needing 7.5 days a year of operation and maintenance: about 158 days a year, roughly 0.7 of an engineer. At the 2026 bar it owns about 90 tools at 4.5 days each: roughly 400 days a year, about 1.7 engineers. Upkeep per tool fell by 40 percent. Total upkeep rose two and a half times.

That result does not hang on the illustrative curve. Total upkeep rises whenever the number of tools grows by more than about 1.7 times, and every plausible curve gets there. Each new tool also brings dependencies to update, credentials to rotate, data access someone had to approve, and an inventory entry someone should read.

The people who can supply that capacity are the same people already short of time for review. When agents write most of the code, the volume of changes to read multiplies. Faros AI, which sells engineering analytics, compared teams with high and low AI adoption inside the same companies in 2026. Under heavy adoption, pull requests (the proposed changes developers submit for review) were half again as large, median review time was about five times longer, and deployments per week fell by about 12 percent. Google's DORA research describes AI as an amplifier of whatever a team already does well or badly. It is the curl story at company scale: producing gets cheap, evaluating does not, and evaluating sets the pace (Where the Saved Time Goes).

Cheaper code lowers the bar for which projects are worth starting. It does not lower the bar for owning them.

So the forecast that matters is about review capacity. The limit on how much software an organization can own will be how much it can check and keep, more than how much it can write. Teams that change what review means, toward checking behavior against specifications and tests and away from reading every line, should end up owning more working software than teams that don't (Reviewing Code You Didn't Write).

What happens to software prices

It is natural to expect software prices to fall with the cost of writing code. The link is less direct than that, because selling software to one more customer always cost almost nothing. Prices tracked what customers would pay given their alternatives and the cost of switching. Cheap code changes the alternatives: it makes it cheaper to enter a market, to copy a competitor's feature and to build the thing in house.

So the pressure lands unevenly. It is strongest on products whose value is a set of features that are easy to describe and easy to leave: a form builder, a simple CRM, a workflow tool with no deep data behind it. It is weakest where the customer pays for something that did not get cheaper: data the vendor holds, a distribution channel, accumulated trust, a place in the daily workflow, and above all the operation, security and compliance of the product. A vendor spreads those costs across all its customers. A company that builds alone carries them alone, and cheap writing does not undo that economy of scale (Where the Moat Moves).

Investors have already priced the fear. Between mid-January and late February 2026 the S&P Software and Services index lost about a quarter of its value, a slide that began with Anthropic's release of Claude Cowork and continued with plugins aimed at sales, legal review and customer support. A stock price is a forecast, though. Price changes caused by cheap code have not been measured yet, and the signals to watch are discounting and customer retention among feature-heavy vendors.

The fair objection

The strongest objection says writing code was never the hard part, so making it cheap changes little. It is largely right, and Brooks supplies the arithmetic. If coding was a sixth of a project, eliminating it entirely speeds the project up by at most 1.2 times. For large systems with many stakeholders, regulated domains and long specification phases, the objection holds almost completely.

Two things survive it. First, projects are accepted or rejected against a cost bar, and the share of writing varies by project. A small tool for a well-understood job, where writing was most of the cost, can flip from not worth it to worth it even if the average project barely speeds up. The objection is decisive about how fast existing projects go and weak about which projects exist.

Second, cheap code is also a way to find out what people want. Brooks himself recommended prototyping for that. When a working prototype costs an afternoon, a team can put something in front of users and learn from their reaction, which attacks the specification line, one of the expensive ones, and not only the writing line.

What I'd do

Price five years of ownership, never the build. A fair build-or-buy comparison counts the whole life, including the person who answers when it breaks. A subscription includes operation, security patches, compliance work and features someone else decided to build. A built tool includes the year-three maintainer, the credentials and the upgrade backlog. Never set a subscription price against a build price.

Write down who gets called when it breaks in year three. Before approving any new internal tool, put a name there. If nobody will, the tool is a liability that hasn't happened yet.

Build what encodes your own process, buy what is a commodity. Build when the tool is small, follows your own way of working, has a named owner and fails cheaply. Buy when it is a commodity function, carries compliance obligations, must connect to many other systems, or depends on knowledge that changes outside your control, such as tax rules (Who Should Build It).

Invest in what survives a rewrite. A written statement of what a tool is for, tests that define correct behavior and stable interfaces between components all outlive the code behind them (Tests Are the New Specification). Code can now be regenerated in an afternoon. The decisions recorded in specifications and tests can't, and they are what make a cheap rewrite safe.

Budget for review before you add agents. A plan that doubles the code and leaves review alone is a plan to build a queue.

For small tools, cheap code makes the old question, what it costs to make, nearly irrelevant. The question that decides is what it will cost every year to keep, and who will be doing the keeping.

Check yourself

Why did a fifteen times cheaper build make five-year ownership only about 2.8 times cheaper?

Writing was one of six cost lines. Operation and maintenance barely moved, and they are now 92 percent of the lifetime cost.

Why can total upkeep rise even when each tool costs less to keep?

Cheaper tools clear the bar for many more projects, so the organization owns many more tools. Total upkeep rises whenever the number of tools grows by more than about 1.7 times.

What limits how much software an organization can own?

How much it can check and keep, which is review and maintenance capacity, more than how much it can write.