There is a button we keep seeing in products lately. It says something like "Ask AI" or has a little sparkle icon, and it sits in the corner of an app that did not need it. You click it, a panel slides out, and it does roughly what the search bar already did, except slower and with a confident wrong answer about one time in five.
Somebody on that team had a meeting where the phrase "we need an AI strategy" came up, and three sprints later this is what shipped. It is not helping anyone. It is making the product heavier and the cloud bill bigger, and the people who built it know it, but the button is there now and nobody wants to be the one who says it should go.
I want to make an argument that will sound strange coming from a firm that builds AI systems for a living. Most of the AI being added to products right now is making those products worse, and the teams adding it would be better off doing almost nothing instead. The useful applications of this technology are real and they are large, but they look almost nothing like the sparkle button, and the gap between the two is where a lot of money is currently being set on fire.
Start with what the sparkle button actually costs. Every one of those calls goes to a model, and that model charges per token and takes a second or two to respond, sometimes much longer under load. So you have taken an interaction that used to be instant and deterministic, a search, a filter, a form, and replaced it with one that is slow, non-deterministic, and metered. The user notices the slowness immediately. They notice the wrongness eventually, and once they catch the feature being confidently wrong even once, they stop trusting it for everything, including the things it was good at. You did not add a feature. You added a tax on latency and a small ongoing erosion of trust, and you are paying a vendor every month for the privilege.
The deeper problem is that a language model is being asked to do a job it is bad at. A model is bad at being a precise interface to structured data. If your user wants to see all invoices over fifty thousand rupees from last quarter, a filter does that perfectly, instantly, every time. Asking a model to interpret "show me the big invoices from a while ago" and translate it into a query is strictly worse: it is slower, it can misread "big" or "a while ago," and when it gets it wrong the user has no idea whether the empty result means no invoices or a misunderstanding. You took a solved problem and made it probabilistic. That is not progress. That is a downgrade with better marketing.
So where is the actual value, then? Because it is real, and it is worth being precise about.
The technology is genuinely good at a specific shape of problem: taking messy, unstructured, human input and turning it into something structured, or the reverse, taking structured information and turning it into fluent human output. That is the whole game. Everything that works lives in that shape, and everything that fails is usually a case of using it for something else.
A support team drowning in tickets, where a model reads each incoming message, summarizes it, tags it, and routes it to the right queue, that works, because the input is genuinely messy human text and the old alternative was a person reading every ticket by hand. A contract review tool that pulls the renewal dates and liability clauses out of a hundred-page PDF, that works, because extracting structure from unstructured documents is exactly the thing the technology does well and the manual version is genuinely painful. A system that watches a stream of events overnight and writes a plain summary of what changed by morning, that works. Notice what these have in common. The AI is doing work that was previously done by a human reading and interpreting text, slowly, at scale. It is not sitting between the user and a database pretending to be a better query language.
We worked on a module inside a larger operations platform where the job was exactly this kind of thing, watching a lot of incoming signals and producing a short readable account of what mattered. It was useful because the alternative was an analyst scrolling through dashboards every morning trying to spot what had moved. The model was not the product. It was a quiet layer doing one specific interpretation task that humans found tedious and slow. Nobody clicked a sparkle button. They just got a better morning briefing than they had before, and most of them probably did not think about the fact that a model wrote it.
That is the tell, actually. The good applications are usually invisible. The user does not interact with "the AI," they just notice that something tedious got easier or something slow got faster. The bad applications announce themselves with a logo and a chat box, because the chat box is the feature, and the feature exists to be seen rather than to be used.
Here is the uncomfortable part for anyone who has already shipped the button. Ripping it out is usually the right call, and it is hard to do politically. Someone championed it. There may be a slide deck where it is a headline. Killing it feels like admitting the AI strategy was wrong, when in fact killing it is the AI strategy working correctly, because a real strategy includes deciding where the technology does not belong. The teams that win with this stuff are not the ones who added the most AI. They are the ones who were ruthless about adding it only where it earned its slowness and its cost, and who left the rest of the product fast and deterministic and boring, the way good software mostly should be.
I will be fair to the other side, because there is one. Sometimes the sparkle button is not about utility at all, it is about positioning, and positioning has real value. If you are raising a round and every competitor has an AI story, having nothing can cost you more than a slightly useless feature costs you. If your buyers have been told by their board to "adopt AI" and your product gives them a checkbox that lets them say yes, that checkbox might close deals even if usage is low. That is a legitimate reason to ship something, but you should at least know that is the reason, and you should keep that feature cheap and isolated so it does not slow down the parts of the product people actually use. The mistake is not shipping a positioning feature. The mistake is confusing it for a utility feature and then being surprised when nobody uses it.
There is also a real cost to doing nothing, and I do not want to pretend otherwise. The technology is improving fast, and the teams that have built up real experience with it, real pipelines, real evaluation, real understanding of where it breaks, will move faster when the genuinely valuable applications in their domain become obvious. Sitting it out entirely means learning all of that under pressure later. So the answer is not "avoid AI." The answer is to spend your effort on the unglamorous internal version, the ticket router, the document extractor, the overnight summarizer, where you learn how the technology actually behaves on your real data, instead of spending it on the customer-facing button that teaches you nothing except how to annoy users.
If you strip away the hype, the decision is not complicated. Before adding a model to anything, ask whether the task is really about interpreting messy human input or generating human output, and whether the old way was genuinely slow or painful. If yes, it is probably worth the latency and the cost. If the task is precise, structured, and already fast, the model will make it worse, and the honest move is to not add it, no matter how much the icon would look good in the next demo.
It helps to run a cheap test before committing engineering to any of this. Take the feature you are imagining and write down, in one sentence, what the user is trying to accomplish and how they do it today. Then write down what breaks if the model gets it wrong, and how the user would even know. A support-routing tool fails softly: a ticket lands in the wrong queue, someone notices, they move it, mild annoyance. A model that auto-approves expense reports fails hard: money goes out the door against a wrong reading, and nobody catches it until the audit. The softer the failure and the messier the input, the better a candidate it is. The harder the failure and the more structured the input, the more you should leave it alone. This takes an afternoon and saves you a quarter.
The other test is honesty about the baseline. People compare the shiny AI version against nothing, as if the choice is "AI feature or empty space." It almost never is. The real comparison is against the boring deterministic thing you could build in a week: a good filter, a saved view, a scheduled report, a well-designed form. A lot of features that look like they need a model are really just admitting that the existing interface was bad. Fixing the interface is cheaper, faster, and does not cost you per token forever. If a better-designed search bar would solve eighty percent of what the "Ask AI" panel was for, build the search bar. It will be faster and it will never hallucinate.
The companies that figure this out will end up with products that feel fast and trustworthy, with a few quiet places where AI does real work behind the scenes. The ones that do not will end up with slow, chatty, expensive products covered in sparkle buttons that everyone clicks once and never again. Right now far more teams are heading toward the second outcome than the first, which is strange, because the first one is cheaper to build.
We spend a fair amount of our time talking clients out of the button and toward the boring useful version. It is rarely what they walked in asking for. It is usually what they needed.