A Product That Improves With the Model

Here is the most useful question anyone building on AI can ask, and it takes ten seconds:

If the model got twice as good tomorrow, would your product get better, worse or irrelevant?

Everyone who builds on a model from OpenAI, Anthropic, Google or an open-weight lab lives with a strange fact. The most important component of their product improves on someone else's schedule. A new release can make the product noticeably better overnight, at no cost to the people who built it. It can also make the product unnecessary, because the new model does unaided what the product used to coax out of the old one, or because the lab ships the same thing inside its own app.

Which of the two happens is not luck. A product gets stronger with each model release when it supplies what the model needs and can't bring with it: access, a place in the work, a way to check the results, someone who answers for them. It gets weaker when its value comes from patching what the model gets wrong, because patching the model is exactly what the labs are doing too. You can tell which kind you're building, and you can design for the first.

Three ways to sit next to a model

Start with what the customer actually pays for, and ask how that thing changes as the model improves. Almost every AI product falls into one of three relationships, often in different parts of the same product.

Compensators make up for the model's weaknesses. A tool that splits long documents into chunks because the model couldn't read much at once. A service that repairs broken output. An elaborate workflow that walks a weak model through a task one step at a time. A library of prompt tricks that worked on last year's model. The customer pays for the gap between what the model can do and what they need. Every model generation narrows that gap, so the product's value falls as the model improves.

Thin wrappers put an interface around the model's general ability: a chat window for a niche, a template gallery, a branded assistant. Their value stays roughly flat as the model improves, because the improvement reaches everyone using the same model, including the lab's own app and every competitor. They last as long as they offer convenience or distribution the lab doesn't bother with, and they're exposed the day the lab decides the niche deserves a default (Why Labs Build Products).

Complements supply what the model needs and can't supply itself. Economists use the word strictly: two things are complements when each makes the other more valuable, the way fuel and engines each make the other worth having. When capability gets better and cheaper, demand rises for whatever it has to be combined with to become finished work. A product that is that "whatever" rises with every release.

Scroll sideways to see the whole figure

Why patching the model is a losing race

Compensators are often the easiest products to build and sell early. The weakness they cover is visible and painful, the demo makes the difference obvious, and the customer can measure it.

That same visibility is the problem. To see why, it helps to know how a model gets its habits. After a model learns language from a huge pile of text, the lab spends a second phase training it on what good behavior looks like, called post-training: examples to imitate, answers to prefer, tasks with checkable results to practice on. This is where a lab fixes specific failures. And a lab can see which failures its customers work around, in feedback, in usage and in the products built on its API. Every visible weakness is a training target.

The record shows this happening layer by layer. Tools that chunked documents for models with short memories lost much of their reason to exist when Anthropic shipped a model that could take in 200,000 tokens at once in November 2023 (a token is a chunk of text a bit shorter than a word, so that is a long book), and Google previewed a million tokens a few months later. Code that repaired malformed output lost most of its job when providers added modes that force the model's answer into a required structure, starting with OpenAI's in August 2024. Prompt pipelines that walked a model through a problem step by step lost much of their value to models that reason before answering, beginning with OpenAI's o1 in September 2024. By mid-2025, a Wharton study found that telling these reasoning models to think step by step moved their accuracy by a few points either way while making them slower.

Each time, the patch became a default. None of this made the patches worthless when they shipped. Compensating is often the right way to deliver something useful now, with the model that exists now. It just has a half-life, and it should be built that way: cheap, labeled with the weakness it covers, and planned for removal. The mistake is pricing a compensator as if it were a durable asset (Same Model, Different Results calls the same thing scaffolding, inside a single system).

What a better model can't bring with it

Complements are harder to see, because they rarely appear in a demo. Five recur.

Access. Connections to the systems where a company's information lives, with permissions worked out, the security review passed and the data mapped. A better model can reason over more of it, faster. Earning that access is slow, human work.

A place in the work. Being where the work already happens: the system of record, the queue, the document people edit together. A better model inside that position does more work there. A better model somewhere else has to be invited in.

A way to know what good looks like. A product with real cases from its domain, and a way to grade them, can adopt each new model within days and prove the improvement to customers. Without one, every upgrade is a gamble.

Accountability. Someone who stands behind the result: a guarantee, a certification, a signature, a support team that fixes things. Models don't sign contracts. As they do more of the work, whoever answers for it becomes more valuable.

An interface for checking. As models produce more, people spend more of their time reviewing. Products that make checking fast, by showing sources, highlighting what changed and making mistakes cheap to undo, gain value as the volume grows.

Notice that every one of these is made of time, permission and trust, which is also why they're defensible (Where the Moat Moves). The same property that makes them hard to copy makes them gain from model improvements.

One honest correction: complements aren't immune to the labs either. The generic version of each is exactly what a lab can ship. Anthropic launched Claude Enterprise in September 2024 with a GitHub integration, described as the first of several connectors to an organization's data, and the labs have since moved into connectors, workplace agents and deployment services. What a lab can't ship is the specific version: the permissions inside one customer's systems, an evaluation built from that customer's cases, a named party who answers for the result.

A connector anyone can install is a feature. The access a security team approved after months of review is an asset.

One product, three parts

Real products mix all three, and the useful exercise is to take yours apart.

Consider an AI coding tool. Some of it compensates: tricks for squeezing the right files into an older model's limited context. Some of it wraps: an editor with a model behind it, which any competitor using the same model can match. And some of it complements: access to the company's repository, the connection to its test runner, its review flow, its team's conventions written down where the model can read them.

Ask the twice-as-good question of each part. The context tricks get less necessary. The editor stays about as valuable, until the lab ships a good one. The repository access, the tests and the conventions all get more valuable, because a stronger model can do more with them. The strategic question is which share of the customer's willingness to pay sits in each part, and which way the largest share is moving.

Designing so the next model helps

Knowing which relationship you want is the strategic part. The design part is making sure each model improvement actually reaches your customers instead of piling up unused. Five habits do most of the work.

Keep the model swappable. Put it behind an interface the product owns, so moving to a new model or provider is a configuration change backed by tests (Choosing a Model Provider Without Marrying It).

Run your own evaluation on every release. A set of real cases tells you within hours whether the new model is better at your work. Without it, every upgrade is a risk, teams delay them, and the product falls behind competitors built on the same models.

Make autonomy a dial, not a rebuild. Design the model's role to grow in steps: suggest, then draft, then act with approval, then act within limits, then run the whole flow with people reviewing samples and still answering for the result. Each model generation should move you one notch without redesigning the product, and the dial should move on evidence from your evaluation, not on release notes.

Scroll sideways to see the whole figure

Take scaffolding out on each upgrade. When a new model arrives, the first experiment is removal: the rigid steps, the repair code, the defensive prompt rules. If results hold or improve, the product just got simpler and better at once. Scaffolding you never remove caps what each new model can do inside your product.

Write down intent, not tricks. Instructions that describe the goal, the constraints and the reasons survive model changes. Workarounds for one model's habits become noise, or harm, on the next (Write for the Model That Doesn't Exist Yet).

When a wrapper is a fine business

Thin wrappers get a bad name, and some of it is deserved. But a wrapper can be a sound business when its real asset is distribution: an audience, a channel, a brand trusted in a niche the labs won't prioritize. It works when it moves fast enough to treat each release as a chance to ship something new. And it works best as a phase, where the company uses the revenue and the customer relationships to build complements.

The failure is mistaking traction that came from the model's capability for a position of your own, and still selling the capability after it has become a default.

My judgment on all this is fairly blunt. If most of what your customer pays for is a patch, start building the complement now, while the patch still pays for it. If you are a buyer rather than a builder, ask the same question of your vendors: a supplier whose product gets worse as models get better is a supplier you'll be replacing. This rests on labs continuing to improve general capability faster than any single product can improve its patches; if that slowed for years, compensators would live longer. As of October 2026, nothing points that way.

What to do

Classify what your customer pays for. Patching the model, wrapping it, or complementing it. Expect the first to shrink, the second to stay flat until absorbed, and the third to grow.

Put your engineering into complements. Access, a place in the work, evaluation, accountability, and an interface for checking. These are slow to build, which is the point.

Treat every patch as temporary. Build it cheaply, write down which weakness it covers, and try removing it the week a new model arrives.

Make upgrading boring. A swappable model, an evaluation that runs on every release, and an autonomy dial that moves one notch at a time. The product that adopts a better model in days, and can prove it got better, is the one that improves with the model.

Check yourself

Why do compensators lose value with each model release?

The customer pays for the gap between what the model does and what they need. Each generation narrows the gap, and labs can see which failures customers work around, so each one becomes a training target.

Why do complements gain from a better model?

They supply what a model can't bring itself: access, a place in the work, grading, accountability and checking. A stronger model does more with them, and they are made of time, permission and trust, so they are hard to copy.

What do a swappable model and your own evaluation do for upgrades?

They let you adopt a new model within days and prove it got better. Without them every upgrade is a gamble, teams delay it, and the product falls behind.