DEV Community: Dmitry Truhanovich

AI Can Build Software Faster Than We Can Use It

Dmitry Truhanovich — Thu, 22 Oct 2026 13:01:00 +0000

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

[1] Mert Demirer, Leon Musolff, Liyuan Yang — Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools. NBER Working Paper 35275, revised September 2026.

[2] RevenueCat — State of Subscription Apps 2026. New app launch figures sourced from AppFigures; RevenueCat dataset covers 115,000+ subscription apps and more than $16 billion in revenue.

[3] Lars Rieser, Brent Furneaux — Share of Attention: Exploring the Allocation of User Attention to Consumer Applications. Computers in Human Behavior, Vol. 126, 2022.

[4] Sensor Tower — 2026 State of Mobile: AI Moves Mobile into Its Next Phase.

AI Can Write Code Faster Than I Can Trust It

Dmitry Truhanovich — Wed, 16 Sep 2026 12:00:00 +0000

Will I still understand a project I (didn't quite) write?

A couple of years ago, I decided to build a simple application for cleaning up unnecessary folders in C# projects.

As every programmer is apparently required to write their own logger, DI container, and ORM at least once, I decided to write my own utility.

It did one fairly simple thing: found temporary bin and obj directories in .NET projects and deleted them.

AI wasn’t quite the cool kid yet, so eventually I abandoned the WinForms application. Mostly because I couldn’t be bothered to figure out how to turn it into a proper Visual Studio extension.

Then Codex arrived.

Or, more accurately, I started using it seriously.

I handed it the repository and asked it to turn the application into a proper extension.

GPT-5.2 was still a bit green and didn’t quite get there.

Not that it failed completely. It produced something. Code appeared.

But I couldn’t turn what it produced into a solid working solution, so I abandoned the idea again.

Some time later, GPT-5.4 came out. After some ritual troubleshooting, I finally managed to port the application.

The actual task, meanwhile, had barely changed.

It still deleted bin and obj.

So what now?

From that point on, I started using the same prompt — remember prompt engineering? Very 2025 — and the same instruction with every new model:

Do a code review of the project.

Every new model, at the same effort level, found a fresh list of problems.

And not just cosmetic ones.

Another P0.

P1s and P2s were never far behind.

After each review, I asked the model to fix everything.

The fix would turn into hundreds of lines of changed and newly added code.

The project became “better.”

Then the next model came out.

And found critical problems again.

And so the cycle continued.

I can think of several explanations for this:

The original code genuinely had some code smells, and several generations of models have simply been finding more and more problems in it. I don’t write bugs, obviously.
New models really are getting so much better at code review that they see things previous models simply missed. Questionable, but fine.
Some of the new problems are introduced by the previous fixes.
Models are simply getting more inventive at finding the next P0 in places where nobody saw one yesterday.

And if that is the case, the problem is no longer just the code.

It is also the process.

If you ask an AI to perform a review, it is almost required to find something worth fixing.

Preferably something “critical.”

There is also no obvious stopping condition for this loop:

review → fix → review → fix

At what point is the project good enough?

When does the next fix add less value than the complexity it introduces?

The funniest part is that the actual task has not changed this entire time.

The program still just deletes bin and obj.

The project, however, gets larger after every new review.

Where do I go from here?

By now, this small project has grown noticeably.

There is much more code, even though the actual task is still the same.

It still deletes temporary folders from C# projects.

And the issue is not just the number of lines.

The issue is me.

I still roughly know how the project works.

I know which patterns different classes follow. I roughly know where things live.

But if I had to make a substantial change manually, I would probably need to learn large parts of the repository almost from scratch.

In the past, a significant part of my mental model of a project formed naturally while I was writing it.

When you write a class yourself, you usually remember why it exists.

You remember why you implemented it that way.

You remember the alternatives you tried and discarded.

You remember where you made a compromise, and what other code is quietly holding that workaround together.

With an agent, that connection breaks.

It can produce a finished implementation in minutes.

The code already exists.

My understanding of that code does not.

And if AI really does remove the constraint on implementation speed, then in my own tiny project I have run into what is increasingly called the verification bottleneck:

The agent can produce code faster than I can verify it well enough to justify accepting it.

Which raises another question:

Do I even need to understand all of it?

We never understood every line of our systems before AI either.

I don’t know the internal implementation of the entire .NET runtime.

I don’t read the source code of every NuGet dependency.

I don’t go line by line through everything another developer writes.

We constantly work through abstractions, contracts, tests, and trust in code written by other people.

So what changes with AI?

This is where it gets more complicated.

With code written by another developer, I can at least try to recover the intent.

I can ask why they chose that particular solution, what alternatives they considered, and where they deliberately accepted a trade-off.

More importantly, I can usually try to understand their line of reasoning.

We are both human.

We have roughly similar constraints, ways of reasoning, and professional experience.

Even when I disagree with a decision, I can often reconstruct why another developer arrived at it.

With an agent, it is different.

Its internal process is fundamentally not a human line of thought that I can reconstruct from my own experience.

I can analyze the result, the prompt, the context, and the changes it made.

But I cannot treat them exactly like another developer’s decision and simply “understand what they were thinking.”

That context is also much easier to lose.

The diff stays in the repository.

The reasons why that diff ended up looking exactly the way it does may remain somewhere in the history of an agent session.

Or disappear with it.

On the other hand, if I try to understand every line of generated code, I lose a significant part of the productivity gain AI gives me.

While I carefully read several hundred lines of the latest diff, someone else will already have their agent building the next feature.

And then another one.

In the job market, they will look much faster and more productive.

But if I stop understanding generated code altogether, sooner or later I will end up owning a system that I am formally responsible for but do not actually know.

So the question of whether a developer needs to understand every line has probably become rhetorical.

Where's the Boundary?

AI can already produce code faster than I can properly read it.

So how well does a developer need to understand a repository to still genuinely own it?

Is understanding the architecture enough?

The main contracts?

The invariants?

The failure modes?

Or will there come a point when saying, “I built this feature,” means roughly the same thing as saying, “I used a library whose internals I have never read”?

In the past, authorship of code and understanding of code tended to develop together.

Now they are starting to separate.

You can get the code almost immediately.

Trust still has to be built.

And the developer is still responsible for the code the agent generates.

So perhaps the real constraint on agentic development will not be how quickly AI can write code.

It will be how quickly a human can determine what, exactly, they have enough reason to trust in that code.

Instead of a postscript

New models will keep coming.

They will keep getting smarter.

And I am quite sure the next generation of AI will once again find a critical P0 in my little project that still just deletes bin and obj.