I sent versions of this memo to the ASAPP team in June 2016, when I started using the term AI Native, which we later trademarked. For years I thought the original was lost. It turned up in an old inbox, and it appears here as written.
Machine learning today is narrow, brittle, and expensive. Systems that look astonishing inside the boundaries of a benchmark can fail embarrassingly a few inches outside them. Much of what gets called AI is statistics with good marketing. I know this. It doesn’t matter.
What matters is the slope. Five years ago, computers could not reliably tell a cat from a dog. This spring, AlphaGo defeated Lee Sedol at Go, a game whose complexity and reliance on intuition were supposed to protect it from machines for another decade. Speech recognition is approaching human accuracy. Translation is improving faster than almost anyone predicted. Any one of these advances can be explained away as a narrow achievement. Taken together, they are harder to dismiss. The same small family of methods is beginning to work across problems we once considered fundamentally different.
That is not general intelligence. But it may be the beginning of a general capability. I want us to take seriously what happens if it is. The timing is uncertain. The direction is not.
When a new technology arrives, the instinct of every incumbent—and, honestly, of most smart people—is to fit it into the world that already exists. The first automobiles were horseless carriages. The first websites looked like documents. We take the existing product, architecture, and mental model as given, then find a slot for the new capability. A recommendation engine here, a prediction there. This year, everyone is adding a chatbot.
This is usually sensible, often profitable, and almost always how a technological transition begins. It is also how we miss what the technology ultimately changes.
You cannot strap wings onto a train and expect it to fly. The train is a marvel of engineering, optimized over a century. That is precisely the problem. Every part of it was optimized around the assumption that transportation happens on rails. Once flight becomes possible, the rail is no longer a foundation. It is a constraint.
Imagine someone handed you a perfect self-driving algorithm: any vehicle, any road, any conditions. The obvious thing to do is put it in a car. Add sensors, remove the driver, and ship an autonomous version of the vehicle that already exists.
But look at the car for a minute. The windshield exists because a driver needs to see the road. The steering wheel, pedals, mirrors, dashboard, even the orientation of the seats are consequences of the same constraint: a human being has to operate the machine. What looks like the natural architecture of a car is actually the fossil record of the human driver.
Remove the driver and almost everything becomes negotiable. The seats can face each other. The windshield can become a screen. The dashboard can disappear. The cabin can be designed around working, sleeping, talking, or entertainment. The natural product is no longer a car without a driver. It is a room that moves.
The important thing about the algorithm, then, is not that it improves the old design. It deletes the assumption the old design was built around.
Software has an assumption that deep. Almost every product we use was designed on the premise that the intelligence sits on the human side of the screen. The computer stores, retrieves, calculates, and displays. The person understands, decides, and acts. A database stores the information; a person decides what to retrieve. A dashboard displays what happened; a person decides what it means. A CRM records the customer; a salesperson decides what to do next.
We have spent fifty years improving this arrangement without fundamentally changing it. Menus, buttons, dashboards, filters, search boxes, alerts, and workflows are all interfaces between a machine that can execute instructions and a human who has to supply the intelligence. In that sense, much of what we think of as software is not intrinsic to software at all. It is an accommodation to the limitations of the machine.
It is the windshield.
AI Native means starting from the opposite premise: that machine intelligence will increasingly be available inside the system, at every layer, cheap and improving. If the machine can understand what is happening, infer what someone is trying to accomplish, and increasingly act toward that objective, the architecture changes. The product does not merely present information for a person to interpret; it can interpret it. It does not merely expose functionality for a person to operate; it can decide when to use it. It does not merely provide the tools with which someone performs the work; it can begin to perform the work itself, involving the person where judgment is actually required.
That may eventually change the economics of software as much as the interface. Traditional software sells access to functionality and leaves the customer to turn that functionality into an outcome. Software built around machine intelligence can begin to sell the outcome itself.
This is why native is the operative word. Not AI-enhanced, AI-assisted, or AI-powered. Those all describe the existing architecture with intelligence attached to it—the train with wings. Native means the capability was assumed at the foundation, and everything above it was designed knowing it would be there.
There is one consequence for what we build, and it is not optional.
Traditional software is sold per seat, and its interfaces are honest about that. They are built for a human operator: a place to sit, a set of functions to invoke, a record of what was done. The person performs the work. The product’s job is to be used. More use means more seats, which is the point.
We will not build that.
If intelligence belongs inside the system, the interface has a different purpose. It exists to automate the work it can and to augment the human where judgment is actually required. Not as assistance layered onto a conventional tool, but as the reason the screen exists. At the same time, it has to collect what happens — every decision, correction, and completed task — so the models improve with use. These are not two programs. A product that automates without learning will freeze. A product that learns without doing the work is a science project. Ours has to do both, in the same surface, from the start.
If a screen only lets a person operate the system, it is a windshield. We should not ship it.
There is an obvious problem with this in 2016: the technology is not ready. Models will fail. Things that work in papers will fail in production. Conventional software companies adding narrow machine-learning features will often look more practical, move faster, and make more money. They may be right for years.
That is not an argument for a conventional interface with a model attached. It is an argument for putting people and machines on the same work now, and treating every interaction as training. A company that waits for the models to become obvious will, when they finally do, have no data, no interface, and no habit of working this way. A company that ships this way while the models are still brittle will have a system that improves because it is used.
But there is a risk in waiting for the technology to become obvious. Products accumulate architecture, code, customers, organizations, and business models around the constraints under which they were built. By the time a constraint has visibly disappeared, the companies built around it may be unable to imagine the world without it.
That is the bet we are making. We can be wrong by building too early for capabilities that take longer than expected to arrive. Or we can be wrong by spending years perfecting an architecture around a constraint that is disappearing.
I would rather take the first risk.
The world does not need us to build a faster train. We should build for the moment the rail is no longer necessary.