What does AI Native actually mean?
"AI Native" is the phrase of the moment, and nobody agrees what it means. My definition comes down to one uncomfortable question: could your team delete its codebase and rebuild the software inside a week?
In his AI Engineer Melbourne talk, "Spec driven AI development - A Real World Perspective", Nick Beaugeard said something I've been chewing on ever since: the codebase will stop being the source of truth. The spec becomes the truth, and code becomes something you generate from it.
I poked my mate sitting next to me. "Do you buy this?"
His response: "Naaa."
Same. And yet here I am, weeks later, still not sure he's wrong. That's usually my cue to write something down.
The term that won't define itself
The other thing that's been following me around is "AI Native". It's everywhere now. We must all become AI Native. Our teams must be AI Native. And every time I hear it, I realise I've never heard a definition that satisfies me.
I've watched impressive demos. People building agents that automate a workflow and collapse a week of effort into an afternoon. Genuinely great results. But something bugs me about calling that AI Native, and it took me a while to work out what. My gut says these people are optimising the status quo. Same process, same approach to work, executed faster. That's valuable. It's also something else. It doesn't feel like the radical leap a phrase like "AI Native" should conjure up.
So what would the leap look like?
What native actually means
In the early 80s my nan couldn't operate the video recorder, and I, aged six, could. In the early 90s my dad bought a pile of new computer hardware, went to bed, and woke up to find that his impatient son had assembled the lot and was already finding out what "multimedia" was going to look like. In the late 90s I converted most of my media degree into web-based projects, and got high grades for it, partly (I'd argue) because my lecturers looked at the work and thought: I don't fully understand what this is, but it looks brilliant, give him an A.
That was me being a digital native. Not because I'd adopted technology. Because the technology wasn't new to me. From the outside each of those moments looked like a leap. From where I stood, each one was a small step, because I had no old habits to unlearn.
That's the standard "AI Native" should be held to. Native has never meant "uses the new thing a lot". It means the new thing is your ground floor. Which raises an uncomfortable thought for those of us in our middle age: the genuinely AI Native way of working is probably the one we can't quite be comfortable with. It will be a small step for the next generation and a leap for us. If the way you're using AI feels comfortable, chances are you've bolted it onto the old way of working rather than rebuilt anything.
The definition
As I sit here in mid 2026, this is where my thinking has got to.
At its simplest, AI Native means tearing current processes down and rebuilding them from the ground up, centred on AI. The goals stay the same. The outcomes probably look similar. The means are different at the root.
But "rebuild everything around AI" is a feeling, not a definition, and on its own, those agent demos would suffice. The mechanism underneath it is what matters:
AI Native is a way of working where a team captures what it wants clearly enough that a machine can build it and check it's right, which makes the code itself disposable.
Intent meaning all of it. Requirements. Standards. Design tokens. The decisions you made and why you made them. The business rules buried in that report nobody has questioned for eight years. In most teams, that intent lives in people's heads, in stale wiki pages, in the code itself, where it slowly dissolves. An AI Native team captures it in forms a machine can execute and verify against. The code stops being the asset. The intent becomes the asset. The code is just the current build of it.
The test
Which brings me back to Nick's talk, and the idea I'm now coming round to.
You'll know a team is AI Native when it could delete its codebase and regenerate its software without sweating it.
Think about that for a second, because your first reaction is probably the same as mine was. Imagine your team lost its codebase tomorrow. Total disaster. You'd be reverse-engineering your own product. You'd be going back to every corner of the business to rediscover the requirements. You'd be re-interviewing users to understand what needs the thing was actually serving. A nightmare. And also, conveniently, absurd. Who loses a codebase?
Except we do. Constantly. We just do it slowly.
Take a system that's been in production for ten years. Do you know what it does, and why? What are the rules behind the reports it generates? Are they correct, or merely unchallenged? That advertising delivery on your site: is it doing what the business expects, or has it simply been there so long that silence has been mistaken for correctness? That's a lost codebase. You're still running it, but the intent has gone.
And every replatform is a codebase being destroyed. Every "consolidate these four similar systems into one" is a codebase being destroyed. We already delete our codebases and regenerate our software from recovered intent. We measure the process in years and it's miserable every time, precisely because the intent was never captured anywhere. The whole project is archaeology.
So the test isn't hypothetical. It's asking whether the thing we already do at decade scale, painfully, could be done deliberately and quickly. What if a team could decide to regenerate on a Monday and be done inside a week?
To be clear, no team passes this test today, mine included, and I doubt any team ever passes it completely. There will always be tacit knowledge; some of what a system does was discovered in the building of it. The test is a direction, not a badge. The question worth asking is smaller and sharper: what fraction of your system could you regenerate from what you've written down, and is that fraction growing?
Every standard made executable moves the number. Every decision recorded moves it. Every design token, every spec that can fail a build. That, I think, is what becoming AI Native actually consists of. Not adopting tools. Moving intent, artefact by artefact, out of your head and into a form that survives you.
My nan always struggled with the video recorder. The generation after me won't understand why we ever treated code as the precious thing. They'll delete it on a Monday.