So Who Are We Building It For?
One day, while playing Battleship, I realized that I liked the game overall, but something was still missing.
I spent a little time looking online for my ideal version of Battleship, and at some point decided it would be easier to build what I wanted.
I wrote a prompt and handed it to Codex.
First run, then a prompt with feedback, another couple of iterations — and I had a working application.
Then I created an Azure account, set up a free-tier resource, and about an hour later had the application deployed and ready to play.
Clearly, the world did not need another Battleship game.
But I did.
And that turned out to be more interesting than the application itself.
Sorry, Battleship.
Other than an AI subscription for twenty dollars a month — fine, twenty-eight — and a few free evenings, almost nothing stood between a fairly trivial personal preference and a working program — and then a deployed application.
A few years ago, the thought “well, I’d do this part differently” would clearly not have been enough reason to build an entire application around it.
Now it was.
That is where this article came from.
In my first article, AI Can Write Code Faster Than I Can Trust It, I looked at AI from the developer’s side: an agent can produce code faster than I can verify it well enough to justify accepting it.
Here, I want to follow that chain one step further.
Working code does not yet mean code I am prepared to trust.
And a working application does not yet mean a product people will look for, pay for, and use.
But there is another question.
If, for some tasks, software becomes significantly cheaper to create, how much value does an idea need before it becomes rational to build it?
Because AI does not only change how much software we are capable of producing.
It may also change the minimum amount of expected value required for that software to be worth creating at all.
Implementation as a Filter
Before the current wave of AI, if I wanted to build a startup, an internal tool, or even a reasonably serious prototype, development itself was already a meaningful commitment.
I had to understand the domain, design a solution, write the code, test it, deploy it. For a commercial product, a team, money, and time tended to appear fairly quickly on that list as well.
Of course, solo developers existed long before AI.
People have always written small programs for themselves.
Open source, cloud platforms, frameworks, and ready-made libraries have been reducing development costs for years.
It is not as if this was impossible before.
But cost mattered.
The more expensive the implementation, the more expected value had to exist on the other side to justify building it.
If the potential market is a million users, spending several months on development can still be justified.
If there are ten users, the same investment becomes much harder to justify.
If there is one user, and his problem is that he slightly dislikes the existing Battleship games, development usually ends before it starts.
Yes, value is not simply a function of user count.
An internal tool for a handful of people can be far more valuable than an application used by thousands.
But the general principle is the same:
Expected value has to justify the cost of creation.
Implementation cost acted as a fairly crude economic filter.
It did not necessarily filter out bad ideas.
It filtered out ideas whose expected value was too small relative to the cost of implementing them.
AI has significantly weakened that filter.
For some kinds of tasks, it has made the holes in it much larger.
Something that once needed a mass market to justify building may now need only a niche.
Then a team.
Then one person.
And, at the limit, one specific task.
And There Really Is More Software
The most obvious conclusion is roughly this: if software becomes cheaper to create for some tasks, we will create more of it.
And that seems to be happening.
In a study by Mert Demirer, Leon Musolff, and Liyuan Yang, the researchers used data from more than 500,000 GitHub developers together with information about their use of AI coding tools.
For autonomous coding agents, they estimated a cumulative effect on coding activity of roughly +240%.
But further down the production chain, the effect drops noticeably: the number of projects increases by about 80%, releases by around 30%. An additional analysis across four major software marketplaces found an increase in new applications without a corresponding increase in their aggregate usage.[1]
That does not mean all of this new software is unwanted.
But it creates an interesting asymmetry:
Software production can accelerate much faster than software usage.
A similar signal appears in the subscription app market.
RevenueCat, citing AppFigures data, reports that the number of new subscription apps grew from roughly 2,000 per month in early 2022 to more than 14,700 in early 2026 — about seven times as many.[2]
That, of course, does not prove that AI caused a sevenfold increase.
But we know who to blame.
Nor does it prove that all those applications are unwanted.
And for some reason, this reminded me of the classic school math problem about filling a swimming pool.
Except now, it seems, we have two different pools.
In one, there is much more software that still needs to find its users.
In the other, software may not need a market at all.
Pool One: Commercial Software
There is the familiar software market.
A company builds a product for other people.
Writing a working application is not enough.
The user first has to know it exists, understand why they need it, choose it over the alternatives, trust it with their data — or at least their time — and figure out how to use it.
And if this is a business, ideally pay for it.
Then, preferably, not leave a week later.
In this segment, cheaper implementation can substantially increase supply.
If ten teams could previously build ten similar products, and those same teams can now build fifty, the amount of user attention does not automatically increase fivefold with them.
There is some evidence of this limitation.
In the Share of Attention study covering 303 users and 2,201 desktop applications, the authors found a negative relationship between the size of a user’s application set and the share of attention received by an individual application.[3]
Sensor Tower’s 2025 data shows another side of the same asymmetry: downloads across iOS and Google Play grew by 0.8%, time spent in apps by 3.8%, while IAP revenue grew by 10.6%.[4]
None of this proves a general “overproduction of software.”
But cheaper implementation does not remove the old product problems: distribution, trust, support, reliability, and retention.
Working software does not automatically become a working product.
More than that, if a demo or prototype can now be assembled in an evening, the mere fact that it exists says a little less than it used to.
The code works.
Good.
Why should anyone choose this one?
There is another side effect here as well.
When implementation was expensive, functionality that had already been built created a barrier of its own: a competitor still had to implement it, test it, and maintain it.
If AI substantially reduces that cost for certain classes of problems, “we already wrote this code” becomes a weaker moat on its own.
But only on its own.
Distribution, trust, integrations, reputation, data, support, operational history, and user habits do not disappear.
So cheaper implementation does not automatically make building better than buying.
It simply makes the choice a little less one-sided.
Pool Two: Cheap and Cheerful — Software for One
Which brings me back to Battleship.
Because the logic of overproduction applies much less cleanly to this second category.
Suppose I need, exactly once, to parse a few thousand lines in some peculiar format.
Previously, I would first look for an existing program or library.
Then try to force it to do almost what I needed.
Then curse the interface.
Then write a small script anyway.
Now I can explain the task to an agent and, an hour later, have a tool built specifically for my workflow.
It may not have a website, pricing, marketing, onboarding, a polished interface, or even a second user.
And that does not necessarily make it bad software.
It simply does not need to be a product.
I do not need to convince myself to download it — I know exactly why it exists.
I do not need to separately trust a vendor.
There is no vendor.
But I still need enough confidence in the software itself and in what the agent built, particularly when the cost of an error is high.
I do not need a universal UX.
I need an interface that makes sense to me.
And if the task disappears two weeks later, perhaps the rational thing to do is throw the tool away and never open it again.
For a serious or long-lived problem, an existing product may still often be more rational than building your own.
AI can reduce the cost of implementation very quickly.
It does not remove responsibility for the consequences at the same speed.
But for a one-off or extremely narrow task, the requirements are very different.
And that changes the economics.
Software used to need enough expected value to justify the cost of creating it.
Commercial software usually got that value from many users.
But if the cost of creation falls far enough, the minimum audience capable of justifying software can shrink as well.
mass market → niche → team → one person → one task
And as the audience shrinks, the lifetime of the software may shrink with it.
In some cases, the user stops being only a user.
The familiar chain usually runs through a company and its developers before becoming a product. For some tasks, it can now run almost directly from the user through an agent to software.
So Is This Actually Overproduction?
I am no longer sure that all the additional software being created should be called “excess.”
In one pool, the supply shock is quite real.
More and more commercial products can compete for roughly the same user attention.
Implementation gets cheaper, but discovery, trust, distribution, retention, and ownership remain.
In the other pool, almost the opposite is happening.
Lower development costs make it economical to serve demand that previously was simply not worth serving.
Not because the problem did not exist.
It was not large enough to justify the cost of development.
The world did not need another Battleship game.
The market did not need it.
Even a very small niche probably did not need it.
But I did.
And that turned out to be enough.
Perhaps that is the more important change.
For tasks where AI genuinely reduces implementation cost substantially, it also reduces the minimum amount of expected value required to make creating software rational.
Which means the same increase in the amount of software can represent two completely different things.
In some places, we really are producing more and more products competing for limited attention.
In others, it is becoming rational for the first time to create software that does not need a market at all.
So perhaps the main question is no longer whether we are producing too much software.
It is this:
What counts as sufficient reason for software to exist when the cost of creating it keeps falling?
And immediately behind that question comes another one.
A slightly uncomfortable one for me as a developer.
If users can now create some of the software they need for themselves, what exactly remains valuable in professional software development?
But that is a very different question...
P.S. Some evenings, I still play a round or two of my Battleship game.
Sources
[4] Sensor Tower — 2026 State of Mobile: AI Moves Mobile into Its Next Phase.
Top comments (0)