When AI Should Be a Feature, Not the Product

A language model that answers a prompt is not a product. It is a capability. The product is the job a person is trying to finish: a record updated, a message drafted, a decision recorded, an exception handled. If that job is not clear, adding a model only adds a new way to be uncertain.

This distinction is worth making before anyone opens a design tool. AI belongs in software when it improves a specific step that already has an owner, an input, and a consequence. It does not belong there because a competitor announced a feature, or because a blank chat box is faster to demo than a workflow.

Deterministic software and AI do different jobs

Most business software is deterministic on purpose. Given the same inputs and the same rules, it produces the same result. An invoice total, a permission check, a status change, a booking that either exists or does not. People rely on that repeatability. They can explain it, test it, and reverse it.

A model does something else. It estimates. It is useful when the input is messy and a perfect rule would be longer than the process it is meant to help: sorting unstructured requests, drafting a first version of a routine note, suggesting a category, pulling fields out of a document that does not follow a template. The output is a proposal, not a fact, until something in the system treats it as one.

Confusing the two creates products that feel impressive in a walkthrough and unreliable on an ordinary afternoon. The person using the software cannot tell which parts of the screen are rules and which parts are guesses. When a guess is wrong, there is no obvious place to correct it, and the next run may not fail in the same way.

Reliability is a product decision

A feature is allowed to be probabilistic only if the product can absorb a wrong answer. That depends on the cost of the error, how quickly someone will notice it, and whether the system keeps a record of what happened.

Some errors are cheap. A suggested tag that can be changed before saving is cheap. A drafted reply that stays in a compose box until a person sends it is cheap. A summary shown next to the source text is cheap, because the source is still there to check.

Other errors are not. A payment amount, an access decision, a record deleted, a message sent to a customer with no review. Those steps need a rule, a person, or both. Wrapping them in a model because the interface looks current does not reduce the cost of being wrong. It hides the moment where a decision was made.

Reliability also includes silence. Models fail by answering. Ordinary bugs often fail by stopping. A stopped workflow is frustrating and visible. A confident wrong result can travel further before anyone notices. Design for that. Show uncertainty where it exists. Refuse to invent a value when the input is missing. Prefer a clear “needs review” state over a polished guess that looks finished.

Human review is part of the system

“A person checks it” is often a sentence added at the end of a proposal. In a real product it is a set of screens, states, and responsibilities.

Someone has to see the suggestion in the place where they already work, not in a separate chat they will not open under time pressure. They need enough context to judge it without redoing the entire task. They need a direct way to accept, edit, or reject. The rejection has to stick. The record should store what was proposed, what was kept, and who confirmed it. If accepting is one click and fixing is a scavenger hunt, people will accept, including when they should not.

Review also has a volume problem. If the model touches every item and a person must inspect every item, the feature has added work. Leverage appears when review is reserved for low-confidence results, high-impact actions, or a sample used to watch quality. The rest can follow a rule. That split should be visible in the interface. A confidence number that nobody was trained to interpret is not a review process.

Where AI creates leverage

The useful cases tend to look ordinary, which is a good sign.

One is turning unstructured input into structured fields a workflow already understands, with the original text kept beside the result. The operator checks the fields. The workflow continues on data, not on a paragraph.

Another is drafting the repetitive writing people already produce from a template: follow-ups, internal notes, handover summaries. The draft saves keystrokes. The person still owns the send. The product should make that ownership obvious, with the draft clearly marked and the send action unchanged.

A third is finding and grouping information that does not fit a tidy filter. Similar past cases, related documents, requests that are about the same issue even when the wording differs. The result is a shorter search, not an automatic decision.

A fourth is assisting a judgment that remains a person’s judgment: ranking a queue, highlighting what changed, pointing at the passage that matters. The ranking is not the approval. The highlight is not the conclusion.

These features earn their place because they remove a specific kind of effort inside a process that already has a definition of done. The model is not the thing being bought. The finished process is.

Where ordinary software is the better tool

If the rule can be written down, write it down. Validation, permissions, calculations, state changes, schedules, and limits should stay deterministic. They are easier to test, easier to explain, and easier to defend when something goes wrong. A model that “usually” applies a discount is not a pricing system.

A chat box is a weak interface for a known workflow. People should not have to remember how to ask for a status change that the product could offer as a button with the right guards. Natural language is a reasonable escape hatch for the long tail of odd requests. It is a poor replacement for the handful of actions that make up the day.

AI is also the wrong layer for the source of truth. Do not let a generated summary become the only copy of a decision. Store the decision as data. Generate a view from it when a view helps someone read faster.

And do not add a model to compensate for a missing workflow. If nobody owns the next step, a suggestion has nowhere to land. Fix the operation first. Then ask whether a model removes effort inside it.

Place it like any other feature

Treat the model as a dependency with failure modes, cost, and latency. Give it a boundary: what it may read, what it may propose, and what it may never commit on its own. Log the proposal and the outcome. Watch whether people accept, edit, or ignore the result. If they ignore it, the feature is not creating leverage, however convincing the demo was.

Start with one step. Put it next to the existing control, not in a new surface that competes with the workflow. Expand only when the correction rate and the time saved justify the operational cost: the prompts or configuration, the monitoring, the reviews, and whatever infrastructure or provider sits behind the call.

The test is simple. Remove the model in your head and ask what job remains. If the job is still coherent, the AI was a feature. If nothing remains except the conversation, there is not a product yet. There is a demonstration waiting for a workflow.