A user adds swimlanes to their kanban board by typing the request. They do not read source code. They do not fork a repository. They describe what they want and their LLM produces the change against their own copy of the application. Free software promised something related forty years ago: the right to modify the software you use, given source access. Few users could ever exercise that right. That capability - to modify the software you use - is being delivered, but in a different shape than expected.
The four freedoms the Free Software Foundation codified in 1986 include the freedom to study how a program works and the freedom to modify it. The mechanism free software offered for cashing those freedoms out was published source code. With access to source, in principle, any user could read the program, find what to change, change it, build the modified version, and run it. The freedom was the access; the rest was the user's job to perform.
In practice, the rest was unperformable for almost everyone. Reading unfamiliar code is hard. Modifying it correctly is harder. Building it requires toolchains, dependencies, and time. Most users of free software, including technically literate ones, never modified any of it. They used it as shipped. The political claim was that the freedom to modify mattered. The lived reality was that the freedom existed and the capability did not.
The thing that finally delivers that capability is itself not free. The frontier LLMs that make this possible are built by a handful of well-capitalized labs, on training data and infrastructure no individual user controls. None are open source in the FSF's sense — the leading models are entirely proprietary, and even the "open" ones release only weights, not training data or pipeline. Users are now free to modify their applications but are not free from the tools that perform the modification.
A second layer to the irony: open source developers themselves use these tools heavily. The community whose political project this technology fulfills is also the community that has most rapidly adopted technology built on commercially controlled foundations. That is pragmatism, but it is a strange position to occupy.
The Prompt Mechanics
The prompt-based modification surface inverts the old barrier. The user does not need access to source. They do not need to read or write code. They describe what they want — "add swimlanes," "rename this column," "make this faster on mobile" — and the LLM produces the modified application. The barrier drops from "developer with time" to "user with words." The thing free software said should be possible, but practically wasn't, is now practically possible.
But, This is not what free software argued for. Free software argued for a specific mechanism — published source — as a political guarantee against vendor capture. The prompt regime guarantees nothing politically. What it offers is a working modification capability, which is not the same thing as a free software stack, but it is what the lived experience of "I want to change how this works" actually requires.
Open source advocates can reasonably argue that this is a different victory than the one they fought for. The community development model that produced Linux, the security review enabled by openness, the licensing infrastructure that shaped industry norms — none of these come from the prompt-based modification surface. Those are the things open source uniquely accomplished. The user-modification dimension was one of the project's political claims; on that specific dimension, the technology now delivers what the political project tried and largely failed to deliver.
The Prompt Regime
This is also a category shift in what software is. Conventional software is an artifact: a thing built, packaged, signed, distributed, installed, and run. The vendor's product is the binary or the source tarball or the container image. Users acquire a copy and use it. Modification is a separate activity, performed (or not) on the side.
In the prompt regime, the canonical thing the vendor produces is shifting. It is no longer just the artifact. Increasingly, it is a description — a prompt, a manifest, a recipe — that the user's local model uses to produce the artifact instance the user actually runs. The vendor ships less than they used to. The local environment produces more.
You can think of a cooking analogy in this context - with some care. When you cook something, a recipe is a description from which you as a cook, using local ingredients in a local kitchen, produce a meal. Same recipe, different cooks, different meals. The recipe is canonical and shareable; the meal is local and consumed once. Conventional software was the meal — produced centrally, distributed for consumption. Increasingly, what we ship is the recipe.
This recipe-meal distinction maps the originator-realization distinction. Different local realizations of the same canonical description are normal in cooking and structurally inherent to prompted software. However, cooking has rough tolerance for variation; software less so. A recipe slightly off produces a slightly worse meal. A prompt slightly off can produce broken software. The shift from meal to recipe is real, but it imports requirements cooking does not face.
The Architecture Shift
The shift is already visible — rewritables, Artifacts, vibe-coded apps. You can describe this as: "software distribution is moving from artifacts to instructions.", because it tells you what is actually happening at a human level. People who could not modify the software they used can now modify it. That capability was promised to them. It just arrived from somewhere unexpected, on terms no one chose, with constraints no one designed.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.