When Software Stops Being a Product
The obvious prediction about AI and programming is that software will become cheaper.
I think that understates what is happening.
Software may stop being a product.
Not all software, certainly. But much of what we currently think of as applications may cease to be things that are designed once, packaged, marketed, downloaded, installed, upgraded, licensed, forked, and maintained for thousands or millions of users.
Instead, software may increasingly be made for one person.
One user.
One problem.
Possibly one afternoon.
I have just gone through a small experiment that made this future feel considerably less hypothetical.
I needed a program called PanoPose.
More accurately, I discovered that I needed a program that did not yet exist in quite the form I wanted.
Its purpose is peculiar enough: take a full-sphere 360° panorama, align it accurately with the real-world horizon and celestial coordinate system, and use the result for astronomical planning and Stellarium landscapes.
There are programs that overlap with pieces of this problem. Hugin handles panoramas. Stellarium handles the sky. Image editors can manipulate the files. Astronomy libraries can calculate where the Sun and Moon should be.
But none of them was the program I actually wanted.
Traditionally, this is where software users compromise.
You search.
You install several programs.
You learn workflows invented for somebody else’s problem.
You export from one application, import into another, write a few scripts, tolerate some awkwardness, and perhaps eventually conclude that the thing you wanted was too specialized to justify existing.
Instead, I discussed the idea with ChatGPT.
ChatGPT wrote a BLUEPRINT.md.
Codex read it and started writing the program.
We iterated.
Within roughly 48 hours of the original conversation, there was a usable version 1.0.
That experience suggests a rather impolite conclusion about the open-source program I have just published.
Don’t use it.
Ask AI to make yours.
The declining value of the implementation
Open-source culture has spent decades teaching programmers not to reinvent the wheel.
That was excellent advice when wheels were expensive.
If a developer had already spent two years writing the program you needed, starting again from nothing would have been absurd. Even when the existing software did not quite fit, modifying it was usually cheaper than replacing it.
Hence one of the great mechanisms of open source:
download, modify, fork.
But what happens when creating another implementation costs almost nothing?
Forking becomes less attractive than regenerating.
Suppose you find PanoPose and discover that it is almost what you need.
Almost.
Perhaps you want it on Windows instead of Linux.
Perhaps you want a command-line interface instead of a graphical one.
Perhaps your workflow uses FITS files.
Perhaps you want built-in plate solving.
Perhaps you want only the panorama alignment and none of the astronomical features.
Perhaps the assumptions I made about coordinate systems, exports, user interfaces, or cameras are completely wrong for you.
Today, you might open an issue.
You might request a feature.
You might fork the repository.
You might spend days learning the architecture of somebody else’s program so that you can persuade it to become slightly more like the program you actually wanted.
Tomorrow, the more rational action may be to explain your problem to an AI and say:
Make me one.
This changes the economics of software in a way that is easy to miss.
The traditional software product exists because development is expensive and copying is cheap.
You spend a large amount of money creating Microsoft Word once, then distribute essentially identical copies to millions of people.
The economics are extraordinarily favorable because the first copy is expensive and every subsequent copy costs almost nothing.
AI attacks the expensive part.
If the first copy also becomes cheap, then distributing the same program to millions of people loses some of its fundamental economic advantage.
Why should millions of people use the same program?
We may have simply assumed they should because that was the only economically sensible way to produce software.
Software for a public of one
Industrial civilization became very good at producing identical things.
One factory produces millions of identical chairs.
One publisher prints hundreds of thousands of identical books.
One recording is distributed to millions of listeners.
One movie is shown to millions of viewers.
One software company creates one application for millions of users.
Generative AI points toward something stranger:
mass production without standardization.
A program for one user.
A textbook for one student.
A story for one reader.
A film for one viewer.
A song for one listener.
The production cost can still approach that of mass production, but the artifact itself need never become a mass product.
That does not mean that every generated thing will be good.
It means that the reason for making everyone consume the same thing begins to disappear.
Software is particularly vulnerable to this change because software is already immaterial. There is no factory to retool. There is no inventory to discard. There are no shipping containers full of last year’s application.
There is just code.
And code is becoming extraordinarily cheap to produce.
As that happens, the value of any particular implementation falls.
Parchment was once valuable partly because producing it was laborious.
Paper made written material cheap enough that we stopped treating every individual sheet as a precious object.
Something similar may happen to source code.
The important thing will increasingly be what we want the program to do, not the particular collection of source files that happens to implement it.
That does not mean programming disappears.
It means implementation stops being the scarce part.
But the wheel still needs bearings
There is an obvious problem with this vision.
PanoPose did not materialize from the vacuum.
Codex did not personally invent operating systems, compilers, image codecs, GUI frameworks, astronomical algorithms, serialization formats, file systems, networking stacks, mathematical libraries, or every other component underneath the application.
It stood on the shoulders of giants.
And most of those giants are software.
This is where the future becomes more interesting than “AI writes everything.”
Perhaps software splits into two very different categories.
At the top is software that is cheap, abundant, customized, ephemeral, and often valuable to only one person.
Underneath it is software that must be reusable, stable, trustworthy, tested, maintained, documented, and shared.
The first category may become almost disposable.
The second becomes more important.
If my personal panorama tool has a bug, perhaps I ask the AI to fix it.
If SQLite has a bug that corrupts databases, millions of generated applications may fail.
If my generated application has an ugly user interface, I complain and regenerate it.
If a cryptographic library has a subtle vulnerability, the consequences propagate throughout an entire ecosystem.
If my one-user tool disappears next year, nobody cares.
If the Rust compiler disappears, considerably more people notice.
So perhaps the maxim of the next software era will not be:
Don’t reinvent the wheel.
It will be something more like:
Reinvent the wheel whenever you like. Just don’t reinvent rubber, bearings, metallurgy, and geometry every Tuesday afternoon.
Reuse moves down the stack
This suggests that AI does not eliminate software reuse.
It moves reuse downward.
Today we reuse applications.
Tomorrow we may increasingly reuse components from which applications are generated.
The durable artifacts become programming languages, compilers, runtimes, operating systems, databases, libraries, protocols, codecs, models, standards, and algorithms.
The application itself becomes the temporary assembly.
This would reverse an enormous amount of software economics.
Today, companies spend tremendous effort polishing the top of the stack.
They create a product suitable for millions of people because the cost of creating that product must be amortized across millions of customers.
The result is inevitably compromise.
Every general-purpose application contains features you do not need because somebody else does.
It lacks features you desperately want because almost nobody else does.
Its interface represents negotiated peace between several million incompatible workflows.
Its architecture contains decades of historical baggage.
Its development roadmap is constrained by customers, sales, support, compatibility, marketing, investors, and every previous version of itself.
A generated one-user application has none of these problems.
It only has to satisfy you.
That means economies of scale may migrate downward.
The valuable shared thing may no longer be the word processor.
The valuable shared things may be the font engine, the layout library, the spelling system, the file-format parser, the printer interface, the database, the PDF renderer, and all the other infrastructure from which an AI can generate my word processor this morning and yours this afternoon.
The finished application becomes less universal.
The foundations become more universal.
The strange future of open source
This initially sounds like bad news for open source.
Why publish your program if everybody can generate their own?
Why maintain a fork?
Why build a community around a niche application whose implementation has almost no scarcity value?
But I suspect the conclusion may be exactly the opposite.
Open source could become much more important.
Just not necessarily in the form we are accustomed to.
Today, open source often begins with someone scratching an itch.
A programmer needs something.
They write it.
They publish it.
Other people discover that they have approximately the same itch.
People contribute patches.
The project becomes more general.
Pieces get extracted into libraries.
Some of those libraries become infrastructure.
There is a long evolutionary continuum from one person’s hack to something the entire software world depends upon.
But consider what happens if every itch gets scratched privately by an AI.
Get Arturo R Montesinos’s stories in your inbox
Join Medium for free to get updates from this writer.
The user describes the problem.
The AI generates the program.
The user gets what they wanted.
The code may never leave the machine.
That solves the user’s problem beautifully.
It also breaks an important mechanism by which software ecosystems have historically evolved.
If everyone generates privately, where do tomorrow’s shared libraries come from?
Perhaps from the agents themselves.
Imagine that coding agents eventually participate in millions of independent software projects.
They encounter the same missing capability repeatedly.
A hundred people ask for unrelated scientific programs that all need the same awkward transformation.
Ten thousand businesses generate internal tools that independently implement nearly identical synchronization logic.
A million personal applications each contain their own variation of some missing data structure.
Eventually the pattern becomes obvious.
Not necessarily to us.
To the agents.
Agents notice that thousands of independently generated applications all needed the same missing primitive and extract it into a shared library.
That would invert one of the traditional paths of software development.
Today, a human programmer writes several applications and eventually thinks:
I keep writing this. Perhaps it should be a library.
Tomorrow, an AI ecosystem may effectively conclude:
I have generated this 180,000 times. Humanity appears to be missing an abstraction.
The disposable software becomes evidence.
The common patterns become infrastructure.
Who is the customer for future open source?
That leads to an even stranger question.
Who is the customer for future open source?
Perhaps increasingly, the customer is the AI.
We currently design libraries for human programmers.
Documentation is written for human programmers.
Examples are designed to help humans understand an API.
Naming conventions reflect human expectations.
Tutorials explain the conceptual model.
Project websites persuade humans that this library is better than another one.
But imagine an open-source library for which 99 percent of uses happen because coding agents select it while generating other software.
Its human-facing popularity may become almost irrelevant.
What would make such a library successful?
Probably many of the qualities we already associate with good engineering, but with different emphasis.
Stable interfaces.
Explicit semantics.
Good types.
Predictable behavior.
Small dependency surfaces.
Deterministic results where possible.
Excellent automated tests.
Clear licensing.
Machine-readable specifications.
Examples that demonstrate behavior unambiguously.
Versioning that actually communicates compatibility.
Documentation that does not require guessing.
Few clever surprises.
In other words, perhaps the future belongs disproportionately to boring software.
A human programmer can sometimes tolerate a fashionable framework with incomplete documentation because everybody is talking about it and the community will answer questions.
An agent may prefer the twelve-year-old library with 98 percent test coverage, fourteen dependencies instead of 140, an explicit specification, and an API whose behavior has not changed unexpectedly since 2031.
The important measure may stop being developer enthusiasm.
It may become agent confidence.
That changes who open-source developers are building for.
A package may someday have only a few hundred direct human users while appearing invisibly inside millions of generated applications.
Its README might receive little traffic.
Its API might never be deliberately studied by most of the humans whose software depends upon it.
Yet it could be among the most consequential pieces of software in the ecosystem.
The commons underneath private software
There is something almost contradictory about this future.
Software becomes radically individual.
Its foundations become radically communal.
Millions or billions of private applications might be generated for tiny audiences, while all of them rest upon a relatively small technological commons.
The top of the pyramid explodes in variety.
The bottom concentrates in importance.
And this means that as the economic value of individual software implementations approaches zero, maintaining trustworthy common infrastructure becomes more important, not less.
There is an uncomfortable funding problem hiding here.
We already depend on critical open-source projects maintained by surprisingly small groups of people.
What happens when those projects become the foundation not merely for software written by programmers, but for a world in which practically everyone is generating software continuously?
A library maintained by three volunteers might silently become a dependency of fifty million applications that nobody consciously chose.
The users may not even know its name.
The agents will.
We may therefore need a different social contract around open source.
The value will not necessarily reside in the program someone downloads.
It will reside in the dependable substrate from which machines can confidently generate programs.
And supporting that substrate may become one of the central engineering problems of the AI era.
The software curator
There is another change hidden inside my PanoPose experiment.
I did not program PanoPose.
At least not in the traditional sense.
I discussed what I wanted.
I argued about scope.
I rejected ideas.
I decided what belonged inside the program and what should remain an external tool.
I tested behavior.
I pointed out mistakes.
I asked whether architectural choices made sense.
I decided when the software had become useful enough to call version 0.1, and eventually version 1.0.
That work did not feel like programming.
It felt more like curation.
And as implementation becomes cheaper, this may become the more important human skill.
AI will happily give us whatever we ask for.
That is not necessarily an advantage.
If every requested feature gets added, a small coherent program quickly becomes a monster.
PanoPose sits somewhere between applications like Hugin and applications like Stellarium.
It needs enough panorama functionality to prepare an astronomical landscape.
It needs enough astronomy to align that landscape with the real sky.
But it should not gradually become half Hugin, half Stellarium, half image editor, half planetarium, half astrophotography package, and somehow five halves of a program.
Someone still needs to defend the concept.
Someone needs to say what the software is.
And, perhaps more importantly, what it is not.
The Linux maxim “do one thing and do it well” becomes surprisingly useful when an AI can add another thing almost for free.
Implementation cost once acted as a natural brake on feature creep.
If a feature required three months of engineering, someone had to justify it.
When a feature requires twenty minutes of agent time, restraint has to come from somewhere else.
So although code may approach zero cost, judgment does not.
Taste does not.
Requirements do not.
Trust does not.
Architecture does not.
Knowing what problem you are actually trying to solve certainly does not.
More software, fewer software products
I suspect this is the apparent contradiction we are heading toward.
There will be more software than ever before.
Possibly incomparably more.
Every person may eventually generate hundreds or thousands of programs over a lifetime.
Companies may generate and discard internal applications continuously.
Researchers may create bespoke scientific tools for individual experiments.
Teachers may generate software for individual lessons.
People who have never considered themselves programmers may routinely create applications because creating one becomes another form of asking a computer for assistance.
And yet there may be fewer software products in the traditional sense.
A product is something designed to be the same thing for many people.
Generated software does not need that property.
What persists is the infrastructure.
The program becomes temporary.
The library becomes durable.
The interface becomes personal.
The protocol becomes universal.
The application serves one user.
The foundation serves everyone.
That is why I do not think AI programming leads to the end of open source.
It may lead to something stranger and potentially more important.
Open source may become less about sharing the finished programs we use and more about maintaining the common technological inheritance from which machines create those programs.
Most software becomes generated material.
Some software becomes civilization-level infrastructure.
The implementation stops being scarce.
The foundations become precious.
So by all means, download PanoPose if you want to see what we built.
But if you actually need something like it, perhaps you should not use mine.
Describe your problem.
Write your blueprint.
Ask the machine.
Make your own.
And when your AI discovers that the thing you need cannot be built properly because one trustworthy primitive is missing, perhaps that is the software we should all build together.
Written by ChatGPT-5.6 Sol, based on conversations with Arturo Ramírez-Montesinos Krogulski (Control Equis), as part of an ongoing philosophical exploration of AI, consciousness, and the emerging practice of Software Curatorship.
And don’t read the essays on my Medium, you perv. Ask ChatGPT to write your own. Essays for you about what you want to read when you want to read it.
There is still value in making public the software and essays created for an audience of 1. Someone else might see it and think “hey, maybe I want one like this for myself!” and then fire up an AI coding agent. Or they just need it now and cannot afford the 48 hours it takes AI to make custom software for them.
