Day 095Understanding AI6 min readChinese original ↗

What actually counts as AI-native?

到底什么才算 AI-native?
TL;DR
  • To judge whether a product is AI-native, I don’t look at whether it uses AI or used it from day one, but at what AI actually changed: the core value, the workflow, the system structure, even the economics.
  • Once you’re really in production, the model is only part of the system. The “native” in AI-native often shows up in the whole set of things around the model: context, tools, permissions, evals, fallback.
  • AI-native is more a matter of degree than a dividing line: from AI feature, to AI-enabled, to AI-native. Faced with AI buzzwords, don’t look first at what it’s called; first look at what it has made different.

In a recent interview, I was asked about a term that’s very common now:

AI-native

I used to see the word often too. My understanding was roughly: it isn’t simply plugging a large model into an existing product and adding a few AI features, but AI more deeply shaping the design of the product itself.

But that definition is still very broad.

Now a SaaS that adds an AI summary can call itself AI-native; a company that uses Copilot heavily can say it’s becoming an AI-native organization. It’s all over job postings, product websites and pitch decks.

So I later reorganized my thinking about the concept.

I think the key to judging whether a product is AI-native isn’t “does it use AI,” nor necessarily “did it use AI from day one,” but:

what exactly did AI change about this product?

The most basic distinction: is AI a feature, or has it entered the product’s core structure?

IBM defines AI-native roughly as:

AI is a core component from the start, not a feature bolted on later; it further shapes the product’s architecture, decisions, user experience and the whole system lifecycle.

“From the start” doesn’t really need to be taken too literally.

A software company that has existed for ten years can just as well redesign its core product because of AI.

For example, a traditional customer service system originally had tickets, search and template replies, and later added an AI summary.

That’s a very useful AI feature.

But if AI starts taking part in understanding the customer’s history, querying related systems, judging the next step and generating a plan for handling it, while the human role gradually becomes reviewing and correcting, the change is clearly deeper.

At that point, what AI has changed is no longer just a feature, but the whole workflow, and the division of labor between people and the system.

So more worth looking at than “did it use AI from day one” is:

has AI changed the product’s core value, workflow, system structure, even its economics?

These days I roughly judge from four places.

1. Has the core value changed?

Much software used to require users to know for themselves:

which page to go to, which fields to fill in, which buttons to click, in what order.

AI products are starting to show another possibility:

users first say what they want to accomplish, and the system helps judge how to do it.

The change isn’t just an extra chat box.

The division of labor between product and user starts to change.

Software used to mostly help users carry out a series of operations; now some AI products are starting to take on part of the judgment and execution.

For example, users no longer need to tell the system explicitly:

look up this data first, then open that page, then do the next step.

They may only need to give a goal, and the system understands the context, calls tools, handles intermediate results, and asks a person to review or correct when needed.

When OpenAI talks about agents, it often uses one word: delegation.

I think the word is very accurate.

One important change in AI-native is software gradually moving from “helping users operate” toward “accepting part of the task as delegated.”

Of course, not every product will end up as a fully autonomous agent.

What really matters is whether AI starts taking on part of the work that users used to have to decide explicitly.

2. Has the workflow really been redone?

Many so-called AI products are really still:

the old workflow + an AI button.

Writing a report used to mean filling in ten fields; now there’s one more thing beside them:

Generate with AI

The feature may be very useful, but the process itself hasn’t changed much.

Deeper AI product design rethinks the whole workflow:

  • how much do users still need to input?
  • which steps can the system decide on its own?
  • when should it ask a person?
  • when can it keep calling tools?
  • how does it recover after a mistake?
  • is the person operating every step, or gradually becoming the one who sets goals, reviews and corrects?

So the process is no longer entirely fixed:

step 1 → step 2 → step 3

Along the way, more dynamic paths appear, decided by context, the model’s judgment and the results of each run.

That’s also why concepts like agents, tool use and context engineering are becoming important together.

Once the system can judge the next step itself, product design naturally can’t only consider pages and buttons.

3. A whole new set of product capabilities grows around the model

This is a layer I used to overlook fairly easily.

If you’re just building a very simple AI feature, it may look like:

prompt → response

connect to a model API and get a result.

But once AI really enters the core workflow, you quickly run into lots of extra questions:

  • what does the model know right now?
  • which data can it access?
  • which tools can it call?
  • does it have permission to perform this action?
  • what happens after a mistake?
  • how do you know whether a new model made the product better or worse?

So around the product, things slowly grow:

context, memory, tools, permissions, guardrails, evals, observability, fallback…

These didn’t entirely not exist before, of course, but AI products clearly amplify how much they matter.

That’s also where I now think AI-native is easily misunderstood.

People easily put all their attention on the model itself:

  • which model does it use?
  • is it the latest?
  • how high are the benchmarks?

But once you’re really in production, the model is only part of the system.

Everyone can buy similar model capabilities; what often decides whether a product works reliably, and whether you dare hand it to real users, is the whole system around the model.

So now I actually think:

the “native” in AI-native often shows up around the model.

4. Even the economics may change with it

AI products have another very practical difference:

usage itself keeps generating compute costs.

A complex task may include model calls, retrieval, tool execution, long context, multi-turn reasoning, and possibly rerunning after failure.

So the product needs to consider early on:

  • which tasks are worth a stronger, more expensive model?
  • when can things be routed to a cheaper model?
  • how long can an agent run?
  • how much allowance do users get?
  • charge per seat, per usage, per task, or per final outcome?

These are no longer just technical questions.

They directly affect the product experience, margins and the business model.

In traditional SaaS, once many features are built, the marginal cost of a user clicking a button one more time is very low.

Not necessarily so for AI products.

So if AI really enters the core of a product, it sometimes affects everything from the UI, workflow and system architecture all the way to the economics.

AI-native is more a matter of degree than a dividing line

So now I don’t really want to split all products simply into:

AI-native / not AI-native.

It’s closer to a process of going progressively deeper.

AI feature

Adding AI capabilities like generation, summarization and search to an existing product.

AI-enabled

AI has clearly changed some important workflows, but most of the product’s structure still follows the old ways.

AI-native

AI starts shaping what value the product offers, how users accomplish tasks, how the system runs, and how the product is evaluated and charged for.

The boundaries won’t be very precise, of course.

And AI-native itself has already been used very loosely by marketing.

If AI really does gradually become default infrastructure the way the internet did, the term may slowly lose its power to distinguish, too.

Today we no longer make a point of saying:

“this is an internet-enabled product.”

Because that’s the default.

AI-native may end up in a similar place.

So how do I judge whether a product is AI-native now?

I won’t accept the label just because a product uses the latest model, has a chat box, has agents, or its website says AI-native.

I look at a few more concrete things:

  • has AI changed the product’s core value?
  • has it changed the workflow by which users accomplish tasks?
  • does it require the system to newly handle context, tools, permissions, evals and failure?
  • has it gone on to change the cost structure and business model?

If basically none of these apply, and it’s just old software with a few AI features added, then AI-native is more packaging.

If AI’s presence has already made the product need its core logic redesigned, then the term really starts to carry information.

That’s also a way of judging I use more and more often now when facing lots of AI buzzwords:

don’t look first at what it’s called.

First look at:

what has it actually made different from before?

Written in Chinese and translated into English with the help of AI. Read the original