I have started to notice that "AI-native" has joined the small cemetery of phrases that mean less every time they are used. Cloud-native died there. So did digital transformation. So, probably, will agentic.
I want to make a case for taking AI-native seriously, by which I mean treating it as an engineering discipline rather than a marketing position. The reason matters: I think the next two years will sort companies into two piles based on which one they pick.
What AI-native actually means
If cloud-native had stuck to its original meaning, it would have described software designed to assume elastic infrastructure, network-as-substrate, and statelessness as a default rather than an exception. Most software that called itself cloud-native was not. It was lifted-and-shifted code with a Kubernetes manifest stapled on.
AI-native is heading the same direction. The mainstream interpretation right now is: we use an LLM somewhere in our product, and our marketing site says so. By that definition, every team is AI-native and the phrase carries no information.
The interpretation I find useful, the one I am betting on, is this: AI-native means the software's primary abstraction layer is built to be co-authored by a model and a human, and to do that, the layer has to be linguistically explicit.
That last part is where the discipline lives.
The pattern that does not scale
I see a recurring shape in early-stage AI-native startups. It looks like this:
- A founder discovers what LLMs can do in their domain.
- They wrap a fast prototype around prompts and a tool call or two.
- It works for the first ten customers.
- The eleventh customer wants something the prompts cannot do reliably.
- The team adds more prompts, more tools, more if-else around model output.
- By customer fifty, the codebase is a layered fortress of regex, retries, and "for this customer, do this instead."
This is not a failure of effort. It is a failure of layering. The team built without ever asking what concepts in their domain were stable enough to be named.
When you do not name the concepts, every customer becomes a special case, and the model becomes the single point of judgement on every decision. That is expensive, slow, and brittle. It is also indistinguishable from being non-AI-native, except more confusing to debug.
Explore then scale
The discipline we have settled on, after several false starts, is a two-phase pattern. I call it explore then scale, and it is the closest thing I have to a credo for how we build.
Phase one: explore.
Build abilities. Solve real customer problems with a mix of code, prompts, and tools. Do not pretend you know the domain yet. The point of phase one is to discover which problems you are actually solving and which concepts keep showing up across them. You are looking for the words that the domain uses naturally.
Resist the urge to over-abstract here. Premature abstraction is more expensive than special-casing, because a bad abstraction is harder to delete than a duplicated function.
Phase two: scale.
When you have built enough abilities to see the domain clearly, formalize it. The concepts that kept appearing in phase one become first-class keywords in a small domain-specific language. Derived concepts are composed from primaries. The DSL becomes the contract between human authors, the model, and the engine that runs the work.
Once the DSL exists, the rule we follow is roughly: 75% of new feature work is expressed in the DSL and generated; 25% is wired with proven libraries. The model's job is to help authors write the DSL, not to interpret intent at runtime. The engine's job is to execute the DSL deterministically, not to guess.
I phrase the underlying idea as: deterministic skeleton, probabilistic joints. The DSL is the skeleton. The model handles the joints, which are the places where language, ambiguity, and creativity actually belong.
Why this is harder than it sounds
The cost of explore-then-scale is that phase one feels embarrassingly slow. You are not shipping a polished product, you are building abilities and watching the domain teach you its own vocabulary.
The temptation in 2026, with capital cheap-ish and competitors loud, is to skip phase one and go straight to a polished phase-two artefact. That works for about as long as your scope is narrow, and then collapses, because you formalized a domain you had not actually explored.
The other failure mode is staying in phase one forever. Some teams genuinely enjoy the abilities phase: it is creative, it is full of small wins, and the codebase looks like art. But if you never scale, you never compound, and your fortieth ability is no cheaper to build than your first.
The discipline is knowing when to leave phase one. The signal I trust is when I can name, on a whiteboard, six to ten concepts that keep recurring across the abilities we have built, and when those concepts have stable boundaries. That is the readiness signal for a DSL. If you cannot name them clearly, you are not ready.
Worked example, kept abstract
Take a domain I am familiar with: test automation for web applications. In phase one we built abilities like crawl a site, generate scenarios, identify equivalent states, parameterize inputs. Most of these were prompts wrapped around code and graph machinery, plus the occasional LLM consult.
Around month nine, the recurring concepts were unmistakable: state, transition, scenario, parameter, equivalence, oracle. Six words. Each had a stable boundary in the domain. So we formalized a small DSL whose primary keywords were exactly those, composed derived concepts from them, and rebuilt the abilities on top of the DSL rather than around prompts.
The same pattern is now playing out for us in business operations and in real estate workflows. Different domains, same shape. The DSL is the moat. The abilities are the path to discovering it.
The boring middle is where the moat is
If I had to summarize the strategic claim in one sentence, it is this: AI-native companies that will compound are not the ones with the best prompts or the best models. They are the ones who took the time to learn the language of their domain and then made that language executable.
That work is unglamorous. It does not demo well. It is slow at the start and unfairly fast later. It is also, in my experience, the only AI-native architecture I have seen survive the second year.
The marketing era of AI-native is roughly halfway done. The engineering era is about to begin.
Drafted in 2026
Updated for site in October 2026