Will Software Have Its 3D Printing Moment?
The way we get software today still looks a lot like the industrial age.
Software is designed, built, packaged, and distributed from somewhere else. It reaches users through app stores, websites, SaaS platforms, or open-source repositories. As users, we search, compare, download, install, sign up, subscribe, and then try to find the part of an already-shaped product that comes closest to what we actually need.
This model works. In fact, most of the software industry has been built on top of it.
But it also has a hidden assumption: a need has to be common enough to become a product. A user’s workflow has to be close enough to the product’s design in order to be served well.
In reality, many needs are not like that.
Someone may just want a budgeting tool that fits the way their family thinks about money. Someone else may need a tiny app that generates weekly reports in their company’s exact format. Another person may want to connect a few spreadsheets, reminders, templates, and AI conversations into one small workflow. Someone may simply want a tool that runs only on their Mac, keeps all data local, has no accounts, no cloud sync, and no complicated settings.
These needs are too specific, too personal, and too long-tail.
They do not fit neatly into the product logic of traditional software companies. But they are real.
The programming ability of LLMs is starting to create a new path for these needs.
The point is not that “AI will replace programmers.” That framing is too broad and too crude. A more precise way to say it is this: LLMs may change how some software gets made.
For small tools with clear boundaries, especially tools meant for individuals or small teams, getting software may no longer mean only downloading an app someone else has already built. It may mean describing what you want, then generating a piece of software for yourself.
This feels a bit like 3D printing.
In 3D printing, the important thing is not only the printed object. It is also the model file behind it. With the right model, material, and printer, an object can be reproduced locally.
Software may go through a similar shift.
In the past, what we distributed was the application itself. In the future, what we distribute may be a software blueprint.
But that blueprint should not be just a prompt.
A prompt is too temporary, too vague, and too easy to lose context. It can trigger one generation, but it is not a good way to preserve the long-term intent of a piece of software.
What matters more is a structured spec.
A good spec should describe what problem the app solves, what its core features are, how it should behave, what platform it runs on, how it should be built and tested, how it should be exported, and what constraints it must respect.
In other words, for some kinds of software, the unit of delivery may shift.
Instead of delivering only a finished app, we may deliver the specification, the generation process, and the verification results.
This is not just about whether AI can write code.
Code can be generated, but that does not mean the software is reliable. An app can launch, but that does not mean its behavior is correct. A feature can work once, but that does not mean the product is safe, maintainable, or distributable.
So if software is going to have a “3D printing moment,” the key will not be one-off magic. The key will be a reproducible process: from requirement to spec, from spec to code, from code to build, and from build to verification.
There is another important distinction here.
LLMs are probabilistic. Software needs to be deterministic.
A user cannot accept a budgeting tool whose data model changes every time it opens. They cannot accept a weekly report generator whose format randomly shifts from one run to the next. They cannot accept exports that behave unpredictably.
LLMs are good at generation. Software is good at running.
The value of an LLM is turning vague intent into structured output. The value of local software is that, once generated, it should behave in a stable, predictable, and repeatable way.
That is why I am more interested in locally generated small software than in temporary answers that live forever inside a chat window.
A chat is open-ended and fluid. Software needs boundaries, state, files, permissions, and build artifacts.
The truly useful thing is not asking AI the same question again and again. It is using AI to create a tool that can keep working after the conversation is over.
Of course, this will not replace all software.
Complex systems, safety-critical software, large-scale collaborative products, and infrastructure still require serious engineering, architecture, testing, and long-term maintenance. AI-generated software will also introduce new problems around security, quality, and trust.
But a large amount of personal software, long-tail tools, internal apps, temporary workflows, and vertical utilities may be redefined.
In the past, these needs were too small to be built. In the future, they may be suitable for generation precisely because they are specific.
This is the idea I am exploring with Vaela: can an ordinary user turn an idea into a local software workflow that can run, be modified, and be generated again?
For me, the important part is not how much code AI can write.
The important part is whether software can move from a one-time conversation into a blueprint that can be saved, inspected, changed, rebuilt, and shared.
That may be the most interesting part of software’s 3D printing moment.
Some software in the future may not be bought or downloaded.
It may be described, generated, verified, and rebuilt.
Software will not always flow from companies to users. It may also grow out of a user’s own language, environment, and constraints.