Built With Is Not Built On

I spent last month running agentic AI workshops across India, at universities in Gujarat and at corporate centres further south. By the third corporate visit I could predict the room. People used Copilot in Outlook, some in Word. On the engineering side everyone used Claude Code, GitHub Copilot and coding agents daily. Most of them told me, unprompted, that they were AI-native.

So I asked the follow-up. Does the product you ship call an LLM API at any point in its runtime?

I mostly heard a no.

These were not laggards. They had the deepest Western client exposure in the country and were ahead of the median on adoption. That is what makes the pattern worth writing down.

What the teams described is real, and I am not interested in being sniffy about it. Shipping conventional software faster with an agent is a genuine gain. It is also what this site calls AI-assisted: using the tools to do your existing work faster. The trouble starts when that gain and a product that runs on inference are folded into one word, and the word turns up in the same board deck, the same diligence questionnaire, the same client pitch.

Two different assets

The existing argument about "AI-native" is an argument about degree. Venture investors have sharpened a test for it: the model layer is the part you can replace, and whatever value survives the replacement is the only value you own. The test is useful because it is binary. Swap the model, keep the value or lose it.

The rooms I sat in fall upstream of that test. Is there a model to swap in the first place? In most of them, no. The claim rested on one fact: the engineers used an agent to write the code faster.

Split those two things apart and they behave differently. Tools that help your people build are one line item. Models that run inside what you sell are another. Different vendor dependency, different cost structure, different exit risk. Most companies track them as one.

Where the models actually were

The models were in these organizations. Just not in the product. They were in consumer accounts that IT does not administer. When I asked people what happens to the client documents, internal drafts and code they paste into these tools, the answers were honest and unembarrassed, because nobody had ever suggested it was a question worth asking.

One CIO had counted seats on an enterprise chatbot tier the year before and treated the small number as containment. When I asked how he would find out how many people used the free consumer version on their personal phones during work hours, he had no answer.

The honest version of the label

This is why the frameworks start with the honest look. The announcement layer, the label on the deck, tells you nothing you can act on. What tells you something is how the work actually gets done, seen close enough to be useful.

For an engineer, the honest version of the question has two halves. Does the thing you ship run on a model? And separately: is your own judgment compounding through the tools, or is the work just getting faster? Neither answer is a failure. Blurring them is.

Ask your own team the question you would ask a vendor. A yes or no, not a paragraph. If the answer takes a paragraph, the label needs a second look.

Adapted from Built With Is Not Built On in The Forward View. Read the full issue.