"AI-native" is being claimed faster than it is earned. Five questions that check it.

"AI-native" is in the middle of the phase where a term is being claimed considerably faster than it is being earned. It is in job descriptions, in CVs, and in a fair number of bios including, in one form or another, my own — so I have some obligation to say what I think it means and how I would want it checked, including on me.

#The distinction that makes it a real term

The useful line is between adding these systems to an existing method and starting from them.

A designer who has always designed and now generates first drafts faster is using AI. Excellent, sensible, and not what the word describes. Someone AI-native has a working method that does not make sense without these systems — the way work is scoped, the order things happen in, what gets prototyped versus discussed, what is worth attempting at all.

For me it means that a question I would previously have researched for a week and then written a document about, I now build a working version of in an evening and look at. That is not the same job done faster. It is a different sequence, and it produces different decisions.

#Five questions that separate the claim from the label

1. What have you shipped, and can I look at it?

Not what you have used. What exists because of you that did not exist before. It does not have to be large — a working internal tool with three users is a stronger answer than a description of an ambitious project that stayed a description.

2. What did you do when the model was wrong?

This is the highest-yield question and I would ask it first if I only had one. Anybody who has genuinely built something has a story here, and it is usually specific and slightly annoyed — the confident wrong answer that cost a day, the thing that worked in testing and not in front of a user, the subtly incorrect implementation that was built on for a week.

Somebody who has only used a chat window has no such story, because a wrong answer in a chat window costs nothing. You just ask again.

3. What have you refused to automate?

An answer here demonstrates that the enthusiasm is governed, which is the property everyone is quietly worried about. "Nothing, I automate everything I can" is a genuinely bad answer and it is given frequently, in the belief that it sounds committed.

4. How do you know the output is right?

Look for a process rather than a sentiment. "I check it carefully" is a sentiment. "I read every change before accepting it, I test on a second device, and I have a list of things that never ship without a person looking" is a process. Most people do not have one, which is precisely why having one is worth so much.

5. What is in your codebase that you did not write, and how do you know it is safe?

The uncomfortable one, and the fastest way to find out whether somebody has thought about the risk they are carrying. The honest answer usually starts with "most of it", and what follows is the actual information.

#What a thin claim sounds like

• A list of tools as the answer to every question. Tools are the least differentiating thing about anyone right now.
• No artefacts. Two years of AI-native practice and nothing anyone can look at is a contradiction.
• No failures. Anybody who has built something real has been badly wrong at least once and can describe it in detail. Everything having gone smoothly is not a good sign; it means nothing was attempted at a scale where it could break.
• Volume as the headline. "I ship an app a week" invites the question of how many of them anyone uses, and I say that as somebody who has made exactly this mistake and written about it.
• Total confidence about the tools' capabilities. Real familiarity comes with a specific and slightly irritated sense of what they are bad at.

#My own answers, since I use the term

It would be poor form to publish a test I have not sat.

• Shipped: twenty-one products, several publicly usable, plus a language model trained from scratch with a measured accuracy figure.
• When it was wrong: it once produced a plausible adjacent solution I did not catch for several days, and everything built on top of it had to come out. That is why I now require an agent to report what it assumed before I accept anything.
• Refused to automate: accepting changes. No auto-accept, ever, on anything anyone will depend on.
• How I verify: every diff read before it lands, summaries and commit messages read, security model reviewed separately from whether the feature works, and a production build used for anything the development server cannot honestly test.
• What I did not write: most of it, and I know it is safe to the extent that I have read it and tested it, which is a claim with a boundary rather than a guarantee.

#The version I would want applied to me

Somebody who has built one thing badly and can explain precisely why it was bad is further along than somebody who has built five and thinks they all went fine. The first person has a model of how this goes wrong. The second has a portfolio and no instincts.

So if you are assessing the claim in someone else, weight the failure question heavily and the tool question at zero. And if you are making the claim yourself, have the answers ready — not because someone will definitely ask, but because assembling them tells you whether the term is currently true of you.