Bolt-on AI speeds up the old unit of work, AI-native software replaces it

The pitch deck I see most often this year has a slide that says "AI-native" and a product screenshot that says otherwise. The screenshot shows the same form, the same table, the same approval button the product shipped with in 2021, and a panel on the right where a model drafts something for the person to paste in. Board members nod. Nobody asks what changed about the work.

I have sat in that decision. With an installed base, a product customers have built their processes around, and a budget that funds either a model beside the product or a rebuild of the product around the model, both options get called "AI." They are not the same decision, and the difference is not where the model sits on the architecture slide.

My claim: bolting AI on keeps the old unit of work and makes it faster. Building AI-native changes what the unit of work is. Bolt-on is the right choice when the artifact your customers trust, the record, is the product, and the wrong one when the work that produced that record is what the model can now do. Most companies calling themselves AI-native have made the first choice and are describing the second.

The distinction the field actually draws

The argument usually starts with the wrong definition. Founding date is not it; a company started in 2025 can bolt a chat window onto a CRUD app as easily as an incumbent can. Model quality is not it either; both sides call the same APIs.

The definition that holds up comes from the standards. NIST's AI Risk Management Framework, following ISO/IEC 22989, defines an AI system as "an engineered or machine-based system that can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions influencing real or virtual environments."¹ The useful word is the one nobody quotes: decisions. A recommendation leaves the environment unchanged until a person acts. A decision changes it. The question that separates the two architectures is which of those outputs the model is permitted to produce, and that is a question about the unit of work, not the model.

A unit of work is the smallest thing a system treats as complete: a ticket resolved, a document approved, an invoice matched, a part cleared for shipment. Every business application is organized around one. Satya Nadella described the incumbents' version of this bluntly on the BG2 podcast in December 2024: business applications are "essentially CRUD databases with a bunch of business logic," and once "the logic tier can be orchestrated by AI and AI agents," the notion of the application "will probably collapse in the agent era."² Whatever one thinks of the prediction, the anatomy is right. Create, read, update, delete, plus the logic that decides which of those happens. Bolt-on and native differ in what the model is allowed to touch in that list.

The two architectures

In the bolt-on architecture the model sits in the read path. It reads the record, reads the context around it, and proposes. A person accepts, edits or dismisses the proposal, and only that person's action writes. GitHub's documentation for Copilot's completions describes the pattern exactly: "Copilot offers coding suggestions as you type," and the developer decides what lands in the file.³ The unit of work, the file, the commit, the pull request, is unchanged. The model made the developer faster at producing it.

In the native architecture the model sits in the write path. It reads the inputs, produces a decision, attaches the evidence that justifies it, and writes to the record itself. The person moves to a different place in the loop: they define the policy the model applies, they own the exceptions the model cannot resolve, and they audit a sample of what it wrote. The unit of work is no longer "a person completes a task with help." It is "the system completes the task, and a person handles what it could not."

Anthropic's engineering guide draws the same line from the other end. It separates "workflows," where "LLMs and tools are orchestrated through predefined code paths," from "agents," where "LLMs dynamically direct their own processes and tool usage," and advises "finding the simplest solution possible, and only increasing complexity when needed."⁴ That advice is often read as a case for bolt-on. It is not. A native system can be a workflow: a fixed pipeline in which the model's output is a decision with a confidence and an audit record, and the only branch is whether that decision clears the policy or goes to a person. What makes it native is that the pipeline ends in a write.

The bill for bolting on

Bolt-on wins the first year, and it is worth being precise about why. It ships in weeks, because the record, the permissions, the integrations and the customers' habits are untouched. It carries no rewrite risk. It is easy to measure, because the old unit of work still exists to count. And it preserves the trust the record has earned, since nothing the model does can reach the record without a person in between.

The costs arrive later, in three places the research has already mapped.

The first is integration debt. Sculley and his co-authors at Google described in 2015 how "a massive amount of supporting code is written to get data into and out of general-purpose packages," and estimated that "a mature system might end up being (at most) 5% machine learning code and (at least) 95% glue code."⁵ Their conclusion was that it "may be less costly to create a clean native solution rather than re-use a generic package." That paper is about classical ML systems. A model bolted onto an application built for humans has the same shape: the glue is the prompt assembly, the context retrieval, the output parsing and the UI that turns a suggestion into a form field. Their CACE principle, "Changing Anything Changes Everything," is why the second and third bolt-on features cost more than the first.

The second is that the bolt-on does not learn. MIT's 2025 study of enterprise generative AI, drawn from 52 interviews, 153 survey responses and 300 public initiatives, found that "95% of organizations are getting zero return," and located the cause in what it called the learning gap: "Most GenAI systems do not retain feedback, adapt to context, or improve over time."⁶ A model in the read path cannot learn from what happened to its suggestion, because the person's edit is never fed back; the system was not built to record it. A model in the write path sees the exception queue, and the exception queue is training data.

The third is the one the economists measured. Brynjolfsson, Rock and Syverson's productivity J-curve paper shows that a general-purpose technology "enable[s] and require[s] significant complementary investments, including co-invention of new processes, products, business models and human capital," and that for AI the intangible investment runs "between roughly 2.7 and 4.1 times the observable investment values."⁷ Bolt-on is the strategy of skipping that investment. It books the measurable gain now and forgoes the restructuring that carries the larger one.

Michael Hammer wrote the operator's version of this in 1990, before any of the current models existed. Companies "leave the existing processes intact and use computers simply to speed them up," and his instruction was: "It is time to stop paving the cow paths."⁸ His example was Ford's accounts payable, which "employed more than 500 people" and had targeted a 20% cut through automation, until Ford discovered Mazda's equivalent department "consisted of a total of 5 people." Ford changed the unit of work, matching the receipt against the order instead of processing the invoice, and "achieved a 75% reduction in head count, not the 20% it would have gotten with a conventional program." The technology was a database. The gain came from the redesign.

The same model, two units of work

The cleanest current test is two products that call the same class of model and chose different units of work.

GitHub Copilot put completions inside existing editors, kept the file as the unit and the developer as the writer, and by April 2026 had "4.7 million paid subscribers and 90% adoption among the Fortune 100."⁹ Cursor built the environment around the model instead, as "an AI coding agent and software development environment" that can "search across a codebase, edit files, run terminal commands, and carry out multi-step programming tasks from natural-language instructions," with the developer reviewing what it wrote.¹⁰ It went "from zero to $2 billion ARR in roughly three years" by February 2026, "the fastest-scaling B2B software company on record."⁹ Both are successes. The distribution went to the bolt-on; the growth rate went to the product that changed what a unit of work was.

What this looks like on a real decision

At Certivo the unit of work is a compliance decision on a part: given a supplier's documents and a rule set, is this part cleared to ship into this market. The bolt-on version of that product would put a model beside the existing checklist so the analyst fills it in faster. We built the other thing. The model reads the supplier's documents and the applicable rules, writes a decision with the evidence extracted from the document and a confidence, and if the decision clears the policy threshold, that is the record. The analyst owns two things: the policy that sets the threshold, and the exception queue where the model could not reach it. The auditor, when they come, reads the evidence attached to each decision, not a transcript of a chat.

Two consequences follow that a bolt-on cannot produce. The exception queue tells us which document types and which rules the model handles badly, so the system's weaknesses are measured rather than guessed. And the throughput is the model's, with a person's time spent only where it earns something.

The strongest objection

The best case against building native is that it is a rewrite, and the industry has one durable rule about rewrites. Joel Spolsky called rewriting from scratch "the single worst strategic mistake" a software company can make, because old code "has been used. It has been tested. Lots of bugs have been found, and they've been fixed," and Netscape spent three years on a rewrite while its share fell.¹¹ A record that customers trust is exactly the kind of code he means. Throwing it away to put a model in the write path destroys the one asset the incumbent had.

He is right, and the answer is that native does not require it. The record stays. The permissions stay. What is rebuilt is the unit of work around the record: what writes to it, what evidence must accompany a write, and where a person sits. That is a smaller rebuild than a rewrite and a larger one than a panel.

The second objection is older. Lisanne Bainbridge's "Ironies of Automation" observed in 1983 that "the designer who tries to eliminate the operator still leaves the operator to do the tasks which the designer cannot think how to automate," and that "it is impossible for even a highly motivated human being to maintain effective visual attention towards a source of information on which very little happens, for more than about half an hour."¹² A native system that leaves people watching a stream of model decisions has recreated her problem. The exception queue is the answer, and only if it is designed as work rather than as vigilance: bounded, prioritized, and fed back into the policy.

The third is the market. Menlo Ventures' 2025 survey of about 500 enterprise buyers found that "76% of AI use cases are purchased rather than built internally," and that startups "captured nearly $2 in revenue for every $1 earned by incumbents," 63% of application spend.¹³ Read one way, buyers are choosing native products from new vendors. Read the other way, incumbents with bolt-ons still hold 37% of a market that tripled in a year, without a rebuild. Both readings are true, and neither settles the question for a given company.

What the CEO or CTO actually decides

Three questions decide it, and none of them is "how good is the model."

Is the record the product, or is the work the product? If customers pay for the record, the ledger, the system of record, the audit trail, bolt on. The model makes the record cheaper to keep, and nothing you do can be allowed to compromise it. If customers pay for the work that produces the record, the review, the classification, the decision, then someone will rebuild the unit of work around the model, and it is better that it is you.

Can the model's output carry its own evidence? A write path requires that every decision arrive with the evidence that justifies it and a confidence a policy can act on. If the model cannot produce that in your domain yet, it belongs in the read path until it can. It is a capability test.

Where will the exceptions go? A native design is only as good as its exception queue. If the answer is "the same team, on top of their current work," the design will fail the way Bainbridge described. If the answer is a role whose job is the queue and the policy, the design can hold.

The failure mode I see is the company that answers the first question correctly, work is the product, and then builds a panel, because the panel is what the roadmap could absorb this quarter. It will show up in the numbers for a year. Then the company that changed the unit of work will show up in the numbers instead.

— Kunal