Users Keep Telling You They Don't Want More AI in the Product

Your users are not asking for more AI. They keep saying it, in adoption numbers and in dating apps and in the small ways they route around your shiny new feature. Meanwhile the whole industry is arguing about how to build AI better, faster, and with more taste. Let me catch you up on where the real fight is, because it isn't where the noise is.

The bolt-on nobody opens

Start with the plain fact: shipping AI does not make people happy. Smashing Magazine put it bluntly: AI is not a value proposition, and many AI features land with low adoption and high delivery cost. The reason is simple. A bolt-on feature pulls people out of the workflow they already know and adds one more system to hop into and out of.

There's a hidden tax too. Asking AI to draft something feels faster, but then you skim the output, hunt for the key points, verify each one, and regenerate. People feel that cost. They compare your feature to a feature that just works, not to some imperfect human, and they pick the one that behaves the same way every time.

AI is also good at exposing your mess. It amplifies bad data, technical debt, and conflicting priorities, then hands the confusion straight to the user. If your flow was already fragmented, AI makes that visible instead of fixing it.

The ick is real, and it's about effort

The resistance isn't only in enterprise dashboards. It shows up in how people judge each other. Match Group's research found 51 percent of women aged 18 to 24 would refuse to date someone who uses an AI companion app. One woman, Beth, ghosted a guy after four dates when she spotted an AI-generated doll on his Instagram and started to wonder if his charming opener was written by a bot.

The deeper read is worth your attention. Couples' therapist Joanna Harrison points out that intimacy builds when someone shows they made an effort to understand you. When AI does the work, the effort signal disappears. People praise AI for requiring less effort, but in relationships, and in products people care about, effort is the point.

Translate that to your team. When a user senses AI did the thinking instead of helping them think, trust drops. The tool that saves them a click can still cost you their confidence.

Where AI actually earns its place

So where does it work? When AI takes over the boring, draining tasks and leaves people the part they find rewarding. Smashing's take, echoing writer Bo Young Lee, is that the good AI is "AI-second": subtle, ambient, sitting in the background of dull work instead of announcing itself. It has to match the mental models people built over years, not force them to change how they think.

This is also why the framing has shifted. Towards AI argues that AI is turning into infrastructure, the layer under the app rather than a chatbot bolted on the side. Their practical advice is the useful part: start with one repetitive task, prove it, then scale. Not a swarm of agents. One boring job done well.

The test is old and still holds. Frank Chimero's line, quoted by SAP's Arin Bhowmick, is that people ignore design that ignores them. The desktop metaphor passed that test for forty years. New AI patterns haven't earned that trust yet.

The interface is how people stay accountable

Here's a shift worth planning for. AI is moving software from task-driven, where you operate every step, to intent-driven, where the work starts after you state what you want. Bhowmick describes systems that listen, talk, and work at the same time, with no turn-taking. That breaks the interface conventions you've relied on.

Don't let anyone tell you the screen is going away. Where a human is accountable for the outcome, the UI is the instrument of that accountability. It's how someone sees what the system did and steps in to fix it. Models have real gaps: Bhowmick cites a TCS Research paper showing the strongest models estimate task duration four to seven times too high and can't say how long their own work took. A model can lay out a settings panel in seconds, but whether it belongs in front of an admin managing ten thousand seats is a judgment it can't make. Route those calls to a person.

And the patterns are unsettled. Patrick Neeman's playbook compares this to 1999, when a site worked in one browser and broke in the next. Today a workflow works in one assistant and falls apart in another. His lesson from Jeffrey Zeldman's web standards fight: lead with cost and reach, not virtue. Shared, documented patterns are cheaper than a fresh pile of one-offs per product.

The deep cut

The trap isn't building AI badly. It's building the wrong thing, fast, with total confidence. Dan Maccarone sat with a company that spent two and a half years and four rebuilds and still couldn't tell him who they were building for. AI made building so cheap that nothing forced them to stop and check the idea. When building was expensive, a budget forced a decision. Now the cost doesn't vanish, it moves onto your team as an endless fire drill, and the good people leave first.

So the practical move is to spend your saved build time on the question building used to force: who is this for, and why would they want it. Andrew Bosworth's north star after twenty years is embarrassingly plain, find a human with a problem and ask if you can solve it. Craft and standards make sure the thing gets made well. They can't tell you it should exist. Put your review energy on the decision, not the demo.

Three questions for your team

1. For every AI feature on the roadmap, can you name the one boring, draining task it removes, and would a user still choose it over doing the work by hand? If not, cut it.
2. Where does your AI hand judgment back to a person, and can that person see what the system did and undo it? Name the review point, don't assume it.
3. Before the next build cycle, who exactly is this for and why would they want it? If you can't answer that in a sentence, you're sharpening a knife for a gunfight.