Why the AI Wrapper Insult Became the Laziest Argument in Software

Wrapper is the standard dismissal for any product built on a foundation model. It is deployed as though it settles a question, and it settles nothing. Every application in the history of software has been built on infrastructure it did not create, and the interesting question has never been what a product is built on. It is whether anyone else can build the same thing and win.

Where the word comes from

The term describes a product that calls a foundation model API and presents the result through its own interface. Used descriptively, it is accurate about a great many products.

Used as an insult, it carries an implied argument: that the company adds nothing, that the model provider could replicate it trivially, and that the valuation is therefore unjustified.

That argument is sometimes correct. It is applied indiscriminately to companies where it is obviously wrong, which is what makes it lazy rather than merely harsh.

What the insult gets wrong

Every application is a wrapper

Software has always been built on infrastructure the builder did not create. A database is a wrapper around a filesystem. An application is a wrapper around a database. A cloud application is a wrapper around someone else's servers.

Nobody dismissed a company for being built on a database, because the question was never what it was built on. It was whether the thing built was worth using and hard to replicate.

The input is the least distinguishing part

Model access is available to every competitor on similar commercial terms. That makes it the one component of an AI product that provides no advantage whatsoever.

Pointing at the commodity input as though it were the product is an odd analytical move. It would be like assessing a restaurant by noting that it buys its ingredients.

The evidence points the other way

Companies routinely described as wrappers have reached revenue and valuations that wrappers are not supposed to achieve. Harvey reached an $11 billion valuation on roughly $190 million ARR. Cursor crossed approximately $2 billion in annualised revenue.

Whether those valuations hold is a separate argument, examined in the analysis of Cursor's position. What is not arguable is that customers paid, at scale, for products the term dismisses.

The companies that used the label as fuel

There is a pattern worth noticing in which companies attracted the label most loudly. It tends to arrive when a company grows quickly in a category that looks easy from outside.

Coding tools were dismissed as thin layers over completion models. Legal platforms were dismissed as prompt engineering with a compliance veneer. Both categories then produced companies with revenue that thin layers do not generate.

That is not proof the critics were wrong about everything. It is evidence that the label was applied before anyone had examined the position, which is the specific failure being described here.

What the insult gets right

The defence above is incomplete without this, and the criticism has a real target.

A product whose only function is a nicer interface to a model does get absorbed, and faster than in any previous software cycle. Summarisation, transcription, extraction and basic generation were all standalone products before becoming default features.

The absorption mechanism is well documented. Roughly 35% of point-product SaaS is projected to be replaced or absorbed by 2030, and interface-only products are the first cohort, as set out in the analysis of category absorption.

So the insult is a blunt instrument pointed at a real phenomenon. The problem is that it cannot distinguish between the products it correctly describes and the ones it does not, because it examines the input rather than the position.

A better test than wrapper

Replace the word with four questions that actually discriminate.

The fourth question is the one worth keeping. If a major model release makes a product better, the company has built something that compounds with the underlying technology. If it makes the product unnecessary, the criticism was correct and the label was merely imprecise about why.

Applying the test to real categories

The pattern is consistent. Products positioned beside the model get absorbed. Products positioned inside a workflow get better, because the model improving improves the thing the customer is actually buying.

Notice that architecture is identical across all four rows. Every one of them calls a foundation model API and presents the result. If architecture were the determining factor, the four outcomes would not differ, and they differ substantially.

Why the label persists anyway

It survives because it is useful socially rather than analytically. It signals sophistication cheaply, requires no research into the specific company, and is unfalsifiable in the short term because absorption takes years.

It also happens to be right often enough to feel validated. A commentator dismissing every AI application company will be correct about a meaningful share of them, which is a low bar that feels like a track record.

The historical parallel nobody mentions

In the early cloud era, companies building on Amazon Web Services faced an identical dismissal. The argument was that Amazon owned the infrastructure, could observe usage patterns, and would simply build any successful application itself.

Amazon did build competing services in several categories. It did not capture most of the value created above its infrastructure layer, because building the application was never the hard part. Distribution, customer relationships and domain specificity were, and those did not transfer.

The parallel is imperfect in one important way. A cloud provider has to decide to build a competing product. A model provider absorbs capabilities incidentally, as the model improves, without targeting anyone. That makes the boundary harder to predict and the absorption less avoidable.

The lesson survives the imperfection. Owning infrastructure has not historically meant capturing the value built on it, and the burden of proof sits with anyone claiming this time is structurally different.

What founders should take from this

The practical use of this argument is not to feel better about the label. It is to stop optimising for the wrong thing.

A founder who hears wrapper and responds by fine-tuning a model, or by switching providers, or by building evaluation infrastructure to prove capability, has accepted the critic's framing and is now competing on the one dimension where they cannot win.

The response that works is to move position rather than improve the input. Get deeper into the workflow, acquire data nobody else can reach, or own a distribution channel the platform cannot access. All three are slower than a model upgrade and all three survive one.

Where this defence is weak

Three honest problems with the argument I have just made.

The comparison to databases and cloud is not exact. Those were passive infrastructure that did not improve at the application layer on their own. Models do, which means the surface being absorbed expands without anyone deciding to expand it. That is a genuine structural difference and I have understated it.

Revenue is not vindication. Pointing at companies with large revenue proves the products found customers, not that the positions are durable. Several categories that were absorbed had profitable companies in them right up until they did not.

And the strongest version of the criticism is not about wrappers at all. It is about margin. A company paying a model provider for every request has a cost structure the provider controls, and no amount of distribution or workflow depth changes who sets the input price. That is a real vulnerability, examined in the analysis of AI margins, and calling the criticism lazy does not answer it.

Frequently asked questions

Where to start this week

Retire the word and use the fourth question instead.

The next time you evaluate an AI company, as an investor, a buyer or a competitor, ask what happens to it when the underlying model improves substantially. Does the product get better, or does it get less necessary?

That question takes the same three seconds as the insult and produces an actual answer. It also happens to be the question the companies themselves should be asking after every model release, and most are not.

If you are building rather than evaluating, run it as a written exercise after the next release rather than as a feeling. List the three things your product does that the new model made easier, and the three it made less necessary. Both lists will be non-empty, and the ratio between them is your position.

Do it consistently and you will have something more valuable than an opinion about wrappers. You will have a record of whether your product is compounding with the technology or being eroded by it, which is the only version of this question that affects any decision you actually make.

Related reading