Software will no longer be written. It will be described. That changes software companies, every other company, and every due diligence.
Every large software company is a memory. Years of customer conversations, complaints, edge cases, failed releases and hard-won industry rules are buried in its code. They were safe there, because nobody but the vendor could read them. That was the moat: not the code itself, but the process knowledge frozen inside it, which nobody could thaw without the vendor.
As of this fall, it thaws. Coding agents now operate the tools of reverse engineers, probe running programs and their network traffic, and piece together what an application actually does. A single developer is taking on seven Adobe applications with AI-built alternatives, and he tests his Photoshop clone against files that Photoshop itself produced. The original supplies the acceptance criteria for its own replacement.
Before anyone dumps their Adobe stock: whoever decodes Photoshop owns Photoshop as of October 2026. He does not own the company that builds Photoshop 2027. That is where the real story begins.
Writing code has stopped being worth money
The thesis is simple, and for a lot of business models it is uncomfortable. Producing software will soon cost a few tokens. Anyone who still sells me programming work is selling me something I can generate myself for pennies.
One capability keeps its value: knowing what needs to be built. Describing your own business so precisely, settling contradictions so clearly and evolving that description so consistently that the right software can come out of it at any time. Requirements, a word that makes most executives tune out, become a company’s most valuable asset.
That holds for software companies. And it holds just as hard for every other company.
The new world has new rules, and they apply now. Whoever does not understand them will not be doing business for long. There are four shifts.
Shift 1: from product to snapshot
For incumbents, this means their code no longer protects them. Copyright still stands, but it protects the code, not the function. The Adobe case shows it: whoever can work out a product’s behavior and rebuild it with their own code does not need the protected code. The monopoly is still on the books. The cash flows from it now live only in last year’s spreadsheet.
The clone is not there yet. PhotoCraft’s own estimate is that it covers only about 45 percent of what professional users need. Whoever takes comfort in that is looking at the position and missing the slope.
The more interesting part is what the attacker does not get. He holds a snapshot: every decision up to yesterday, not a single one for tomorrow. He does not know why a rule is the way it is, which customer asked for it, or what that customer will ask for next. A clone is a photograph of the product. The product itself is a film.
So attacker and incumbent are in the same race, and neither wins it with code. The winner is whoever figures out faster what needs to be built next.
Shift 2: legacy software, from liability to source
For many companies the second shift matters more. Old software has mostly been a liability. Nobody knew exactly which rules were buried in it, and every replacement was a project where half the budget went into finding out what the old system actually does. So you kept it running and paid.
Once requirements can be recovered from old code, that math flips. At Nokia, two engineers analyzed more than 50 million lines of code in two weeks. Thought Machine and AWS have announced a solution for banks that extracts business rules from legacy systems, consolidates them and generates new implementations, tests included. The legacy estate stops being dead weight. It becomes the specification for its successor.
This hits a business model that rarely gets named out loud: fear of migration was a business model. Vendors lived off the fact that nobody got out. Service firms lived off the fact that every exit took years. From here on, that fear is just an excuse. And the customer does not even have to switch. Being able to switch is enough to kill the next price increase.
Shift 3: from code to specification
The first two shifts point to the same place. When code can be produced at will, the description of what it is supposed to do becomes the actual product. The specification is the product. The code is its byproduct.
The big misunderstanding in today’s debate is called vibe coding. Someone types a wish into a chat window, gets a pretty app and mistakes it for the future of software development. That is roughly like looking at a sketch on a flip chart and drawing conclusions about the future of mechanical engineering. Professional software production looks different, and it is only now being invented.
At its core is a living model of your own business. Not a requirements document a consultant hands over at the end of a project, outdated by the first change request, but a description that is maintained continuously. What do our terms mean? Which rules apply, and why? Where do sales, operations and finance contradict each other, and who resolved the contradiction, and how? How do we know a result is right?
Acceptance criteria are derived from this model, and only against those criteria is code generated, code that no machine gets to wave through on its own terms. What goes wrong in production does not end up in a ticket graveyard. It flows back into the model as a new question. Every loop makes the description sharper and the next version of the software better. The decision stays with people. The grunt work in between does not.
The bottleneck then no longer sits with the developers. It shows up in every company that cannot say how its own business works. One warning belongs here: whoever describes their worst process perfectly will get it perfectly automated. Requirements competence therefore also means questioning requirements before you pour them into software.
Shift 4: from off the shelf to made to measure
Standard software was always a compromise. We bent our processes to fit someone else’s product, because custom work was too expensive. Whole consulting industries make a living teaching companies how to fit into the screens of an ERP system. When production costs nothing, the reason for that compromise disappears. Custom software, for decades treated as an expensive luxury, becomes the obvious choice wherever the way you work makes a difference.
That puts an uncomfortable but logical question to every company: do I still need a software company that writes code for me? In many cases the honest answer is no. What I need is the ability to say precisely what I want, and to keep that description moving at the pace of my business. “Make or buy” becomes “describe or stay dependent.”
Whoever outsources that ability outsources the understanding of their own business. That was always a bad deal. Until now it was just the only one available.
What is left of software companies
Software companies will not disappear, but they will change. The software company of the future is a requirements company with deep domain knowledge. Its product is not code but its lead in understanding and learning: it sees across a hundred customers what no single customer sees, spots earlier than anyone else which rule is changing, and ships the answer before the customer has phrased the question.
That is a good business, just a different one. The old formula, simplified, was: build once, sell a million times, raise prices every year. The new one is: prove every month that you understand the customer’s business better than the customer does, and better than anyone who cloned yesterday’s code. There are decent margins in that, too. They just have to be earned again every month instead of being renewed with the next license letter.
For valuation, this means what counts is no longer what a software company has built, but how fast it knows what to build next. A large code base is no longer an asset. It is closer to a memento of past revenue and profit. Anyone who underwrote a software roll-up on the assumption of annual price increases should run the model once without that line.
Why this is good news
For business owners, this is the best news in decades. For the first time, software adapts to the business instead of the business adapting to the software. Differentiation, so far a privilege of corporations with their own development departments, becomes affordable for everyone. Whoever truly understands their processes can now turn them into software without chaining themselves to a vendor and its roadmap.
For investors, a new map appears, with winners on both sides: first, the software companies that rebuild themselves into the requirements engine of their domain, and second, all the other companies whose requirements competence does not yet show up in any valuation. The second group is systematically undervalued today, because nobody has it on their radar.
That is why two questions belong in every due diligence, not just for software companies. How is requirements work organized across the teams? And how fast do you learn, and how much of your customer retention is real performance and how much is just fear of leaving? And to every other company, even if the sector line says industrial machinery: can you describe your own business well enough that software can be built from it? Or do you keep buying consultants’ slide decks and licenses someone else picked for you?
Software will no longer be written. It will be described. The companies that understand this first will be the software companies of the next decade, no matter what their incorporation papers say today.
