Blog / UX & Design

The AI Bolting Problem: Why Your Product Needs Surgery, Not a Paint Job

Most teams are adding AI as a feature. They should be redesigning everything around it.

Juan David Avellaneda May 3, 2026 4 min read 12 views
The AI Bolting Problem: Why Your Product Needs Surgery, Not a Paint Job

We're Building Worse Products by Playing It Safe

Last month I watched a team spend three weeks integrating OpenAI's API into their dashboard. They added a chat widget to the sidebar. Shipped it. Called it innovation. The actual users? They never opened it. The feature sat there like a decorative plant in a waiting room—present, but solving nothing.

This happens everywhere. Companies treat AI as a coat of paint instead of structural steel. But here's what bothers me: I'm not entirely sure where the line is between thoughtful integration and over-engineering. Maybe some products genuinely don't need ground-up redesign. Maybe a chatbot sidebar is exactly right for some use cases, and I'm just cynical because I've seen too many failed implementations.

  • The quick integration path: bolt API onto existing interface, hope for adoption
  • The honest realization that rethinking architecture takes 4x longer and your CEO wants features this quarter, not next year
  • Starting from scratch
  • The question nobody asks: what if AI isn't the answer to this problem at all?

Design Thinking Doesn't Stop at the Wireframe

When I work on products with AI components, the first mistake I see is treating design as finished before the model arrives. You mock up screens. You hand off specs. Then engineering bolts in the AI layer and suddenly your carefully considered user flows don't work anymore because the latency changed, or the output format doesn't fit your layout, or the model hallucinates and your UI has no recovery state designed for that.

The second mistake is worse: assuming users understand what the AI can actually do. At a startup I consulted with in 2023, they built a predictive analytics feature that was genuinely powerful. Launch happened. Nobody used it. Turned out the interface suggested it was just a filter, not a reasoning engine. The mental model was broken from pixel one.

Real integration means designing backwards. Start with: what behavior are we trying to change? What does the user need to do differently? Now—not later—figure out if AI makes that possible. I'm not sure this always leads to AI being the answer, honestly. Sometimes it's just better information architecture. Sometimes it's better copywriting. Sometimes it's acknowledging your product was solving the wrong problem.

The Architecture Conversation Nobody Wants to Have

From a technical side, bolting on AI means your database schema was built for a world without real-time inference. Your API wasn't designed for streaming responses. Your error handling doesn't account for model uncertainty. These aren't small things you patch later—they're foundational decisions that either exist or they don't.

Take Figma's AI features. They rethought their entire infrastructure to support real-time generative design. They didn't add a button that calls an external API. It took months. It required new data pipelines, new thinking about how design files flow through their system. The result doesn't feel bolted on because it wasn't.

The cost of this is brutal: slower time-to-market, more complex engineering, more uncertain outcomes. You're betting that rethinking everything will actually matter to users. Sometimes it won't. Sometimes you'll spend eight weeks rebuilding and users still want the sidebar chatbot because that's what they're used to from ChatGPT. I genuinely don't know how to predict which outcome you'll get until you build it.

  • Rewriting your data pipeline while shipping other features
  • The engineering debt you're creating by not doing this, compounding quarterly until the system is unmaintainable
  • Explaining to your board why timeline just doubled

What Actually Changes When You Redesign

The honest answer is: sometimes nothing obvious. The user experience might look similar. But underneath, the system handles edge cases. It's built for iteration. The model's limitations are baked into the design instead of treated as bugs.

And sometimes everything changes. The product becomes something different. You discover workflows that weren't possible before. You also discover you've overbuilt for a need that turns out to be smaller than you thought.

There's no framework for this. No checklist that tells you whether your product needs surgery or just a widget. You have to think through it honestly, which takes time, and involves admitting uncertainty, and probably requires rebuilding things twice.

That's the part they don't sell you in the AI startup pitch.

#AI integration #product design #UX strategy #technical architecture #design thinking

Was this helpful?

Juan David Avellaneda

Juan David Avellaneda

Innovation Specialist · Bogotá, Colombia