The moat was never the software

In the first week of May I asked a coding agent for a streaming app. I didn’t want a mockup. I wanted the whole shape: hero banners, per-profile state, episode rows, offline downloads, a settings page 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 shows, because it’s easy to read too much into it.

It doesn’t show that software engineering is solved, or that implementation has stopped being scarce in general. What it shows is narrower: for one kind of product, building a working substitute has become much cheaper. The interesting question is which kind, and the boundary turns out to be fairly sharp.

What exactly got cheap

What got cheap is 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 depends on pictures. “Build me something that works like Spotify” specifies a lot on its own, without a single screenshot, because everyone knows how that product behaves. A written feature list, a set of acceptance tests or a competitor’s public API does the same job. In each case the target behaviour is already information, and information is what generation is good at. What the 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. Behaviour nobody can describe precisely doesn’t get cheap, because you can’t state the target: think of undocumented processes, a regulator’s expectations, or twenty years of edge cases in someone’s head. Behaviour you can’t check cheaply doesn’t get cheap either, because generation without a verdict is just faster guessing. In the same week, the work that had no clear acceptance test went slowly.

So the dividing line runs between what can be specified and checked and what can’t. Further down there’s a second line, between information and permission.

The evidence is mixed

The productivity literature disagrees with itself, and the disagreement tells you something.

A controlled study of GitHub Copilot found developers finishing a task 55.8% faster. A 2025 randomised trial with 16 experienced maintainers working on their own repositories found them 19% slower with AI assistance, even though they believed they had been faster. Both results hold up. The first task was well specified, with an obvious success condition. The second is the case described above: deep context and no clear way to check.

Benchmarks say something similar once you read past the headline. OpenAI’s own 2026 analysis of SWE-bench Verified reports progress slowing, from 74.9% to 80.9% over six months, and found that 59.4% of an audited hard subset had flawed test cases or problem descriptions. The benchmark stopped measuring the right thing before the models stopped improving.

None of this contradicts the Myflix result. It puts limits on it: reproduction gets much cheaper inside the specifiable-and-checkable region, and hardly anywhere else.

From buildable to replaceable

A cheaper substitute changes nothing on its own. Software has been technically copyable for decades, and that never emptied the market. What matters is whether a buyer can get an acceptable alternative and is willing to switch. By buyer I mean an ordinary customer with a renewal date, not a competitor with a research budget. Lower build costs only reach your pricing when someone decides they no longer need to pay you.

So the question isn’t “can this be built?” It’s “how many buyers are now in a position to have it built?” That’s a question about diffusion, and the data is more interesting than either the hype or the dismissals suggest.

Three statistics offices (the US Census Bureau, Eurostat and the OECD) land within 2.2 points of each other, at about one firm in five. Two industry surveys land sixty-four points higher. The gap comes from what they count: official statistics count firms, while 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 shows where the capability is concentrated.

That concentration is the other half of the answer.

Large enterprises adopt AI at roughly three times the rate of small ones, and two independent official sources, Eurostat and Ireland’s CSO, show the same gradient. If cheap generation levelled the field, the gradient would be flattening. It isn’t, because using AI well needs the same things defensibility needs: data, governance, integration capacity and people.

Together that gives a specific and fairly modest claim: a minority of buyers, concentrated among your largest accounts, can now credibly commission a substitute for anything that is specifiable and checkable. That’s enough to change a negotiation, and negotiations are where prices get set.

The condition that decides it

The tool for deciding when that pressure bites is old.

Economists have modelled this since the 1990s as a switching-cost problem: a locked-in customer stays as long as the cost of moving exceeds the gain from moving. Klemperer’s 1995 survey is the standard reference, and Shapiro and Varian’s Information Rules applied it to software and information goods in 1998. The formula is textbook material. Nobody certifies it as an industry standard; it’s simply the usual way to frame the question.

Written out for this case, a customer leaves when:

$$\text{replica}+\text{switching}+\text{trust}+\text{compliance}+\text{integration}<\text{price}+\text{value premium}$$

The left side is everything that makes leaving expensive. The right side is what the customer pays, plus whatever you’re really worth over the alternative. My one addition to the standard framing is to pull replica cost out as its own term. It’s the only term generative capability touches, and separating it makes the exposure visible.

Take the three bars in order. With replica cost high, the subscription holds comfortably. Collapse replica cost but keep real switching friction, earned trust, compliance work and deep integration, 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’s your product, the price was held up by the cost of building another one more than by the software itself. Cheap generation showed that the moat was partly an accident of build cost.

What is new here, and what is forty years old

Most of the above is inherited, so it’s worth saying which parts.

Not new. Teece showed in 1986 that value migrates to complementary assets when imitation is easy. He called it the appropriability regime and predicted that, when imitation is cheap, returns go to whoever controls the assets an innovation has to pass through to reach a customer. Barney’s resource-based view says resources must be rare and hard to imitate to give an advantage. Klemperer showed that switching costs decide retention. Nicholas Carr’s IT Doesn’t Matter argued in 2003 that IT capability commoditises as it standardises, so this argument has a twenty-year-old ancestor, and that one was contentious too.

What I’m adding. Three modest things. First, treating AI-assisted reproduction as a shift in the appropriability regime for a well-defined class of software, which turns Teece’s static observation into a directional one you can act on. Second, isolating replica cost as a term in the switching condition that can move on its own. Third, building a complete application under observation and coding it feature by feature, to test where the line falls instead of asserting it from an armchair.

What I’m not claiming. There’s no causal estimate of AI’s effect on reproduction cost, and no measurement of commoditization at market level. One case study, run by the person arguing the thesis, is evidence about a mechanism. It doesn’t prove a trend.

Stop selling the screen

If the interface is the reproducible layer, then shipping only an interface is shipping only the reproducible layer.

So stop treating the screen people look at as the boundary of the product. An agent doesn’t need your UI if it can call your service, and the infrastructure for that arrived quickly: 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 of it for transactions, x402 for machine payments over HTTP, and A2A for coordination between agents.

Taken together, 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 and initiate a licensed transaction, each with an authorisation decision the caller can’t make for itself. The same works for tax filing, claims handling, procurement, booking and compliance reporting.

This is where the specifiability line pays off. You can’t stop your interface from being reproduced, because an interface is information. But you can be the only party allowed to perform the action behind it, because permission comes from a relationship: a licence, a contract, an accountable party. I think that has always been the real asset, and expensive implementation made it easy to mistake the code for the moat.

The part nobody has solved

There’s a second-order problem that defensive IP can’t reach.

People value generated output highly. US consumer surplus from chatbots has been estimated at $172 billion, up from $116 billion a year earlier, and mean monthly willingness-to-accept for giving up access rose from $98 to $124.50. Very little of that flows back to the documentation, code, writing and data that made the output useful. Today the answer is a fight over permission: license it or sue, in or out.

A better answer is mechanical. Source assets publish machine-readable rights and provenance. Generation and agent-action events record their context and revenue. Attribution methods produce contribution estimates weighted by confidence. Payment rails settle a royalty or an action fee when confidence clears a threshold, and hold the money in escrow or pay nothing when it doesn’t.

None of this exists yet, and I’m proposing a design, not 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. My narrow claim is that every component now exists in some usable form, so this is a market-design problem rather than a research fantasy. It’s also a better use of effort than another round of litigation.

What this looks like in practice

This is the application the argument rests on. Six days of prompting produced a real app, and by the argument above it’s the least defensible thing I’ve ever built.

Every row, button and transition in that video can be described, so all of it can be reproduced. What isn’t on screen is the right to deliver the files, the user’s own library and history, credentials kept outside source control, playback that stays reliable on a bad connection, and a provider boundary that encodes who may fetch what. A competitor can copy a button labelled Download. Copying the right to deliver the file is a different problem.

If you’re building something:

• Assume the screen can be reproduced. Invest where a description doesn’t reach: data you hold, rights you have, decisions you’re accountable for.
• Write down your own inequality. If the only thing keeping a customer is the cost of rebuilding, you’re already exposed, and you’ll find out at renewal.
• Expose governed capability, not just an interface. Agents are becoming a real sales channel. Make yourself 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 the product. The answer: the part that couldn’t be specified, which is also the part the agent couldn’t 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.