Decommissioning Enterprise Software: AI Agents and the Collapse of the Replication Moat

By elliotsaha @ 2026-10-12T14:38 (–4)

Elliot Saha
Independent Researcher
October 2026

Abstract

I have spent the last six years building software for a living. For most of that time, one rule held: if a company bought a big piece of business software, it was stuck with it, because rebuilding that software would cost far more than just paying for it year after year. This paper is about why that rule is breaking. With an AI coding assistant that costs a few hundred dollars a month, tools that can take apart almost any program, and open models you can run on your own hardware, a single developer can now rebuild the part of a product that a business actually uses, in weeks instead of years. I walk through three real cases from October 2026, the plain economics behind them, what the law does and does not protect, why hiding how your systems work no longer keeps them safe, and who ends up controlling these tools. I am not saying software has lost its value. I am saying the industry can no longer charge people for how hard it is to leave, and the change is going to be messy.

Theses

1. For twenty-five years the business software industry charged people for how hard it was to leave, and called it the price of the product.
2. That price held up because of one fact: no customer could afford to rebuild what they were renting. That fact is no longer true.
3. One person, a few hundred dollars of tools a month, and an AI assistant can now read almost any shipped program and rebuild the part of it a business relies on.
4. What protected the industry was never really the law. Copyright covers the code itself, not what the code does. What protected it was the cost of copying, and that cost has fallen by a factor of thousands.
5. The profit margins give it away. Out of every dollar paid for business software, roughly eighty cents paid for the lock-in, not the running of the software. That is the part that is going away.
6. This is not theft and it is not the death of software. It is the end of charging for the difficulty of leaving, and almost nobody has planned for what comes after.

1. Introduction

For most of my career, the expensive part of understanding a program was a person. You needed someone who had spent years learning how to read code they did not write, often code that had been compiled down into a form meant to be hard to read. That skill was rare and slow, so most software stayed a black box to everyone except the company that made it. That is the thing that just changed.

Every time a company renews a software contract, it does a quiet piece of math. It compares the cost of staying with the cost of leaving. For as long as I have been working, the cost of leaving was always the bigger number. Leaving meant rebuilding every feature your staff used, moving years of records into something new, retraining everyone, and betting that the replacement would not get something wrong.

AI coding assistants change the second number. They do not make software free. What they do is make the slow, expensive parts fast and cheap: writing the code, checking it, moving the data, and most of all, figuring out how the thing you are replacing actually works. A small team, or one determined developer, can now take on work that used to need a funded company. Tools that read shipped software extend this to products whose inner workings used to be sealed. Open models you run yourself remove the last gatekeeper, because they answer to you and not to the company that trained them.

I want to make three claims in this paper.

1. The part of any business platform that a company actually depends on can now be rebuilt for weeks of work and a few hundred to a few thousand dollars of tools, instead of years of work and millions of dollars.
2. The legal protection around software was always thinner than the business protection. Copyright covers the exact code. It does not cover what the software does. The real lock was the cost of copying.
3. What follows is a repricing, not the end of software. The value moves away from the code and toward things the code cannot capture. But the repricing is large, it is fast, and it lands unevenly, and that is where the trouble is.

I am writing from what I can see, test, and point to: public reporting, published court decisions, and what these tools openly do. I am not going to publish a recipe for ripping off any specific product. The point here is the money and the law of a shift that is already happening.

2. The tools, in plain terms

An AI coding assistant, on a normal consumer plan of around two hundred dollars a month in 2026, reads and writes code, runs tests, talks to other systems through the command line, and keeps working across a long task. Work that used to be the output of a team is now the output of one person telling the assistant what to do.

The one I used for this paper is Claude Code, made by Anthropic. It is not the only one. Cursor, GitHub Copilot, OpenAI’s Codex, and Google’s Gemini command-line tool do the same kind of work, and new ones show up every month. What matters here is not which brand you pick. It is that they are now good enough that one person can direct them through work that used to need a whole team.

You also do not have to use any big company’s product at all. There are open tools, with names like Cline, Aider, and OpenHands, that do the same job while running against models you host yourself. And the models you can host have gotten very good. Open releases such as Qwen, Llama, DeepSeek, and Mistral now handle coding work that a year ago only the big hosted models could. I think this is the most underreported fact in the current coverage of AI. The mainstream story stays fixed on a race between a few large companies, while the free models you can run on your own hardware quietly close the gap. The day one of those is good enough to rebuild a product on its own is the day the pricing in Section 4 stops being hypothetical, and I think that day is much closer than the coverage admits. I do not think the quiet is an accident. The companies that fund a lot of that coverage, and buy a lot of its advertising, have no reason to tell you a free alternative is catching up to them.

Then there are tools that read shipped software. The one I will name, because it is open and public, is called REA, short for Reverse Engineer Anything. It connects an AI assistant to the serious analysis programs that professionals have used for years, the ones that turn compiled machine code back into something readable, along with tools for reading the code inside websites, desktop apps, and phone apps. The important part is not that these analysis programs exist. The well known ones, Ghidra and IDA, have been around for years. The important part is who can use them now. Using them well used to take years of training in how computers work at a low level. Now the assistant does that part, and the person just says what they want to know, in plain English. The hard skill moved from the person to the machine. Hiding how a system works was only ever a strong defense because, on the other side, there was a human who had to spend years learning how to look.

There is one more piece. A company like Anthropic or OpenAI can refuse to help with some of this, and that refusal has some value. But it only binds people who have to use that company’s product. Open models, ones that are roughly as capable and that you can download and run on your own machines, answer to nobody’s rules but yours. That single fact drives the money argument in Section 4, and it is why no refusal from one company can hold the line.

2.1 The tooling landscape

These are not one program. They are a stack, and each layer used to be its own career. I am listing them not as instructions, since every one is public and widely used, but to show that the whole chain, from a shipped product to a working understanding of it, can now be driven in plain language.

The change is not that any one of these became possible. Ghidra has been free since 2019. The change is that running them no longer takes years of training. The assistant holds the know-how. The person holds the intent.

[Figure: Figure 1. Every kind of shipped software can be read. An agent turns it into an understanding, and new, independent code is built from that, on the lawful side of the line.]

Every kind of shipped software now has a way in. A website sends its logic to your browser as code, which can be read back. A desktop app ships as a compiled file or a packaged bundle, which can be opened and read. A phone app ships as a package whose parts a tool can list directly. An online service exposes a set of web addresses whose shape a recorder can capture. In each case, the thing the company hands you is, in effect, the blueprint, as soon as something can read it fluently. That is what has changed. The reading is now fluent and cheap, so it is becoming ordinary rather than rare.

2.2 Doing this the legal way

There is a clear line through all of this, and it is a legal line, not a technical one. The lawful path, and the only one I am endorsing here, is called clean-room rebuilding. You use the analysis to understand how something behaves and what its file formats are, and then you write fresh, independent code from that understanding. You keep the original’s code, its compiled files, and its name and branding out of your result. This is how the public copies in Section 3 were built, and it is protected by the court decisions in Section 5. The unlawful path takes the product’s own code and just repaints it. The tools can do either one. The law treats them very differently. This paper describes where that line is, not how to cross it. What AI changed is the cost of staying on the legal side, which was always the only thing that made it too expensive to bother.

3. What already happened this year

In two weeks in October 2026, three stories showed the same thing reaching software that had looked untouchable.

Creative software. A group called ArtCraft, led by a developer named Brandon Thomas, released free, open versions of Photoshop, Premiere, Illustrator, and Lightroom, written in a language called Rust with the help of a top AI model. They describe them as clean-room rebuilds, written from scratch rather than copied. Several run right in a web browser. The coverage agrees they are early and rough. Thomas walked back a claim of full parity in a month to something measured in months, not years [1][2].

Office software. The same group shipped free versions of Word, Excel, and PowerPoint, which they call WordCraft, GridCraft, and DeckCraft, reaching an early release on October 10 and 11, 2026. They open and save real Word, Excel, and PowerPoint files, and they run on Windows, Mac, Linux, and the web. Their Excel version already handles 501 of Excel’s 523 worksheet functions and covers about 89 percent of its ribbon commands. The makers reckon it is about half ready for real work, and the Word version about sixty percent. They built it from public descriptions of the file formats and by watching how the real programs behave, not from Microsoft’s code [3]. These are working, compatible alternatives, not finished copies.

Games. On October 6, 2026, a version of Grand Theft Auto V that runs in a web browser went live, and it was taken down within hours at the request of Rockstar and its parent company [4][5]. Reporting ties that one to GTA V source code that leaked back in 2023, which makes it a different and clearly illegal case, not clean-room work. In the weeks after, Kotaku reported hundreds of games, rebuilt or decompiled with AI help, showing up in browsers [6].

These sit on a line, and that line is the whole point of this paper.

What changed is the cost, not the law. The first two were always allowed in principle. What the tools took away is the labor cost that used to make them not worth attempting.

[Figure: Figure 2. The same tools work on both sides of the legal line. AI makes the lawful side cheap. It does not move the line.] [Figure: Figure 3. The wall that protected software was the years of training needed to read it. That wall moved into the agent.]

3.1 The same pattern in my own work

I did not learn this from the news. I watched it in my own work before any of those stories broke.

The first thing I built was my own web browser. Not from nothing. I took apart how existing browsers work, the parts that drive the page and let software control it, and rebuilt a version shaped around one need: switching cleanly between a person driving the page and an agent driving it, and watching, in plain text, everything any piece of software on that page was doing. That browser is now how I let agents operate other software directly. A few years ago, building your own browser was something only a funded team attempted. I did it on my own, with an assistant, in a shape that fit exactly what I needed and nothing more.

The second thing cuts closer to this paper, and it turns on a tool the vendor ships on purpose. Salesforce, like most large business platforms, runs your data and your business logic on infrastructure it controls. It also gives developers a command-line tool, the one it ships so that teams can build on top of the platform, and that tool will export the whole thing: every object, field, and piece of automation, and the data itself, read-only, into version control that you control. I have done exactly this. Once that export sits on your side, it is a blueprint. The structure of the org, the rules that run inside it, and the shape of the records are all in plain files on your own machine. From there the rest follows the pattern in this paper. I moved a separate inventory system’s records into a model of that structure, reconciled every total against the original to the row and to the dollar, and built a working version of the parts a business actually uses, running on my own hardware with a local model instead of the vendor’s cloud. Nothing in that chain used anything the vendor did not hand me itself.

I want to be straight about where this lands, because the honest version is more useful than the triumphant one. What you get this way is a working prototype, not a finished switch-off, and in any real setting the vendor’s system keeps running next to it. What I am describing is not that you can turn a platform like that off overnight. It is that you can get the whole thing, the configuration, the data, and the behavior, onto your own side, model it, and run a working version of your slice, for a tiny fraction of what the license costs. The rest, running the two side by side, training people, and taking over the day-to-day, is ordinary work measured in weeks, not a multi-year project. The moment leaving is believable, the renewal math has already changed, whether or not anyone finishes leaving.

The part worth sitting with is how I got in. I did not break anything and I did not find a hole. I used the tool the vendor builds, documents, and tells its customers to use, the one that exists to make development on the platform easier. That same tool is a complete description of how to leave. This is the pattern under the whole paper. The instruments that large software companies created to help people build inside their products, the developer command-line tools, the export formats, the published interfaces, the documentation, are the same instruments that let one person carry the product out and rebuild it. The industry armed its own customers, because building on the platform was a large part of what it was selling. Now that reading and rebuilding have both gotten cheap, the help and the blueprint turn out to be the same thing.

3.2 Why people call this a toy, and why they are wrong

I use these tools every day, and not for demos. I have built internal systems, automation, data pipelines, and the browser and migration work above, all with an assistant in the loop. The way I built them is not special. I describe what I want, the assistant drafts it, I run it, I test it, I fix what breaks, and I go around again. That loop is how working developers already build real software. There is no separate, more serious method that “real” engineers use that I am somehow skipping. This is the method now.

Here is what I keep running into. People who are not in software look at what comes out of this and see a vibe-coded prototype. Something rough that demos well and falls over in real use. A toy. And today, often, they are half right, because the first version is rough. What they miss is the math.

A prototype and a production system are not two different kinds of thing. They are the same thing at two points on one line. The distance between them is testing, hardening, handling the odd cases, and running it against real data until it holds. That distance is ordinary work. It is the exact work developers have always done to turn a first cut into something that ships, and the assistant does that part too, at the same low cost as the rest. None of it needs a breakthrough. It needs iteration, and iteration is now cheap.

So a rough first version is not proof that this stays a toy. It is the first frame of a process that ends in a production system, built the same way, by the same loop, that any team uses. The only thing that changes between the rough version and the finished one is time and the number of times around the loop. And the only thing that changes between this year’s results and next year’s is how smart the models are, which has gone in one direction and shows no sign of stopping.

The people betting that these stay prototypes are really betting that the models stop getting better. That is the whole bet, and it is a bad one. Everything else is already in place: the tools, the method, and the way developers actually work are already production grade for well-defined problems. The only gap left is raw model capability, and that gap closes on its own, every few months, without anyone changing how they work. When someone outside the field waves off a rough demo, they are looking at one frame and calling it the whole movie. I have watched enough of these go from rough to running to know which way the frames are heading.

3.3 Testing is the other half, and agents do that too

If building got cheap and checking did not, then checking is where the real work now lives. This is the part outsiders never see, because it is not a flashy demo. It is the unglamorous work of proving the thing is right, and it is where a prototype either becomes a product or stays a toy. What I have watched change is that agents now do a large share of this part too.

Start with end to end testing. For a long time, automated testing mostly meant small checks on small pieces of code. What agents can do now is drive the actual product the way a person would: open the real screen, click through a real flow, fill in the real forms, and confirm the right thing happened at the end. Not a unit test of one function, but the whole experience, exercised like a user. The browser I built does exactly this: it lets an agent operate real software, step by step, and watch, in plain text, what the software did at each step. That means I can point it at a full workflow and have it tell me whether the workflow actually works, over and over, every time I change something.

For a rebuild, there is an even stronger move, and it is the one that makes clean-room work believable. You run the same inputs through the old system and the new one and compare what comes out. The product you are replacing becomes the thing you test against. You feed both the same data, line them up, and keep closing the gaps until they match. That is not a vague “looks right.” It is a measured agreement, number for number. In the migration I described earlier, that is exactly how I knew it was done: every total in the new system reconciled against the original, not by eye, but by comparison across the whole dataset. The vendor’s own system was the answer key.

Then there is direct testing with real people. Because building is cheap now, you can put a working version in front of actual users early, watch where they get stuck, and feed that straight back into the loop. You can also have an agent walk through the user’s journey first and find the obvious breakage before a person ever sees it. The point is that the feedback that used to take a release cycle now takes an afternoon.

Here is why this matters for the whole argument. Each behavior you test and lock down becomes part of a growing, exact definition of what the business actually needs. Over time, your test suite stops being a safety net and becomes the real specification: an executable description of the product, built up one confirmed behavior at a time. That accumulated specification is worth more than the code it checks, because it is what lets the next person, or the next model, rebuild the thing again without losing what mattered.

It also explains why the hard last stretch shrinks faster than people expect. The comparison tells you exactly what is still wrong. You can see which behaviors do not match yet, decide which of them the business actually depends on, and close those, while dropping the ones nobody uses. The gap between a rough rebuild and a production one stops being a mystery and becomes a list. And a list, worked through with cheap iteration and automated checking, is just a matter of time.

What stays human in all of this is judgment. An agent can tell you whether the new system matches the old one. It cannot tell you whether matching the old one is the right goal, or whether the experience is any good, or who is responsible when it is wrong. Deciding what “correct” means, and standing behind it, is the part that does not get automated. The typing got cheap. The responsibility did not.

4. Follow the money

The deepest moats in business software belong to products that hold decades of hard-won, specialized knowledge. Design and engineering tools like SolidWorks and AutoCAD. Simulation tools like Ansys and MATLAB. Chip design tools. Big resource-planning systems like SAP. And a long tail of narrow tools where one company owns a niche. Their defense was never only the code. It was that no customer could justify rebuilding thirty years of engineering just to get out of a license.

That defense rested on a hidden assumption: that copying the knowledge needed a matching team of experts. AI weakens that assumption. The knowledge is mostly published, in standards, textbooks, file formats, and in how the product behaves when you watch it. An AI assistant can pull that together into working software far faster than a team can.

Here is the part that matters for prices. Business software is sold as rent you pay forever: a per-person subscription, raised a little each year, justified by how much it would cost you to leave rather than by what it costs them to run it. An open model on your own hardware turns that forever-rent into a one-time purchase. A strong setup of AI hardware runs in the low hundreds of thousands of dollars, which a mid-sized engineering firm can afford, bought once.

Put the two side by side. A company paying several million dollars a year across a stack of specialized licenses could instead spend a fraction of one year’s licenses, one time, on hardware and the work to rebuild the part it actually uses. The model does not have to match the vendor on every feature. It only has to do the things that company uses, which is always a small slice of everything the product can do.

This sets a ceiling on what any software-only moat can charge. The ceiling is no longer the vendor’s price list. It is the cost of a capable model on your own hardware, spread over time, plus the work to steer it. Any vendor whose only real advantage is the software itself, and not its data, its network, its support, or who it protects from liability, now has to price under that ceiling or watch its best customers build past it.

This is where the trouble comes in. The repricing does not show up as a tidy discount. It shows up unevenly. The most capable and most heavily charged customers leave first, and those are exactly the high-margin accounts that were quietly paying for everyone else. Companies whose stock price assumes forever-rent get repriced faster than they can change what they sell. The hit lands hardest on the firms that look safest today, the ones whose pitch is that they are very good software in a field only they understand.

[Figure: Figure 4. Rent paid forever keeps climbing. A one-time cost to run your own levels off after you buy in. After the crossover, owning is cheaper. That is the ceiling on any software-only moat.]

4.1 How big the change is

The shift is easier to feel than to measure, so let me put it in rough multiples. The numbers below are illustrative, not quotes, but the sizes are the point. A change of two or three times is a cheaper tool. A change of a thousand times is a different world.

Two of these multiply together. When the cost to try falls by a thousand or more, and the number of people needed falls by ten or a hundred, the real drop in the barrier to entry is the two multiplied, somewhere around ten thousand to a million times easier to start. A moat built for the old numbers does not survive a change that size. It is the same arithmetic that turned film, music recording, and publishing from capital-heavy industries into things a teenager can do on a laptop. It has now reached the tools that run companies.

The one thing that did not get cheaper is being correct. Checking that the rebuilt system does the right thing in every odd case still costs about what it always did. So that cost now dominates. When building is thousands of times cheaper and checking is not, the whole job becomes checking. For anyone actually doing this work, that is the most important thing to understand.

4.2 Where the money actually goes

The clearest proof that business software was priced on lock-in, not cost, is the profit margin, and it is published every few months. Software companies that sell subscriptions typically keep about eighty cents of every dollar of software revenue as gross profit, after the cost of actually delivering the service, with the best of them above that [14]. An eighty percent gross margin means that out of every hundred dollars a customer pays, around twenty dollars covers the real cost of running the service, the servers, the support, the people keeping it alive, and around eighty dollars is profit on top.

That eighty dollars is what this paper is about. Not all of it ends up as net profit. These companies spend heavily on sales, marketing, and new development, which is why many of them barely break even while growing. But that is the point. The eighty percent is not the cost of making the software work. It is the cost of selling it and the return to investors: the sales teams, the brand, the shareholders. The customer is not mainly paying to run the software. The customer is mainly paying for the vendor to keep being the vendor.

A margin that high only survives behind a moat. In a normal competitive market, prices fall toward the cost of making one more unit, and margins end up in the single digits. That is where airlines and grocery stores live. An eighty percent margin held for a decade is the financial fingerprint of lock-in, of customers who could not get the same thing cheaper because copying it was not worth the cost. The margin was the moat, written as a number.

Rebuilding your own slice goes straight at that number. When a company rebuilds the part of a platform it uses, it stops paying the eighty percent and pays only the real cost: running a model on its own hardware, hosting, and its own upkeep. There is no sales line, no brand premium, no investor return baked into a system you run for yourself. The margin the vendor used to collect is not handed to a cheaper vendor. It just leaves the deal.

In round numbers: a company paying a million dollars a year for a specialized platform is, at an eighty percent margin, paying about two hundred thousand for everything it actually costs the vendor to deliver, and about eight hundred thousand for the privilege of not having built it. If that company can rebuild its slice for a one-time cost of roughly one year’s license, and then run it at the real cost, the eight hundred thousand a year is what it stops paying. That is the plain arithmetic behind the customers walking away.

The stock market has already priced that margin in, which is why this unwind is financial as well as commercial. In mid-2025, software companies above an eighty percent margin were valued at roughly seven times their yearly revenue, while those below sixty percent were valued at about three and a half times [14]. The margin is not just a cost number. It is the multiplier on what the whole company is worth. If rebuilding squeezes the margins of the most exposed vendors, it squeezes what they are worth by more than the margin alone, because the margin and the multiplier fall together. The same eighty percent that looked like a triumph for a decade is the number most at risk now, and the one the market has bet on most heavily.

4.3 Build it once, and everyone has it

Everything so far assumed each company rebuilds its own slice. The sharper version is that it only has to happen once. A clean-room rebuild is software, and software can be published. When one capable person or team rebuilds a product and puts it out for free, the way ArtCraft did with its Adobe and Office copies [1][3], the cost is paid one time for the whole market, and everyone after that pays nothing.

This changes the threat from slow erosion to a sudden drop. Rebuilding firm by firm (Section 4.2) drains a vendor one customer at a time, which is slow and gives them time to react. One free, public rebuild removes the moat for every customer at once, including the small ones who could never have built it and the non-technical ones who just download it. The cost of copying, already tiny, is then spread across everyone who ever uses it, which drives the real cost of the alternative toward zero.

Two things make this worse for the vendor than ordinary open-source competition ever was. First, the thing being released is not an independent product built from scratch over many years, the way the free office suite LibreOffice was. It is a deliberate copy of the functions of a specific paid product, made fast, aimed right at it. Second, once it is out, it cannot be recalled. A lawsuit or a takedown can chase one website, but the code is copied, forked, and mirrored, and a free license, once given, cannot be taken back for the versions already out there. The vendor is not facing a competitor it can outspend or buy. It is facing a free, permanent, self-spreading substitute for the part of its product that most customers actually use.

The thing to understand is how fast and how wide this can hit. A vendor can plan for gradual customer loss. It cannot easily plan for the week a believable free copy of its core shows up on a public code site and starts spreading. The defenses that survive are the ones that are not inside the released copy: the live data, the running of the service, the legal and compliance cover, and the new features shipped after the copy was frozen. Everything that was in the box is now, potentially, in everyone’s box.

5. What the law actually protects

Software is covered by copyright. That has been settled in the United States since a 1983 case called Apple v. Franklin, and most countries have similar rules. Canada treats programs as protected works too. The useful question is what, exactly, the copyright covers.

It covers the expression: the actual source code and the compiled code, and in some cases the detailed structure. Copying, recompiling, or sharing that code without a license is infringement. A port built from leaked source code is in this bucket.

It does not cover what the software does: the ideas, the functions, and the way you operate it. A few well-known cases make this concrete. A 1995 case, Lotus v. Borland, held that a menu of commands is a method of operation and cannot be copyrighted. A 2012 decision in Europe held that a program’s functions, its language, and its file formats are not protected. In 2021, the US Supreme Court held in Google v. Oracle that reusing part of a programming interface was fair use.

Taking software apart to make your product work with it is also expressly allowed in the major places. US courts ruled in the 1990s and 2000s that copying a program temporarily, in order to study it for compatibility, is fair use. European law allows the same for compatibility. So does Canadian law.

Three other kinds of law do the work that copyright does not.

1. Trademarks and branding. Names, logos, and a look that could confuse customers stay protected no matter how the software underneath was built. Taking a copy, stripping off the Adobe or Microsoft name, and shipping the same functions under your own name gets around the trademark, but it does nothing about the two kinds of law below, and copying the look of the interface still carries risk.
2. Contracts. Most software terms and license agreements forbid taking the product apart, and US courts have enforced those terms. A customer is bound by the terms it agreed to for as long as it stays a customer, whatever the copyright question.
3. Trade secrets. Leaked or stolen source code is still stolen, no matter what you run it through afterward. Passing a product’s files through an AI does not launder where they came from. A clean-room rebuild from public behavior is a different act from taking the original and repainting it.

The bottom line. Rebuilding your own processes from your own data is the safest ground there is. A clean-room rebuild from public specs and watched behavior is defensible, with the branding being the live risk. Taking a product’s own code and repainting it is not clean-room, and recompiling leaked source is infringement. What AI changes is not where these lines sit. It is how cheaply you can now reach the legal side of each one, and how tempting the illegal side gets when the technical gap between them shrinks.

This section is a plain summary of public court decisions, for context. It is not legal advice.

6. What this means for the industry

The moat was the cost of copying. Per-person pricing, yearly increases, paid tiers for basic features, and the friction of getting your data out are not explained by what it costs the vendor. They are explained by what it costs you to leave. When that cost falls, each of those is exposed, not for the whole product, but for each customer’s slice, which is all each customer was ever paying for anyway.

Is this a collapse? What collapses is the rent, the premium charged on top of the cost of making and running the software. What does not collapse is the work. Software still has to be specified, checked, secured, hosted, kept running, and kept correct as the business changes. That work moves in-house. It does not vanish. The better comparison than collapse is the falling price of computing itself: a steep drop, followed by people using far more of it. Companies will commission more software, not less.

What stays valuable moves to things the code cannot hold:

1. Data and networks that cannot be rebuilt from watching behavior.
2. Legal cover: certifications, audit trails, guarantees, and somebody to sue if it goes wrong.
3. Running the thing: uptime, security response, backups, being on call.
4. Being the safe, default choice to buy.
5. New features nobody has shipped yet, which cannot be copied because they do not exist to copy.

Can anyone stop it? Enforcement works on distribution: taking down a website, cutting off payments, pulling an app from a store, suing a named person. There it still bites, one site at a time. It has almost no grip on creation. No vendor can stop someone building a private copy on their own machine, and open models on your own hardware put that build beyond any company’s rules. The industry has faced this kind of thing before with music and movie piracy. It was not won by stamping out copies. It was won by making the paid product more convenient than the free one.

I want to be fair about the costs of doing this, because they are real.

1. The last ten percent is the hard part. The last stretch of a product holds most of its strange edge cases. The public copies are half to sixty percent ready after their first release. Rebuilding your slice is doable. Rebuilding the whole product is not.
2. The upkeep becomes yours. Every connection to another system, every format change, is now your cost. Without discipline, a rebuilt system rots faster than the vendor product it replaced.
3. It depends on the people who built it. A system one developer built with an assistant depends on that developer, or on documentation good enough for the next one.
4. The legal lines in Section 5 are wide but not unlimited.

For buyers, this means you now have a real ability to leave, and that alone changes the renewal conversation, even if you never leave. The first step is not a rebuild. It is a full, verified copy of your own data and a written map of what your setup actually does. For vendors, pricing that depends on how hard it is to leave will erode customer by customer, starting with the most capable. The ones who survive will charge for running the service, for the legal cover, for the data, and for new features, not for the lock-in. For developers and consultants, the scarce skill is no longer writing the code. It is knowing what the business does, describing it exactly, and proving the new system does the same thing. The job moves closer to being an auditor and an architect.

7. Security: the same tools, pointed at you

The tools that make rebuilding cheap make attacking cheap, and they point both ways. Programs that scan the whole internet for exposed services, like forgotten login pages and open file servers, have existed for years. What AI adds is speed, turning a finding into a working attack quickly, and reading the code inside websites, phone apps, and services without special training. Anything you ship to a browser or a device, a password, an internal address, a business rule, should be treated as public.

So here is the blunt question every company should now ask itself: what actually stops someone from taking apart your apps, scraping your site, and mapping your whole public footprint? The honest answer is that almost nothing stops the looking. Mapping and scraping use the public surface you already serve. Reading the code in your website, your phone app, or your service is reading what you handed the user. Taking apart a desktop program you distribute is reading your own shipped file. None of this requires breaking in, and an AI assistant now does all of it quickly, in plain English, at a cost that stops nobody. So assume your public footprint is already mapped, your front-end code already read, and anything shipped to a device already public, because proving otherwise now costs an attacker almost nothing. What stops the next step, turning that map into a break-in, is not secrecy. It is whether there is a real hole and a path to reach it. That is the only part still in your control, and it is where defense has to live now: not in being hard to understand, but in being hard to break into once understood.

The old defense of hoping attackers would not understand your systems is finished. Security people rejected that idea more than a century ago, with a simple rule: assume your opponent knows how your system works, and make it safe anyway. AI makes that rule literal, because understanding a system has stopped being the expensive step. The attack still needs a real hole, which is why layered defenses still matter while hiding the design does not: keep a full list of everything you expose, use encryption everywhere, change any secret that was ever shipped in code, require two-factor logins and least-privilege access everywhere, and watch for large data exports. You can run these same tools against your own shipped software first.

The point follows directly, and it mirrors the one for software itself. The same tools that let an attacker read and probe your systems let you read and probe them first, faster, cheaper, and more completely than any human security team could. A company that is not now turning these tools on its own code, finding what an attacker would find, and fixing it first is not holding a neutral position. It is handing a growing advantage to whoever does. The attacker already has the cheaper cost described throughout this paper. A defender who turns down that same cheaper cost keeps paying the old price for a shrinking margin of safety. Not adopting is not caution. It is watching the ground erode while the tools to shore it up sit unused.

I want to be honest about how thin the comfort of “defenders have the same tools” really is, because in practice the two sides are not symmetric at all. The attacker is one of a small, motivated group who adopt these tools fast, because getting good at them pays off directly. Defense depends on the opposite: a huge population of companies that run software without ever thinking of themselves as software companies. Manufacturers, clinics, law firms, logistics outfits, car dealerships, local governments, water and power utilities. They have software, often old, often custom, often barely maintained, and in most cases nobody whose actual job is to turn these new tools on it and look. The attacker only has to be good at this once per target. The defender has to have already adopted it across the whole organization before the attacker arrives. One side’s adoption is fast and self-selected. The other side’s is slow and uneven and depends on the least technical people in the economy moving first. So the gap does not close evenly. It widens for most companies before it ever narrows, and the ones most exposed are exactly the ones least likely to read something like this or to believe it applies to them. The symmetry is real in the tools. It is not real in who picks them up, and that difference is where most of the damage is going to happen.

8. Who controls the tools

8.1 The guardrails, and what they can and cannot do

The big AI companies increasingly refuse the worst case, taking a named product apart, stripping its name, and shipping it as your own, while they will happily discuss the economics and the legal path. That gap is itself evidence for the argument here, in two directions. It shows the companies take the ability seriously enough to guard it. And it shows the limit of refusal as a control. A rule inside a hosted product shapes who does this early and how recklessly, but it does not decide whether it can be done, because the same ability sits in open models on your own hardware with no rule in the loop. The honest reading is not that the guardrails are wrong. It is that they do not change the economic outcome. A rule at the model level buys time. It does not rebuild the moat.

This matters beyond software, because the model is becoming the place where a lot of behavior, commercial, informational, and political, gets allowed or blocked. Whoever sets the line on what a model will refuse is setting a kind of policy for everyone who depends on it. That makes who controls that line a real question about power, not a small detail of product safety.

8.2 Blocking moves to wherever the tools live

A refusal is a decision about content. When a hosted model declines a request, the company has made a judgment about what may be produced, and that judgment reaches every user at once. Sometimes that is right and necessary. It is how the worst cases get slowed down and how genuinely dangerous output gets held back. But it is also one central lever over what people can say and do, and central levers attract hands.

The open-model escape cuts both ways again. It limits any one company’s ability to block things, because a user who dislikes the line can run a model without it, and it concentrates that ability in whoever can afford the hardware. The result is a split: a filtered layer for the public, and an unfiltered layer for the well funded. Both the commercial rebuilding in this paper and the political questions here land on that same split.

8.3 Naming the thing is a political act

In 2026, control of AI became openly political in the United States, and two federal actions show what is at stake at the model level.

In July 2025, an executive order titled “Preventing Woke AI in the Federal Government” said the government would only buy AI models that met two principles it called truth-seeking and ideological neutrality, and later guidance required vendors to disclose how their models are built and tuned [8][9]. Supporters said it corrects bias. Critics, including the Electronic Frontier Foundation, said that “ideological neutrality” is itself a point of view, enforced through the government’s buying power, that pressures companies to tune their models to one administration’s liking [10]. Either way, the order confirms the model’s refusal line as something the government now reaches for.

In September 2026, another order, titled “Inaugurating The Era Of Super Intelligence,” told federal agencies to replace the term “artificial intelligence” with “super intelligence” in official use, and set a sixty-day clock to consider changing the legal definition [11][12]. The administration also called warnings about the technology a hoax and, according to the White House, cast people who use the term “artificial intelligence” as the enemy [13]. Researchers pointed out that “superintelligence” has long meant a hypothetical future system that beats humans at everything, not today’s models, and that using it for today’s systems is misleading [11].

Here is my own view, offered as an argument, not a fact. Redefining a technology by decree, and treating the people who disagree about what to call it as enemies, is dangerous no matter your politics. It does two things at once. It inflates what the technology can do today, by borrowing the name of a milestone we have not reached, while it bans the ordinary, accurate word for it. And it treats a genuine technical question as settled by the government, with anyone who disagrees recast as an opponent rather than someone to argue with. The danger is not the word. It is making the government the judge of what a technology is, and of who is allowed to call it something else, at the very moment the same technology’s refusal lines are being pulled into government purchasing rules. A government that can both say what a model may say and rename the whole field holds both ends of the same lever.

8.4 The problem with trusting the tool

There is a problem the person using these tools feels directly. The same companies that build the assistants are businesses with their own interests, investors, and partners, and the assistant is also how a lot of people now get their information. When the tool that answers your question has a financial stake in the subject of the question, its refusals and its framing are not neutral by default.

You can see this without claiming anyone is acting in bad faith, and that is the uncomfortable part, not the reassuring one. A model might decline to help document a legal migration because the request looks like a banned one. It might state an incumbent’s case more smoothly than a challenger’s, because that is what its training and its rules reward. It might be more careful about topics that touch its makers’ business relationships. None of this needs anyone to intend it. Ordinary business incentive is enough, which is worse, not better, because it means the slant is built in and permanent rather than occasional and fixable. Either way, the effect on the person relying on the tool is the same: the information you get is shaped by interests that are not yours and are not disclosed when you get it.

Field note. While researching this paper I was using Anthropic’s Claude Opus 5.5 as a writing and research assistant. In the middle of documenting a legal migration of a business’s own systems, Opus 5.5’s safeguards stopped the response and put up a message: “Opus 5.5’s safeguards flagged this session. You may be seeing this for the first time: Opus 5.5 is more capable and has stronger safeguards as a result, which can sometimes flag non-cybersecurity work.” The session stalled, showing “Waiting for API response, will retry,” and the only choices offered were to drop down to the older, less restricted Opus 4.8 or to stop. I am not going to soften what this was. A paid AI product, sold by one of the companies whose interests this section is about, blocked its own user at the moment that user was writing about the very thing the product is sold to do, and then offered a weaker version of itself as the fix. Using the tool to do the thing was allowed. Using it to write about the thing got flagged. No reason I could inspect was given, and the line that stopped the work is one I could not see and did not control. This is not a side note to the argument about control. It is that argument, happening to me, through the tool I was using. Whether any one flag is a mistake is beside the point. The mechanism exists, it is owned by a company, it can be turned up or down by that company, and it lands on the writing-about more easily than on the doing.

What I take from this is not to throw the tool away, which is neither possible nor sensible. It is to treat it like a source with its own interests: check what it tells you against original sources, prefer tools whose incentives you can see, and keep an open model available so that no single company is the only judge of what you are allowed to know or build. The same open layer that caps the price of software also keeps a second opinion available that nobody can quietly edit.

Underneath this is a deeper discomfort, and it is about knowledge. We do not currently know what we are allowed to know through these tools, because the line is invisible when you are using them. A refusal you can see. A quiet gap, a softened answer, a path not suggested, you cannot. When one system handles a large share of what a person can find out and build, and that system’s limits are set by interests it does not state in the answer, you cannot tell “there is nothing here” from “you were not shown it.” That uncertainty is new. A library does not decline to carry a book and then decline to mention that it declined. The practical defense is the same as for any single source with power over the record: check more than one, keep an unfiltered fallback, and treat a missing answer as information, not proof there is nothing there.

None of this came out of nowhere. The ability has been building for years: free professional tools for reading code since the late 2010s, steadily stronger AI models, the open model releases that broke the single-company gate, and the connecting layer that lets an assistant drive the specialist tools. What changed in 2026 is not one invention but a point where all of those were far enough along at the same time that one person could do what the start of this paper describes. The multiples in Section 4.1 are the result of a slow build, not a sudden break, which is also why there is no single policy that fixes it.

8.5 A scenario: one official way to make software

The two 2026 orders set up a method, not just a mood. The first showed that government buying can be used to set conditions on which models may be bought, and to force disclosure of how they are built and tuned [8][9]. The second showed a willingness to define the technology’s very terms by decree [11]. Carry those two forward and a sharper picture appears. It is a what-if, offered as an argument, but every step uses a lever that already exists.

Suppose an administration decides there is a correct, favored way to build software, call it a “Prosperity” approach: maybe only approved toolchains, mandated model providers, approved licenses, required logging of what gets made, or a ban on anything that competes with favored companies. It would not need to pass a law. It could:

1. Attach strings to its spending. Make federal dollars depend on vendors whose models enforce the approach, the way the 2025 order already does for “ideological neutrality.” The biggest buyer in the economy sets the standard in practice.
2. Lean on the model. Require approved models to refuse or reshape anything outside the approach, turning the refusal line from Section 8.1 into a tool of industrial policy. Because the model is increasingly how software gets written, controlling the model is controlling the means of making it.
3. Define the terms. Rename or reclassify what counts as legitimate software or legitimate AI, the way the “super intelligence” order renamed the field, so that disagreement is not just disfavored but defined as outside the category.

The money effects would be large and distorting. Companies that go along would get a hidden subsidy: guaranteed sales, an approved toolchain, protection from competitors whose software the approved models will not help build. Companies outside it would pay a tax in friction, their developers’ main tools quietly unhelpful for disfavored work. Money would flow toward going along rather than toward the best product, which is the classic waste of this kind of government capture, done through a software supply chain instead of a tariff.

The check on this scenario is the same open layer that runs through the whole paper. An approach enforced at the hosted-model level only binds people who have to use hosted models. A company with its own hardware and open models can build outside it, which both limits the control and sharpens the unfairness: the escape is available to the well funded and to sophisticated governments, not to ordinary developers or small firms. The same fact that frees a business from a vendor’s moat frees the biggest players from a government’s rules, and leaves everyone else inside them. That is the political mirror of the economic story: a loosening that protects the powerful and routes around the rest.

8.6 Why this ties back to the money

The link between the money in Section 4 and the politics here is the open layer. It is what caps the price of business software, and it is also what limits any single authority’s control over what models will produce. The same property, capable models running outside anyone’s rules on hardware a buyer owns, is at once the loosening of the software moat and the loosening of the model’s content line. You cannot cheer the first and ignore the second. They are the same fact seen from two sides. The question for the next few years is whether societies can keep the lawful, decentralizing upside of that layer while holding its harms in check, without handing a single player, a dominant company or a government, the combined power to price software, filter speech, and define the terms of the debate.

9. Where this goes next

Everything here is early. The Adobe and Office rebuilds are rough, about half to sixty percent ready for real work [1][3], and the fair counter in Section 6 is that the last stretch of a product holds most of the difficulty. The reasonable question is what happens when the models get better, and they will. If the next generation is even a few times more capable, not a hundred, the last stretch gets shorter, the checking cost that now dominates (Section 4.1) falls, and rough copies become real products. The direction is not really in doubt. Only the speed is.

So let me answer the biggest version of the worry directly. Does this end software, and does it end creative work?

It ends a business model, not an activity. What a stronger version of this removes is software sold as rent behind a wall of copying cost. That business is genuinely in trouble, and the better the models get, the faster. But software as something people make and value does not end. It flips. When building gets cheap, the world does not get less software. It gets far more of it, most of it custom, made for one company or one person for one purpose. The scarce things become knowing what to build, judging whether it is right, and owning the result when it breaks. Those are not going away. They are becoming the whole job.

Copying a tool is not the same as creating with it, and this matters most for the worry about creative work. A copy of Photoshop reproduces a tool. It does not make a single photograph. The model that can rebuild the editor still cannot supply the thing the editor exists for: something a person wanted to say. Every past drop in the cost of a creative tool, the camera, the synthesizer, desktop publishing, cheap video editing, widened creative work rather than ending it, by moving the tool from a trained few to anyone who wanted it. Cheap, plentiful tools are, historically, a friend to creative work, not its enemy. What falls is the money value of certain kinds of production labor. Who gets to make things grows.

The real danger to creative work is not plenty. It is concentration. If every image, document, and app is made through a handful of models, and those models carry the taste, the defaults, and the permissions of a few companies, or, as in Section 8, of a government’s approved approach, then the threat is not that people stop expressing themselves. It is that expression narrows, funneled through the same few filters, with the same things quietly easy and the same things quietly hard to make. A sameness in the means of making is a more believable loss than silence. This is the same fact as the rest of the paper, seen once more. The open, inspectable, owned layer is what keeps variety alive. The closed, mediated layer is what threatens it. The end of the copying moat is not the end of creativity. The capture of the creative layer would be, and that is still a choice societies get to make, not a fate the technology forces.

10. Limitations

A few honest caveats. The public copies are first releases, none has yet carried a large number of real users in daily use, and the readiness figures are the makers’ own estimates. The October 2026 cases rest on news reporting, and the claims about which AI tools were used are not independently confirmed in several of them. Section 5 is a plain summary of court decisions for context, not legal advice. And the dollar figures in Section 4 are rough, meant to show the shape of the trade, not to quote any specific product.

11. What I think

The wall that protected business software was never mainly the law. It was the cost of copying, and that cost is draining away. A company can now map, model, and partly rebuild the platforms it rents, and tools that read shipped software extend that reach from online services to the compiled products that hold decades of specialized knowledge. A capable model on your own hardware turns rent-forever into a one-time cost and caps what any software-only moat can charge.

This is not the end of the software industry. It is the end of charging for how hard it is to leave. What survives is what cannot be copied from watching behavior: data other people depend on, running the service at three in the morning, legal cover somebody is willing to carry, and the next feature. The change will not be orderly, because the customers who leave first are the ones whose payments were quietly covering everyone else.

There is a flip side for anyone who owns software too. The wall you can now walk through is also the wall that protects what you hold. A company whose position rests on a software product is watching the cost of copying that product fall for everyone else. Refusing to use these tools does not freeze the game. It just gives up the first move. The defensive play and the offensive play are the same action: map your own systems, build with the tools, and compete on the things that cannot be copied, because the alternative is to sit on a position whose value is quietly draining while the people who did adopt build past you.

The open questions are not really technical. Who keeps all these custom systems running? How are they secured? Which license terms survive tools that can read any product? The industry has time to answer, but less than its current prices assume.

References

1. Futurism, “Adobe in Trouble After Someone Reverse Engineered Adobe Creative Suite and Released It as Open Source,” Oct 2026. https://futurism.com/future-society/adobe-creative-suite-software-open-source-artcraft
2. VideoCardz, “Adobe Photoshop, Premiere and Illustrator now have AI-built open-source clones,” Oct 2026. https://videocardz.com/newz/adobe-photoshop-premiere-and-illustrator-now-have-ai-built-open-source-clones
3. Office Watch, “Free Microsoft Office Clones: WordCraft, GridCraft and DeckCraft Are Here,” Oct 2026. https://office-watch.com/2026/free-microsoft-office-clones-wordcraft-gridcraft-deckcraft/
4. Gizmodo, “Browser-Based ‘Grand Theft Auto V’ Shows How AI Is Making It Easy to Illegally Port Games to New Platforms,” 6 Oct 2026. https://gizmodo.com/browser-based-grand-theft-auto-v-shows-how-ai-is-making-it-easy-to-illegally-port-games-to-new-platforms-2000822395
5. Tom’s Hardware, “GTA V playable in browser immediately nuked,” Oct 2026. https://www.tomshardware.com/video-games/pc-gaming/gta-v-playable-in-browser-immediately-nuked-unofficial-webassembly-port-built-with-ai-gets-taken-down-within-hours-of-going-live
6. ExplainX, summarising Kotaku, “AI-Decompiled Games in Browsers: Halo, Vice City, GTA 5,” Oct 2026. https://explainx.ai/blog/ai-decompiled-game-browser-ports-halo-vice-city-black-ops-kotaku-2026
7. REA: Reverse Engineer Anything. https://github.com/morluto/rea and https://rea.tools/
8. Executive Order 14319, “Preventing Woke AI in the Federal Government,” July 2025. White House fact sheet. https://www.whitehouse.gov/fact-sheets/2025/07/fact-sheet-president-donald-j-trump-prevents-woke-ai-in-the-federal-government
9. Crowell & Moring, “In Bid to Ban ‘Woke AI,’ White House Imposes Transparency Requirements on Contractors” (OMB Memorandum M-26-04), 2025. https://www.crowell.com/en/insights/client-alerts/in-bid-to-ban-woke-ai-white-house-imposes-transparency-requirements-on-contractors
10. Electronic Frontier Foundation, “President Trump’s War on ‘Woke AI’ Is a Civil Liberties Nightmare,” Aug 2025. https://www.eff.org/deeplinks/2025/08/president-trumps-war-woke-ai-civil-liberties-nightmare
11. Forbes, “Trump Signs Executive Order Renaming AI To ‘Super Intelligence’,” 30 Sep 2026. https://www.forbes.com/sites/siladityaray/2026/09/30/trump-signs-order-renaming-ai-to-super-intelligence–heres-what-it-says/
12. CNBC, “Trump tries to rename AI ‘super intelligence’ as polls show him sinking on key issue,” 29 Sep 2026. https://www.cnbc.com/2026/09/29/trump-ai-super-intelligence.html
13. The Next Web, “President Donald Trump says anyone using the term ‘artificial intelligence’ is ‘the enemy’,” Oct 2026. https://thenextweb.com/news/trump-artificial-intelligence-enemy-super-intelligence
14. Benchmarkit and Aleph, “What’s a good SaaS gross margin? (2026 benchmarks),” and CloudZero, “SaaS Gross Margin Benchmarks.” Median software gross margin around 80 percent; company-value multiples by margin band. https://www.getaleph.com/answers/saas-gross-margin-2026 and https://www.cloudzero.com/blog/saas-gross-margin-benchmarks/ and https://softwareequity.com/blog/gross-margin-saas/