The moat was never the software
If a product can be specified precisely enough to regenerate and check, an AI-assisted team can now rebuild it in a week. That is a narrower claim than it sounds — and it points at where the value actually sits.
In the first week of May I asked a coding agent for a streaming app. Not a mockup — the whole shape: hero banners, per-profile state, episode rows, offline downloads, a settings surface with storage and NAS configuration. Six days of prompting later there were seven workspaces and about 54,600 lines of TypeScript, with playback, an offline cache served through a service worker, a scheduled TV channel and an Android TV client that signs in by QR code.
I want to be careful about what that demonstrates, because the exciting reading is the wrong one — and the boring reading is the one with consequences.
It does not show that software engineering is solved, or that implementation has stopped being scarce in general. It shows something narrower: for a particular kind of product, the cost of producing a working substitute has fallen a long way. The interesting question is which kind, and the answer turns out to have a clean edge.
What exactly got cheap
Not “software”. A specific property of some software: it can be specified precisely enough to be regenerated, and checked cheaply enough to be corrected.
Both halves matter, and neither is about pictures. “Build me something that works like Spotify” specifies a great deal on its own — no screenshot required — because the public, observable behaviour of that product is common knowledge. A written feature list, a set of acceptance tests, or a competitor’s public API does the same job. What these have in common is that the target behaviour is already information, and information is what generation is good at. What such a sentence does not specify is the label deals, the play history, or the payout accounting — and that gap is the whole argument. I could describe what I wanted because the category is common knowledge. I could tell when it was wrong because I could run it and look.
Change either half and the economics change with it. Behaviour nobody can describe precisely — because it lives in an undocumented process, a regulator’s expectations, or twenty years of edge cases in someone’s head — does not get cheap, because you cannot state the target. And behaviour you cannot cheaply check does not get cheap either, because generation without a verdict is just faster guessing. That is exactly what happened in the same week on work that had no crisp acceptance test: it went slowly.
So the dividing line is not visible-versus-invisible. It is specifiable-and-checkable versus not — and, as we will get to, information versus permission.
The evidence is genuinely mixed
The honest version of the productivity literature is that it disagrees with itself, and the disagreement is informative rather than embarrassing.
A controlled study of GitHub Copilot found developers completing a task 55.8% faster. A 2025 randomised trial with 16 experienced maintainers on their own repositories found them 19% slower with AI assistance — while believing they had been faster. Both results are real. The first is a well-specified task with an obvious success condition. The second is exactly the case above: deep context, no crisp oracle.
Benchmarks tell a similar story once you read past the headline. OpenAI’s own 2026 analysis of SWE-bench Verified reports progress slowing — 74.9% to 80.9% over six months — and that 59.4% of an audited hard subset had flawed test cases or problem descriptions. The benchmark stopped measuring the thing before the models stopped improving.
None of this contradicts the Myflix result. It bounds it: reproduction gets dramatically cheaper inside the specifiable-and-checkable region, and roughly nowhere else.
From buildable to replaceable
Here is the step that is easy to skip, and it is the one that turns an engineering observation into an economic one.
A cheaper substitute changes nothing on its own. Software has been technically copyable for decades; that never emptied the market. What matters is whether a buyer — not a competitor with a research budget, an ordinary customer with a renewal date — can obtain an acceptable alternative and is willing to act on it. Falling build cost only reaches your pricing through someone deciding they no longer need to pay you.
So the relevant question is not “can this be built?” but “how many buyers are now in a position to have it built?” That is an empirical question about diffusion, and the answer is less dramatic than the discourse and more interesting than nothing.
Three statistics offices — the US Census Bureau, Eurostat, the OECD — land within 2.2 points of each other, at around one firm in five. Two industry surveys land sixty-four points higher. Nobody is lying: official statistics count firms, surveys count people who answered a survey about AI. Weight the same US sample by employment instead of by firm and 18% becomes 32%, which tells you where the capability is concentrated.
That concentration is the second half of the answer.
Large enterprises adopt at roughly three times the rate of small ones, and two independent official statistics — Eurostat and Ireland’s CSO — draw the same line. If cheap generation were a leveller, this gradient would be flattening. It isn’t, because using AI well needs the same things defensibility needs: data, governance, integration capacity, people.
Put the two together and you get a specific, unglamorous claim. Not every buyer can replace every vendor tomorrow. Rather: a minority of buyers, concentrated among your largest accounts, can now credibly commission a substitute for anything that is specifiable and checkable. That is enough to change a negotiation, which is where pricing actually lives.
The condition that decides it
Now we can be precise about when that pressure bites, and the tool for it is old.
Economists have modelled this since the 1990s as a switching-cost problem: a locked-in customer stays while the cost of moving exceeds the gain from moving. Klemperer’s 1995 survey is the canonical statement, and Shapiro and Varian’s Information Rules applied it to software and information goods in 1998. This is textbook material, not a new formula, and not an industry standard anyone certifies — it is the standard way the question is framed.
Written out for this case, a customer leaves when:
The left side is everything that makes leaving expensive. The right side is what they are paying, plus whatever you are genuinely worth more than the alternative. My one addition to the standard framing is to pull replica cost out as its own term, because it is the only term generative capability touches — and separating it is what makes the exposure legible.
Read the three bars in order. With replica cost high, the subscription holds comfortably. Collapse replica cost but leave real switching friction, earned trust, compliance surface and integration depth intact, and it still holds — the arithmetic barely moves. Collapse replica cost when the rest of the bar is thin, and it tips.
The uncomfortable reading of the third bar: if that is your product, the price was never being held up by the software. It was being held up by the cost of building another one. Cheap generation did not take your moat. It revealed that the moat was an accident of build cost.
What is new here, and what is forty years old
Worth separating, because almost all of the above is inherited.
Not new. That value migrates to complementary assets when imitation is easy is Teece’s 1986 result — he called it the appropriability regime, and predicted that when imitation is cheap, returns accrue to whoever controls the assets an innovation must pass through to reach a customer. That resources must be rare and hard to imitate to confer advantage is Barney’s resource-based view. That switching costs decide retention is Klemperer. That IT capability commoditises as it standardises is Nicholas Carr’s IT Doesn’t Matter, from 2003 — this argument has a twenty-year-old ancestor, and it was contentious then too.
What I am adding. Three things, and they are modest. First, identifying AI-assisted reproduction as a shift in the appropriability regime for a well-defined class of software — which converts Teece’s static observation into a directional one you can act on. Second, isolating replica cost as an independently movable term in the switching condition. Third, coding a complete application, built under observation, feature by feature, to test where the line actually falls rather than asserting it from an armchair.
What I am not claiming. No causal estimate of AI’s effect on reproduction cost. No measurement of commoditization at market level. One case study, run by the person arguing the thesis, is evidence about a mechanism — not proof of a trend.
Stop selling the screen
If the interface is the reproducible layer, then shipping only an interface is shipping only the reproducible layer.
The move is to stop treating the human-facing screen as the product boundary. An agent does not need your UI if it can call your service. The infrastructure for that arrived quickly and quietly: the Model Context Protocol for exposing tools, OpenAI’s app and plugin surface for putting them in front of users, the Agentic Commerce Protocol and Stripe’s implementation for transactions, x402 for HTTP-native machine payments, A2A for agent-to-agent coordination.
Read as a group, they describe software whose interface is no longer a page. For Myflix that would mean exposing search this user’s authorised library, resolve a playable file, check offline availability, initiate a licensed transaction — each carrying an authorisation decision the caller cannot make for itself. The same restatement works for tax filing, claims handling, procurement, booking, compliance reporting.
And this is where the specifiability line pays off. You cannot stop your interface being reproduced, because an interface is information. You can be the only party permitted to perform the action behind it, because permission is not information — it is a relationship, a licence, a contract, an accountable party. That is the asset. It was always the asset; expensive implementation just made it easy to mistake the code for the moat.
The part nobody has solved
There is a second-order problem that defensive IP cannot reach.
Generated output is worth a great deal to the people receiving it — US consumer surplus from chatbots has been estimated at $172 billion, up from $116 billion a year earlier, with mean monthly willingness-to-accept for giving up access rising from $98 to $124.50. Very little of that flows back to the documentation, code, writing and data that made the output useful. The current answer is a permission fight: licence or sue, in or out.
A better answer is boring and mechanical. Source assets publish machine-readable rights and provenance. Generation and agent-action events record their context and revenue. Attribution methods produce confidence-weighted contribution estimates. Payment rails settle a royalty or an action fee when confidence clears a threshold — and escrow or pay nothing when it does not.
This does not exist yet, and I want to be clear that I am proposing a construction rather than reporting a result. Attribution for closed frontier models is approximate at best. Provenance standards record lineage without settling rights or price. The payment primitives are real but young. The narrow claim is that every component now exists in some usable form, which makes this a market-design problem rather than a research fantasy — and a more productive place to spend effort than another round of litigation.
What this looks like in practice
Here is the thing the argument is built on. Six days of prompting, a real application — and, by the argument above, the least defensible artifact I have ever built.
Myflix: browsing, a show page, playback, then the scheduled TV channel. Everything visible here is reproducible from a description. Nothing visible here is the asset.
Watch it and the point should land without argument. Every rail, every button, every transition is describable, therefore reproducible. What is not on screen is the right to deliver the files, the user’s own library and history, credentials held outside source control, playback that stays reliable on a bad connection, and a provider boundary encoding who is allowed to fetch what. A competitor can copy a button labelled Download. Copying the right to deliver the file is a different kind of problem.
The practical version, for anyone building:
- Assume the screen is reproducible. Invest where description doesn’t reach — data you hold, rights you have, decisions you are accountable for.
- Write down your own inequality. If the only thing keeping a customer is that rebuilding is expensive, you are already exposed, and you will find out at renewal.
- Expose governed capability, not just an interface. Agents are becoming a real channel. Be callable.
- Price the action, not the access. Access is the term under attack.
I built a streaming app in a week to find out how much of it was actually the product. The answer was: the part that could not be specified — which is also the part the agent could not build.
The full argument, with the model, the case-study coding, the prior work it builds on and the sources behind every figure here, is in the paper: Software Commoditization in the AI-First Economy: From Implementation Moats to Contribution Markets. The application is Myflix.