Building AI-Native Products

Google Docs added an AI sidebar. You click a button, a panel slides out, and you can ask the AI to rewrite your paragraph or summarize your document. It works. It’s fine. Nobody’s workflow changed.

Cursor replaced the entire editing experience. The AI isn’t in a sidebar. It’s in the tab key, in the command palette, in the diff view, in the terminal. You don’t “use the AI feature.” You just write code, and the AI is already there, anticipating what you need before you ask. Cursor hit $1 billion ARR in 24 months. Google Docs AI is a checkbox on a feature comparison slide.

That gap, between adding AI to an existing product and building a product around AI from the ground up, is the most important distinction in software right now. And most companies are on the wrong side of it.

The spectrum nobody draws

People talk about “AI products” as if they’re one category. They’re not. There’s a spectrum, and where you land on it determines almost everything about your product’s trajectory.

Level	What it means	Example
AI-decorated	Marketing says “AI-powered.” Product has a chatbot nobody uses.	Most enterprise SaaS in 2024
AI-augmented	Real AI features bolted onto an existing product. Useful, but the core workflow is unchanged.	Google Docs AI, Notion AI, Slack AI
AI-integrated	AI is woven into the core workflow. Removing it would degrade the experience significantly.	GitHub Copilot, Linear
AI-native	The product couldn’t exist without AI. The entire UX is designed around model capabilities and limitations.	Cursor, Perplexity, v0, Midjourney

Most of the money in 2024 and 2025 went to levels 1 and 2. Most of the value went to levels 3 and 4.

The difference isn’t about how much AI you use. A product can use a lot of AI and still be AI-decorated if the AI is stuffed into a chat panel that users ignore. The difference is about whether the AI shapes the product’s fundamental interaction model.

What “AI-native” actually means

Let me be precise about this because the term gets thrown around loosely.

An AI-native product is one where the core user interaction is designed around what AI models are good at and honest about what they’re bad at. The product’s UX, architecture, data model, and business logic all assume that an AI model is a first-class component of the system, not an add-on.

This has specific implications:

The interaction model assumes probabilistic outputs. In traditional software, you click a button and get a deterministic result. In an AI-native product, you express intent and get a probabilistic result that might need refinement. The UX is designed for this: easy iteration, visible confidence, simple correction, undo that actually works.

The product shows its work. AI-native products don’t hide the AI behind a clean interface. They expose just enough of the process for users to build trust and catch errors. Perplexity shows its sources. Cursor shows the diff before applying changes. v0 shows the code it generated. This transparency isn’t a nice-to-have. It’s structural.

Failure is a first-class UX state. The product is designed from day one to handle the case where the AI gets it wrong. Not as an error screen. As a normal part of the workflow. “The AI suggested X, but you can edit it, regenerate it, or ignore it.” This is fundamentally different from traditional software, where an error means something broke.

The data model supports generation and curation. AI-native products often generate many options and let the user curate, rather than trying to produce one perfect output. Midjourney generates four images. v0 generates multiple component variants. This “generate then curate” pattern works with the model’s strengths (generating diverse options quickly) rather than against its weaknesses (reliably producing exactly one correct answer).

The anatomy of an AI-native product

Let me break down what this looks like architecturally by examining three products that got it right.

Cursor: AI as the editing surface

Cursor is the most instructive example because it started from an existing paradigm (code editors) and rebuilt it around AI.

The key insight: code editing is not a “write code, then ask AI for help” workflow. It’s a “think about what you want, and the editor helps you express it” workflow. Cursor made the AI the primary mechanism for that expression.

Traditional editor	Cursor
You type every character	Tab to accept AI completions that predict your intent
You manually find and edit across files	Describe the change in natural language, review the diff
You context-switch to docs/Stack Overflow	The model has your codebase indexed and answers in context
Errors are red squiggles you fix yourself	The agent proposes fixes and applies them with your approval
Refactoring is a manual, file-by-file process	Multi-file agent mode rewrites across the project

None of this is “AI in a sidebar.” The AI is the editing experience. Remove it and you have VS Code, which is fine, but it’s not the product people are paying $20/month for.

The architectural decisions that make this possible:

1. Codebase indexing. Cursor builds a semantic index of your entire project so the model has context. This isn’t a nice feature. It’s the foundation that makes everything else work.
2. Streaming diffs. Instead of showing you a completed output, Cursor streams changes as diffs that you can accept, reject, or modify line by line. This gives you control without requiring you to read generated code character by character.
3. Model routing. Different tasks use different models. Tab completion uses a fast, cheap model. Complex multi-file edits use a more capable model. The user doesn’t see this. They just see fast responses for simple tasks and thorough responses for complex ones.

Perplexity: AI as the information layer

Perplexity didn’t build a chatbot that answers questions. They built a search engine that uses AI to synthesize information from the web into structured, cited responses.

The distinction matters. A chatbot says “here’s what I know.” A search engine says “here’s what the web says, and here are the sources so you can verify.” The second approach is fundamentally more trustworthy because it’s auditable.

Perplexity’s AI-native design decisions:

Source-first architecture. The model doesn’t answer from its training data. It searches, retrieves, reads, and synthesizes. Every claim links to a source. This means the product’s reliability is bounded by the quality of its retrieval, not the model’s knowledge, which is a much easier problem to improve incrementally.

Follow-up as a first-class interaction. Instead of treating each query as independent, Perplexity maintains context across follow-ups. “Tell me more about the third point” works naturally. This mirrors how people actually research: they don’t ask one question and leave. They drill deeper.

Structured output by default. Responses come with headings, bullet points, comparisons, and tables. Not because the model was asked to format nicely, but because the product’s rendering layer structures the output. The model provides the substance, and the product provides the form.

Perplexity’s numbers tell the story. 800% year-over-year growth. $148 million ARR. Projected to reach $656 million in 2026. This isn’t a chatbot that got lucky. It’s a product that reimagined information retrieval from first principles.

v0: AI as the builder

Vercel’s v0 started as a UI component generator and evolved into something more ambitious: an agentic builder that plans, codes, and deploys entire Next.js applications.

The evolution is instructive. v0 launched in 2023 as a prompt-to-UI tool. You described a component, it generated React code using shadcn/ui and Tailwind. Useful, but limited. By mid-2025, Vercel transformed v0.dev into v0.app, upgrading from a generator to an agent that can research, plan, debug, and iterate autonomously.

The AI-native insight here: the product isn’t “AI writes code for you.” It’s “AI builds alongside you.” The distinction is in the interaction model.

Traditional code generators dump output and walk away. v0 works in a sandbox that maps directly to real Vercel deployments. It imports your existing GitHub repositories. It pulls your environment variables. It generates code that runs in context, not in isolation.

This is what Vercel calls solving the “90% problem”: connecting AI-generated code to existing production infrastructure, not just producing prototypes. The earlier version of v0 could generate beautiful components that didn’t fit into anyone’s actual project. The current version generates code that deploys.

The graveyard of AI-augmented features

For every Cursor and Perplexity, there are dozens of products that added AI features and got nothing for it. The patterns are consistent enough to be instructive.

The chatbot sidebar

This is the most common failure mode. Take your existing product. Add a chat interface somewhere. Connect it to GPT-4. Ship it. Call it “AI-powered.”

The problem: nobody asked for a chatbot in their project management tool. Or their email client. Or their spreadsheet. The chatbot doesn’t understand the product’s data model deeply enough to be useful. It gives generic answers when users need specific ones. And it adds cognitive overhead, because now the user has to decide whether to do the task themselves or try to explain it to the chatbot (which often takes longer).

Venture investors said it plainly in late 2025: look-alike applications built on foundation models have fallen out of favor, particularly chatbots without a specific use case or distribution advantage. The generic chatbot sidebar is dead. It just doesn’t know it yet.

The “AI-powered” rebrand

Some products didn’t even add real AI features. They just added “AI” to their marketing. Same product, same experience, new landing page copy. This worked for about six months in 2024, when investors would fund anything with “AI” in the pitch deck. It stopped working once people started asking “what does the AI actually do?”

The feature that’s slower than manual

This one is painful because the AI is real and the feature is implemented correctly, but it’s slower than doing the task manually. An AI email summarizer that takes 5 seconds to summarize an email you could scan in 2 seconds. An AI meeting notes generator that produces notes you have to spend 10 minutes editing into something useful. An AI code reviewer that flags 50 issues, 45 of which are stylistic nitpicks.

The bar for an AI feature isn’t “it works.” It’s “it makes the user faster or better at their job.” If the AI feature adds friction, users disable it.

The design principles that separate native from added

After studying the products that got AI-native right and the ones that got it wrong, I’ve extracted a set of design principles that separate the two.

1. Intent over instruction

AI-native products let users express intent (“make this section clearer,” “find me a cheaper flight,” “refactor this to use hooks”) rather than giving instructions (“rewrite paragraph 3 to be more concise using active voice and shorter sentences”). Intent-based interaction works because the model is good at inferring specifics from intent. It’s bad at following complex multi-step instructions perfectly.

This is the opposite of how most teams think about AI UX. They design elaborate prompt templates with detailed instructions. The user fills in blanks. The model follows the template. This produces rigid, brittle experiences. Intent-based design produces flexible, natural ones.

2. Generate, then curate

AI-native products embrace the model’s strength (generating diverse options quickly) and route around its weakness (consistently producing exactly one correct output).

Midjourney generates four images per prompt. The user picks the best one and requests variations. v0 generates multiple approaches and lets you choose. Cursor shows completions that you accept or reject with a keystroke.

This pattern works because human judgment is cheap and fast. Reviewing four options and picking the best one takes seconds. Trying to craft a prompt that produces exactly the right output on the first try takes minutes (and often fails).

3. Context is the product

The most important architectural decision in an AI-native product is how you manage context, the information the model uses to produce relevant outputs.

Cursor indexes your codebase. Perplexity retrieves from the web. v0 imports your GitHub repo. In each case, the context is what makes the AI useful for your specific situation rather than generic.

Products that skip this step and just send the user’s query to a model with no context get generic, unhelpful responses. The user tries it once, gets a vague answer, and never comes back.

Context engineering is the hard part. Building a good retrieval system, maintaining a semantic index, managing what fits in the context window, deciding what to include and what to leave out. It’s not glamorous work. But it’s what separates “AI that’s useful” from “AI that’s a toy.”

4. Progressive disclosure of AI capability

Good AI-native products don’t overwhelm users with AI features. They start simple and reveal depth as the user gets comfortable.

Cursor’s first interaction is tab completion. You press tab, the suggestion appears, you accept or reject. Dead simple. As you get comfortable, you discover inline editing. Then multi-file editing. Then agent mode. Each layer is more powerful but also more complex.

This mirrors how people adopt any complex tool. They start with the simple, low-risk interactions and gradually explore more powerful ones. If you front-load the complexity (“here are 15 AI features, learn them all”), users bounce.

5. Inspectability builds trust

In a world where the AI might be wrong, showing your work isn’t optional. It’s how you earn trust.

Perplexity cites every source. Cursor shows the diff before applying. GitHub Copilot presents suggestions inline where you can read them in context. These products trust users to evaluate the AI’s output rather than blindly accepting it.

Products that hide the AI’s reasoning (or lack thereof) struggle with trust. Users don’t know if the output is reliable. They can’t learn the AI’s failure modes. They can’t calibrate their trust over time. So they either over-trust (and get burned) or under-trust (and stop using the feature).

6. Low-commitment exploration

AI-native products make it easy to try things without commitment. Generate a design, but don’t save it until you say so. Suggest a code change, but don’t apply it until you approve. Draft an email, but keep the original until you send.

This reduces the perceived risk of using AI. If the worst case is “I wasted 3 seconds looking at a bad suggestion,” users will try the feature liberally. If the worst case is “the AI rewrote my document and I can’t undo it,” users will avoid the feature entirely.

Building AI-native: the practical checklist

If you’re building a product and want it to be AI-native rather than AI-augmented, here’s what I’d focus on.

Start with the interaction model, not the AI feature. Ask: what’s the core thing users do in this product? How would that interaction change if a model could predict, generate, or retrieve in real time? Design the interaction first, then figure out which model capabilities you need.

Build context infrastructure before building features. Whatever domain you’re in, the AI’s usefulness depends on the quality of context it has. Build the retrieval, indexing, and context management infrastructure first. The features on top of it will be dramatically better for it.

Design the failure UX before the success UX. The AI will get things wrong. What happens when it does? If your answer is “an error message,” you’re building AI-augmented, not AI-native. AI-native failure UX is: show the user what happened, let them correct it, learn from the correction for next time.

Ship narrow, then expand. Don’t launch with “AI for everything.” Launch with one AI interaction that works extremely well. Once users trust it, expand. Cursor started with tab completion. Perplexity started with single queries. v0 started with component generation. All three expanded after earning trust on the simple case.

Measure what the AI changes, not what the AI does. The metric isn’t “how many AI queries per user.” It’s “how much faster do users complete their core task” or “how much higher quality is their output.” If the AI is doing a lot of work but not changing outcomes, it’s decoration.

Invest in model routing from day one. Different interactions need different models. Fast, cheap models for low-latency, low-stakes interactions (autocomplete, classification). Capable, expensive models for high-stakes, complex interactions (multi-file refactoring, research synthesis). Build the routing infrastructure early. It affects cost, latency, and quality simultaneously.

The second-mover trap

One pattern I want to flag because I’ve seen it repeatedly: incumbents trying to become AI-native by adding AI features to their existing product.

This almost never works at the AI-native level. It works at the AI-augmented level, which is valuable but different.

The reason is structural. An incumbent’s product is built around a specific interaction model. Google Docs is built around a cursor in a document. Figma is built around a canvas with objects. Jira is built around tickets in a board. These interaction models are deeply embedded in the product’s architecture, data model, and UX patterns.

You can add AI to these interaction models. You can’t easily rebuild these interaction models around AI. The existing architecture fights you at every step. The data model doesn’t support probabilistic outputs. The UX doesn’t have a natural place for “the AI suggested something, do you want to accept it?” The undo system doesn’t account for AI-generated changes.

This is why Cursor, a new product, could be AI-native while VS Code, with access to the same models and far more resources, could only be AI-augmented. VS Code’s extension API, its editing model, its entire architecture was designed for a world where the human types every character. Cursor started from scratch and designed for a world where the AI suggests most of the characters.

The incumbents aren’t doomed. But their path to AI-native likely involves building a new product alongside their existing one, not retrofitting the existing one. Some are doing this. Vercel didn’t try to make Next.js AI-native. They built v0 as a new, AI-native product that happens to output Next.js code. That’s the right move.

Where this goes next

The AI-native products of early 2026 are impressive, but they’re still early. Here’s what I think the next wave looks like.

Multi-modal by default. Current AI-native products are mostly text-in, text-out (or text-in, image-out). The next generation will work across modalities naturally. Describe a UI change in words, see it rendered visually, hear the accessibility implications read aloud, all in one interaction.

Memory across sessions. Current products are mostly stateless. Each interaction starts fresh (or with limited context from the current session). AI-native products with genuine long-term memory of your preferences, your project, your working patterns, will feel dramatically more personal and useful.

Collaborative AI. Current AI-native products are single-user. You interact with the AI alone. Products that support collaborative AI interactions (two engineers using Cursor on the same codebase, with the AI understanding both their contexts and coordinating) will unlock new workflows entirely.

Domain-specific AI-native products. The first wave of AI-native products was horizontal: code editing, search, image generation. The next wave will be vertical: AI-native legal research, AI-native financial modeling, AI-native architectural design. Each one will have domain-specific interaction models that a horizontal product can’t match.

The companies that build these won’t be the ones that add AI to existing domain tools. They’ll be the ones that rethink the domain’s workflow from scratch, with AI as a first-class participant.

That’s the pattern. That’s been the pattern all along. The products that win aren’t the ones that use the most AI. They’re the ones that rethink the interaction from the ground up, with an honest assessment of what AI is good at and what it’s not, and design every layer of the product around that reality.