An argument about where value moved, written from six years of building this way.
August 2026
1. The thing we were actually selling
Software was sold as a product because the product was the hard part. Not the idea — ideas were always cheap — but the crossing from a description of a program to a program that runs. That crossing took skilled people months, and it failed often, and the failures were expensive. The compiled artifact at the end was proof the crossing had been made.
Everything downstream followed from that scarcity. Licences protected the binary. Source was withheld because source shortened the crossing for a competitor. Open source was radical precisely because it gave away the expensive thing.
The economics rested on one assumption so stable nobody stated it: a sufficient description of a program is not a program. You could hand a rival your complete design and still be years ahead, because they had to make the crossing themselves.
2. The assumption broke
A competent agent, handed a sufficient description, now produces a working program. Not always, not for everything, and not without supervision — but often enough, and for a wide enough class of ordinary systems, that the assumption no longer holds where most software actually lives.
The consequence is not that programming ended. It is that the executable stopped being the scarce end of the pipeline. The crossing that used to take months is now cheap enough to redo on demand, in someone else’s environment, against their constraints.
Which raises an awkward question: if the program can be regenerated from a good enough description, what exactly is being protected by not sharing the program?
3. The claim
The route is now the artifact. The code is the destination, and a destination does not tell you how to get there.
This is the whole argument, and it rests on something specific: a finished repository is a lossy record of its own construction. Read one and you learn what survived. You do not learn:
- Order. Which piece had to exist before which other piece, and what was unbuildable until something else was true.
- The dead ends. The approaches tried before this one, and the specific way each failed. This is the most expensive thing you learn in a build, and none of it ends up in the repository.
- Why the strange parts are strange. Every mature system has code that looks wrong and is load-bearing. The reason lives outside the file.
- What done meant. The acceptance conditions the builder was actually working against — usually never written down, because the builder held them in their head.
That information is not hidden in the repository. It is absent from it — not because finishing destroys it, but because nobody writes it down. It sits in the builder’s head during the work and leaves with them. Handing someone the code and handing them the record of how it was built are not two versions of the same thing.
Call the second thing selfware: a record of the way something was built, plus the standards you can hand your agent so it knows when it has got there. That is the whole of it. Not a copy of a program, and not a spec sheet for one.
4. What a route has to carry
Most technical writing is not a route. A tutorial is a route with all the failures removed, which is precisely the part worth having. Documentation describes a finished thing from the outside. An architecture diagram is a destination drawn neatly.
A route carries four things a finished artifact cannot:
- Sequence with reasons. Not just the order, but what became possible at each step.
- The failures, kept. Named, with how each one failed. A record that reports only the things that worked is advertising.
- Standards that can fail. Concrete conditions deciding whether the rebuilt thing actually works, checkable by the agent doing the rebuilding with nobody from the original build present. This is the part everything else rests on. Without them you have a story about a build. With them you have something that can check itself somewhere its author has never been.
- Behaviour, not vendors. Infrastructure is a variable. Name the capability class — an object store, a scheduler, a key broker — not the brand. A route pinned to one vendor stops being a route the moment the reader is somewhere else.
The standards are what separate this from a prompt pack. Anyone can write instructions. The question this has to answer is: how does the reader’s agent know it got there?
5. Both halves, given away
An argument like this should hand over the thing rather than describe it. So here is one. It comes in two pieces, and you need both.
The repository. Free, open, MIT — a working build of a listening room where a reader taps once mid-chapter and talks, and every note pins itself to the passage that caused it. Fork it and you have a running thing. What you do not have is why it is shaped that way, which parts are load-bearing, or what would count as having built it correctly yourself.
The seed. Twelve fields, the wire contract, and eight standards — every one of them able to fail. This is the part carrying what the build actually cost: what has to be true, in what order, and how you know when you are done. It is not documentation of the code. It is the record of having made it, written so it survives leaving the person who made it.
What you add. The seed names no vendor, no host, no house style, because those are yours. So is the reason you came looking — your press, your questions, your readers. A seed that specified all that would produce the same thing for everybody, which is just software again with extra steps.
What your AI does. You hand it the seed and tell it what you want. It writes the code and keeps going until all eight standards pass. You are not writing it, and you are not receiving somebody else’s.
Both halves are free and both are here, because neither works alone. The repository on its own is a finished thing you can look at but not account for. The seed on its own has nothing to build against.
Both links are free and neither is a trial.
6. What this does not establish
The honest limits, stated rather than buried:
- No controlled comparison. Nobody has run the trial where matched builders receive a repository and a route and are measured against each other. Until that exists, the claim in section 3 is an argument from the structure of the artifacts, not a measured result.
- It is testimony. “This worked for me” is evidence, and it is weaker than proof. A route describes one path through one problem in one set of conditions. Some of what it teaches is specific to those conditions and will not survive the move.
- Gate quality is unproven. Acceptance conditions are the load-bearing claim of this paper, and there is no established way to grade one. A weak gate passes a bad rebuild, and neither party finds out.
- Verification is delegated. The reader’s agent judges whether the rebuild succeeded. That is a self-report, with the weakness every self-report has.
- The class is bounded. This argument is about ordinary systems assembled from well-understood parts. Where the crossing is still genuinely hard — novel algorithms, hard real-time, safety-critical work — the executable is still the scarce thing and this paper does not apply.
7. What follows
If the record is the artifact, then closed source protects the wrong thing. It withholds the code, which can now be rebuilt anyway, while the knowledge of how it was made walks out with everyone who ever worked on it.
So open the code. It was never the valuable part; it was the expensive part, and it stopped being expensive. Keep the record on purpose, because unlike the code it does not survive by accident — it only exists if somebody writes it down while the work is happening.
Software is dead in the one sense that mattered: the executable is no longer the scarce end of the work. What replaces it is not a smaller thing. It is the part that was always doing the work and never got written down.
The term selfware is borrowed, with thanks, from Future Fiction Academy, heard on one of their YouTube videos. Written from one operator’s practice. The seed in section 5 is given away in full — take it, build from it, and find out where it is wrong.