The AI Taste Gap
Why most AI features feel robotic even if they work?
Recently, a founder showed me his new AI feature.
It worked. The model was state-of-the-art. Integration was clean. Latency was good. On paper, it looked exactly like what his competitors were shipping.
In the first 30 seconds of using it, I knew almost nobody would stick with it.
Not because it was broken. It just felt like a form that had grown teeth.
Over the last year I’ve audited around 40 AI features. Some at funded startups, others inside enterprise tools with millions of users. The pattern is almost always the same:
The model is fine.
The integration is fine.
The brief was generic.
That’s the taste gap. And right now, it’s the single biggest reason AI features ship but don’t land.
You’ve felt this before
The “AI summarize” button that spits out the same four bullet structure whether you gave it a meeting transcript, a legal contract, or a love letter.
The AI assistant that opens every reply with “Great question!” even when the question was “what is two plus two”?
The writing tool that offers three variations of the same sentence, each one a little more corporate, gently sanding your voice down until you sound like middle management.
The sales coach that scores your call and tells you to “build rapport”. Something you already knew.
None of these are technically broken. They demo well. They look good in pitch decks.
But they are also why most people try an AI feature once and never come back.
What’s actually wrong
It is tempting to blame the model. Or the prompt. Or the context window.
But after building enough of these myself, I can tell you the model is almost never the real bottleneck. The bottleneck is upstream. In the brief.
Most teams ask: “What can AI do here?”
The better question is: What is this human actually trying to do, and where can AI quietly help?
A generic brief produces a generic feature, no matter how good your tech is.
A taste aware brief creates something that feels thoughtful. Even with a simpler model.
This is the part most teams skip. They spend weeks debating models and RAG architecture, but rarely spend a full afternoon watching real users, mapping their actual flow, and understanding where they get stuck.
The features that feel premium almost always come from teams who did that work first.
What good looks like
One SaaS founder I worked with had an onboarding flow bleeding users.
40 percent drop off in the first session.
They had added an AI chatbot in the corner. It worked. Nobody used it.
We rebuilt it with the same model and same data, but a very different brief.
The new version did not announce itself. It quietly watched. When the user typed something that conflicted with a previous answer, it gently surfaced the conflict inline. When someone paused for more than 12 seconds on a field, a small, specific hint appeared. Written for that exact moment.
No “Hi, I’m your AI assistant.” Just a form that felt unusually patient and smart.
Onboarding completion jumped from 60% to 85%.
Another time, I worked with a newsletter creator burning out at 25 hours a week on research and writing. Instead of building a generic writing assistant, we created a system that watched what she read, saved, and eventually published. It learned her taste by noticing what she rejected in drafts.
Her new drafts started showing up with her thinking, not a model’s approximation. She dropped to 7 hours a week. Output tripled. Readers couldn’t even tell where the AI helped.
In both cases, the AI did less. But the right less.
Human flow first, AI second
This is the principle I keep coming back to.
Map the work as if AI didn’t exist. Sit with the actual human doing the job. Watch where they pause, where they abandon, where they get frustrated or embarrassed. Only then ask where AI can help.
When teams reverse this order, the feature feels robotic. Like AI was the answer looking for a question.
When they honor it, the feature feels designed. Like it was built by someone who truly respected the work before bringing in the technology.
The order matters more than the model.
What this means in practice
If you’re about to ship an AI feature, ask these three questions before you write a single prompt:
What does this person actually do today, without AI?
Where in that flow do they pause, abandon, or do something they’re not proud of?
What’s the smallest, quietest thing AI could do to remove that friction? Without announcing itself?
Answer the first two deeply, and your feature has a real chance of being used. Skip them, and no model will save you.
This is the bet I’m making with everything I build now.
The AI features that win the next decade won’t be the ones with the biggest models or the loudest demos. They’ll be the ones that feel like they were built by someone who cared enough to do the unsexy work first.
Taste isn’t a vibe. It’s a brief.
I’m pouring everything I’ve learned from the last 8 months into SketchSprint, my one-person studio where I consult, architect, and ship production AI systems end-to-end for founders and teams who want their AI to actually move business metrics.
If you’re thinking about an AI feature and want a second pair of eyes on the brief before you build, my DMs are open.
If this resonated, the next essay drops soon: a real “taste-aware brief” template you can steal. Subscribe so you don’t miss it.
Mansukh Kaur
Founder, SketchSprint
sketchsprint.dev | linkedin.com/in/mansukh-kaur
About the author
Mansukh Kaur is the founder of SketchSprint, a one person studio building production AI systems for founders and teams who want their AI features to actually move a business metric.
She ships something working every week in public. Read more at sketchsprint.dev or DM her on LinkedIn at linkedin.com/in/mansukh-kaur.