AI Decorated vs AI Native Software: Why Most AI Features Will Lose

In 2008, almost every company with a website added a “mobile-friendly” version. They shrunk the columns, hid the sidebars, called it done. A smaller group threw the website away and built something different: a touch-first, sensor-aware, location-rich application that assumed the phone as the primary surface. The companies that decorated their desktop product with a mobile skin became case studies. The companies that rebuilt around mobile primitives became Uber, Instagram, WhatsApp, and most of the consumer internet.

We are repeating the exercise with AI in 2026, and most software companies are once again on the wrong side of the line. The distinction that matters this year is AI-decorated vs AI-native software. This post is the framework I use to tell them apart, the reason one of them is going to lose, and what it means if you are buying software, building it, or funding it.

What AI-decorated software actually is

AI-decorated software is the dominant pattern of 2024 and 2025. A vendor with a product that shipped in 2012 adds a chat sidebar, trains a small model on their help docs, puts a sparkle icon next to a few buttons, announces “AI” in the product name, and adds a fee on top of the existing subscription. The architecture, the data model, the pricing model, and the team that maintains the codebase are unchanged. The AI is a feature. The product is the same product.

A short list from the last 24 months:

• Salesforce Einstein and Agentforce. A chat layer over a 1999 data model, priced as an add-on. The CRM is still the CRM.
• QuickBooks Intuit Assist. A summarization and Q&A layer over a 1983 general ledger product, with a separate price tag.
• Microsoft 365 Copilot. A useful assistant inside Word and Excel, sold for an extra $30 per seat per month on top of the existing $30.
• Notion AI, Slack AI, Zoom AI Companion, HubSpot Breeze. Each one a chat-and-summary layer welded onto a product specified before transformer models existed.

These are not bad products. They are decorated, not native, and that distinction will decide which of them survive the next price war. The defining property of an AI-decorated product is that you could remove the AI and the product would still work the same way it did before. The chat sidebar is detachable. The architecture would not notice.

What AI-native software actually is

AI-native software is the inverse. The product is architected around AI as the primary interface, the primary implementation surface, or both. Remove the AI and the product collapses, because the old workflow was never built.

The clearest examples today:

• Cursor and Claude Code for software engineering. The editor exists to mediate between the developer and the model. The file tree, multi-file edit semantics, context window management, diff review surface: every primitive is shaped by what the model needs.
• Perplexity for search. The retrieval, citation rendering, follow-up question UI, and answer-first layout assume an LLM at the center. Google’s “AI Overviews” are decoration over the same ten blue links Perplexity threw out.
• Granola for meeting notes. The capture, silent listening, structured output, and post-meeting editor are designed around a model with the full transcript in context. Otter bolted transcription onto a 2015 product; Granola was specified around the model.
• ERPClaw for ERP. The system our team built. Architectural detail below.

The defining property of an AI-native product is that the model is load-bearing. Take it out and there is no product underneath.

The economic argument: AI-decorated cannot win on price

Here is the part founders and investors most need to internalize.

An AI-decorated vendor has the cost structure of the original 2010 to 2020 era product, plus the cost of the AI added on top. They pay for the engineering team that built and maintains the legacy codebase, the data centers, the support org, the sales motion, and the per-seat margins their board expects. The AI is an add-on, both architecturally and on the invoice. That is why every product listed above charges an extra monthly fee for AI: the cost base demanded it.

An AI-native vendor that started in 2024 or later has a structurally different cost base. The codebase is smaller because the model writes most of the mechanical code. The team is smaller because coordination overhead drops with team size. The pricing is not anchored to a per-seat assumption inherited from the on-prem era.

The result is the asymmetry that always shows up in technology shifts. The new entrant can charge half of what the incumbent charges and still have better margins, or give the core product away (the path I picked) and monetize the parts the model cannot do for you. Either way, the AI-decorated tool you are paying $40 per seat per month for in 2026 will look badly priced in 2027 and indefensible by 2028.

This is the Kodak failure mode, almost exactly. Kodak invented digital photography. What they could not do was abandon the cost structure of their film business fast enough to compete with a business that was digital from day one. The same dynamic is playing out across every category of business software.

The 80/15/5 theory of where AI eats first

Why is the AI-native cost base so much lower? Use the 80/15/5 split:

• 80 percent mechanical work. Schema scaffolding, CRUD endpoints, audit logging, parameter validation, list and get APIs, the boring form code every business application needs. Repetitive, well specified, identical across products. AI does it perfectly when given a precise spec.
• 15 percent pattern-matching work. Cross-module integration, report templates, common workflow shapes, GL posting patterns. AI does this well with the right examples and a checklist of invariants. A human catches the cross-cutting surprises.
• 5 percent human judgment. Domain edge cases, regulatory nuance, the question the AI did not know to ask, the business decision that requires taste. Irreducibly human.

A traditional vendor with a 200 person engineering team spends most of its salary line on the 80 percent. An AI-native vendor automates that and reorganizes around the 5 percent that matters. The new tools are not written by smarter people; they are written by people who do not have to write the boring code at all.

This is also why you cannot retrofit AI-native. You cannot fire 80 percent of the team that maintains the legacy codebase, because somebody still has to keep it running. You cannot rewrite a million-line codebase from scratch on a quarterly earnings cycle. Decorated vendors get stuck paying for both stacks in parallel. The math does not work.

How to tell if a product is actually AI-native

Every software company on earth now claims to be “AI-first” or “AI-native.” Most are decorated. The test I run:

1. Is the AI load-bearing or detachable? If you removed the AI feature tomorrow, would users notice? In a decorated product they would shrug and use the old menus. In a native product the workflow stops working.

2. Is the pricing additive or unified? Decorated vendors charge a base fee and an “AI” fee on top, because the AI is a discrete cost line they need to recover. Native vendors price the whole product as one thing, because there is no separate “non-AI” version.

3. Is the team small or 200 people? If the vendor has thousands of engineers, that cost base will show up in the price, regardless of whether the demo had a sparkle icon.

4. Was the data model designed before or after 2023? Schemas designed before LLMs were practical were optimized for human form-filling and SQL reporting. AI-native schemas are optimized for model context: metadata-rich, self-describing, queryable by an agent without a translation layer. If the API looks like 2008 REST with a chat endpoint glued to the side, it is decorated.

5. Could the codebase be regenerated from a spec? The deepest test. In an AI-native product the spec is the asset and the code is a derived artifact; large parts of the system can be regenerated in a weekend if a better architecture appears. In a decorated product the code is the asset because somebody paid millions to write it, and that asset is exactly what they cannot afford to throw away. The sunk cost is now a liability.

Four out of five is plausibly native. One or two is decoration with a press release.

ERPClaw as a worked example

A concrete proof point: ERPClaw, the AI-native ERP our team has built over the last fifteen months. ERP is a category where the AI-decorated pattern is most visible (NetSuite, Sage, Microsoft Dynamics have all shipped a chat sidebar and a price increase in the last 18 months).

ERPClaw is a 48 module open source ERP across 14 verticals, with 3,148 actions and 789 tables. It would not exist as a hand-written codebase in any reasonable timeframe. It exists because the architecture was designed around three primitives that only make sense in an AI-native world.

First, the spec is the source of truth, the code is regenerable. Every action has a YAML-fronted SKILL.md entry that defines parameters, return shape, and invariants. The implementation, the contract tests, the dashboard forms, and the docs are all generated from that spec. A traditional ERP needs about 150 lines of UI code per action; across 3,148 actions that is roughly 470,000 lines that simply do not exist in this codebase.

Second, a constitutional rules engine catches AI mistakes the AI cannot catch itself. 18 machine-readable financial laws (no floats for money, GL is immutable, every submit is a single transaction, trial balance balanced after every test) run as executable assertions across the codebase. A module that violates an article cannot ship. That is what makes it safe to extend the system at AI speed without waking up to a $50,000 audit finding.

Third, the pricing reflects the cost base, not the legacy anchor. The open source edition is free. Not freemium, free. The marginal cost of generating a new module is hours of model time, not weeks of engineering salary. Decorated incumbents cannot match that arithmetic.

I am not telling you to install ERPClaw. I am telling you what an AI-native build looks like in a category everybody else is decorating. The same shape will appear in every other commodity software category over the next 36 months. CRM, project management, HR, helpdesk, billing, BI: commodity problems with public business rules, dominated by decorated incumbents, about to be re-priced by AI-native entrants. More on how this came together in the build retrospective and the founder origin post.

What this means if you are a buyer

Three implications if you are signing a software contract in 2026.

Audit the AI line items on every renewal. A separate fee for AI features on top of the base subscription is a tell. It signals an architecture and a cost base that is going to be undercut. Negotiate the AI line item to zero this year, or start evaluating the native alternative before the price comparison gets ugly in 2027.

Stop signing five-year contracts in commodity categories. ERP, CRM, HR, helpdesk, BI: every one of these is going to look different in 36 months. A long contract with a decorated vendor is a bet that nothing changes. Annual contracts with break clauses are sane.

Run the five-question test on every AI-marketed product you evaluate. If a vendor cannot articulate why their AI is load-bearing, why their pricing is unified, and how their codebase could be regenerated, you are looking at decoration. Use a decorated product if it solves your problem today. Just do not pay AI-native prices for AI-decorated work, and do not assume the vendor will catch up.

What this means if you are a builder

Two implications for founders and CTOs.

You cannot retrofit AI-native onto a legacy codebase. I have watched several teams try, and the failure mode is always the same: the new AI-native module ships, it impresses the demo audience, and the maintenance cost of running both stacks in parallel quietly destroys the engineering org over 18 months. If your category is being attacked by an AI-native entrant, the only response that works is to start a parallel codebase from scratch with a small team and a precise spec, and accept that the legacy revenue is going to decline while you build it. That move worked for Adobe (Creative Cloud) and Microsoft (Azure). It did not work for Kodak.

The spec is the moat now, not the code. If the model is going to write the code, the differentiated artifact is the specification, the constitutional invariants, and the test suite that catches model mistakes. Spend your engineering hours on those. The code is a derived asset and increasingly cheap. The spec is where taste, domain knowledge, and judgment live. The a16z piece on AI-native applications makes a related point in the consumer context: the unit of differentiation is moving up the stack, away from implementation and toward design.

A closing word on the vocabulary

“AI-native” and “AI-decorated” will be co-opted by marketing departments within twelve months, the way “cloud-native” lost meaning between 2014 and 2018. The vocabulary will rot. The underlying distinction will not. Whatever we call the two camps in 2028, the decorated cohort will still be losing share to the native one.

The question to ask of any AI feature right now is not “does this look impressive in a demo.” It is is the AI load-bearing, and is the price reflecting an AI-native cost base? For what the answers look like in ERP, the features overview and the pricing page are the exhibits.

FAQ

What is AI-native software in one sentence?

Software whose architecture, pricing, and team shape were designed around AI as a load-bearing primitive, such that removing the AI would collapse the product rather than degrade a feature.

Is AI-first the same as AI-native?

No. “AI-first” is a marketing claim about strategic priority. AI-native is an architectural claim about how the product is built. Plenty of AI-first companies ship AI-decorated products, because the priority did not survive contact with the legacy codebase.

Is your AI feature actually native?

Apply the five-question test: load-bearing or detachable, unified or additive pricing, small team or 200 people, data model designed for AI context or for SQL reporting, codebase regenerable from a spec or not. Four out of five is plausibly native.

Will AI-decorated vendors ever catch up?

Some will, the way some on-prem vendors successfully became cloud companies. Most will not, because running both stacks in parallel is structurally unsustainable. Watch for the ones that announce a “next-generation platform” and price it separately from the existing product. That is the shape of a serious attempt.

Why is open source the natural home for AI-native software?

The marginal cost of generating new modules is small, the spec is the moat rather than the code, and the cost base does not require per-seat pricing to recover engineering salaries. Open source AI-native systems will eat commodity SaaS the way Linux ate proprietary Unix. The vendors who survive will sell domain expertise, regulatory compliance, distribution, and trust, not code.

Where does ERPClaw fit in this taxonomy?

ERPClaw is an AI-native ERP, MIT licensed, built on the spec-first methodology. It passes the five-question test by design. A worked example of an AI-native build in a category incumbents are decorating.

What should I do this quarter if I am a buyer?

Inventory your contracts. Mark the ones with separate AI line items and the ones longer than 24 months. Start a quiet evaluation of the native alternative in your top three categories.