The subtraction test: what AI-native actually means

I was in a meeting a few months ago where someone demoed "our new AI features." The demo was fine. Clean UI, a chat panel bolted onto the side of the existing product, a summarization button here, a suggestion button there. Everyone nodded.

Then someone asked a question that was not on the agenda: if we removed the model tomorrow, would we still have a product?

Two full seconds of silence. Then someone said "well, yes, obviously," a little too fast, and the meeting moved on. But the room knew. You could feel it. The AI was decoration on a product that already worked without it.

That question, asked plainly and answered honestly, is the whole test. Strip the model out. What is left? If the answer is "basically the same product, minus a convenience feature," you have bolted AI onto a system of record. If the answer is "nothing, there is no product," you have built something else entirely. That difference is going to separate the two kinds of software companies that exist five years from now.

The inversion

For forty years, software has mostly been a system of record. People did the work. Software remembered it. Type the invoice and the CRM stores it. Write the code and the repo tracks it. You made the decision, the database logged it. The human was the engine. The software was the filing cabinet.

AI-native software inverts that. The software does the work. The human decides.

That is the whole idea. Everything else in this post is just what falls out of it.

The trap in the middle

Most companies right now live in the space between those two worlds, and it is worth being honest about why: bolting a chat box onto a system of record is a completely rational thing to do. It is cheap, it ships fast, it makes the roadmap slide look current, and it genuinely helps users in small ways.

But a search box does not turn a filing cabinet into Google. It turns a filing cabinet into a filing cabinet you can search. That is a real improvement. It is not a strategy.

I say this without judgment, because almost every company I talk to is doing some version of it, including ones I have worked at. The trap is not using AI as a feature. The trap is mistaking the feature for the architecture. A summarize button on top of unchanged workflows, unchanged data models, and unchanged pricing is still, underneath, the old system. The record just got a little chattier.

What has to be true

If AI-native is an architecture, not a feature level, then there are a handful of things that have to be true of a product before the label earns its keep.

It fails the subtraction test, on purpose. Remove the model and the product should not degrade gracefully into its old self. It should stop functioning, the way a car stops functioning without an engine. That is not a flaw. It's the point.

It sells outcomes, not access. The old model rented you a seat and hoped you used it. The new model gets paid because the work got done, whether that is a resolved ticket, a shipped design, or a closed deal. I will say the honest thing here: plenty of companies I would genuinely call AI-native still bill by seat today, because pricing infrastructure lags architecture by a year or two. The billing model on day one matters less than which direction the company is walking.

Context compounds. Day thirty should embarrass day one. If the system does not know more about your business, your preferences, your edge cases after a month than it did on day one, it is stateless intelligence wearing a product wrapper. Real AI-native products get better the way a good employee gets better: quietly, cumulatively, without you having to retrain them from scratch every session.

The interface is negotiated, not fixed. Menus and forms assume a human clicking through a fixed set of paths. When software is doing the work, the interface has to flex around what the work actually requires that day, which means a lot less "here are your five tabs" and a lot more conversation, review, and adjustment in whatever form the moment calls for.

Trust is engineered, not assumed. You do not get to skip the part where the system proves it is reliable. Confidence scores, audit trails, graceful failure, clear escalation to a human when the system is unsure. This is infrastructure, not a nice-to-have, because the whole value proposition collapses the first time the software does the wrong thing quietly.

The part nobody writes about

Almost everything written about "AI-native" stops at the product. Nobody writes about what this does to the people who build the product, which is strange, because that is where I actually live.

If the software is doing more of the work, the question for a product or design org is not "how do we use AI tools." It is "what is a designer's job when the model can draft the artifact." I have spent real time on this in my own operating model, and the honest answer is that the job does not shrink. It moves up a level. It re-specializes around decisions instead of deliverables.

In practice that means naming the gates explicitly, because if you do not name them, nobody owns them. What problem are we actually solving. Where is scope locked. Who approves the concept before production work starts. What counts as a protected change that needs a human eye no matter how confident the system is. Who merges. Who launches. Each of those is a place where a human looks at evidence and makes a call, and increasingly the artifact between those gates was authored by an agent, not a person clicking in Figma for six hours.

That changes what craft means. A designer's craft used to live substantially in the making: the pixel, the interaction, the exact spacing. Some of that still matters, but more of it now lives in specifying intent clearly enough that an agent can act on it, in judging the evidence an agent produces, and in owning taste at the gate when something needs a human "no." Design systems stop being a reference library and start being machine-readable contracts the agents actually build against. Evals become the new usability tests, the thing you run before you trust an output, not after a customer complains. Review stops being "did I check every pixel" and becomes "do I trust the evidence enough to approve this."

This is not a smaller job. It's a different one, and most product and design orgs have not admitted that out loud yet.

The honesty bar

Here is the uncomfortable part. It is easy to say your team runs an AI-native process. Almost anyone can say it in a meeting. The proof is boring, and that is exactly why it works as a test.

Are the gate owners actually named, or is "the team reviews it" doing the work of an answer. Are evals actually running in CI, or do they live in a slide from last quarter. Does every agent-produced artifact carry provenance, so you know what generated it and what a human approved. Is throughput actually measured, or is "faster" a feeling people repeat to each other in standup.

If those things are missing, what you have is a demo of a process. Demos are fine. Just do not confuse one for the thing itself.

The whiteboard

There is a drawing I keep coming back to, one Satya Nadella has described in similar terms: a model, plus your context, plus your tools, cycling continuously. Around the rim of that loop sit the human decision points, named and specific, where someone looks at what came out and decides what happens next.

Every AI-native thing I have seen that actually deserves the name, whether it is a product or a way of working, is some version of that drawing. Strip away the logo and the pricing page and the roadmap deck, and what is left is a loop and a set of gates.

Which brings the question back around. I asked it about a product at the start of this piece. It works just as well pointed at your own team. Remove the model from how your organization actually works tomorrow. Not from the roadmap slide, from the actual daily work. What is left?

If you cannot answer that quickly, you already know the answer.