Skip to main content
← All posts
3 min read

Why Your AI Product Feels Broken (Even Though the Model Is Good)

Claude 4 didn't get stupider. Your safety layer is failing. How to identify when the problem is your architecture, not the LLM.

Share

Your CEO paid for OpenAI's best model. Your users see confident nonsense. You blame the model. You're wrong.

Last month, a fintech PM told me their LLM keeps recommending portfolios it invented. GPT-4o in the backend, top-of-the-line inference. The model is smart—the architecture is broken.

The problem isn't hallucination. Hallucination is what LLMs do. The problem is you built no walls around it.

The Architecture Trap

Every LLM has a simple job: predict the next token based on patterns in training data. When you ask it about your proprietary data, historical trades, or company-specific rules, it doesn't know those patterns exist. So it hallucinates—confidently filling gaps with plausible-sounding text.

This isn't a bug. It's the fundamental contract of language models.

The companies shipping AI that doesn't hallucinate aren't using better models. They're using better fences.

What the fence looks like:

  1. Retrieval layer — Your private data gets indexed. The LLM only "knows" what you explicitly give it. No retrieval = no source = hallucination.

  2. Verification layer — Critical outputs (trades, medical advice, legal summaries) get checked by a second system or human before surfacing. This sounds expensive. It's cheaper than the refund.

  3. Constraints layer — The model gets explicit rules: "You can only recommend products from this list" / "You must cite a source for every claim." Not prompts. Actual constraints in the call structure.

  4. Fallback layer — When the LLM's confidence is low, don't show the user a guess. Show nothing, or route to a human.

The fintech company was missing all four. They'd dropped the model in and hoped. That's like shipping a car with a working engine but no brakes.

The Business Impact

PMs think hallucination is a model problem. Engineers know it's an architecture problem. But the cost is always the same:

  • User trust evaporates in one week. Seeing two wrong answers kills credibility.
  • Support tickets spike. Every hallucination becomes a support incident.
  • You can't scale. Every user interaction needs review. The system breaks under load.

The fix isn't a better model. It's a better pipeline.

What This Actually Costs

A solid retrieval + verification stack:

  • Qdrant or Pinecone for vector search (~$100-500/month)
  • A second LLM call to verify outputs (~5-10% overhead)
  • Basic rule enforcement in your application layer (free, just engineering)
  • Maybe one human reviewer for edge cases (depends on volume)

The cost of shipping hallucinations:

  • Legal risk (regulated industries)
  • Churn (users leaving)
  • Engineering time fielding support tickets
  • Reputational damage

Pick one. One costs money. One costs the product.

The Real Question

Before you blame Claude or GPT, ask yourself:

  • Does the LLM have access to the data it needs to answer correctly?
  • What happens when the LLM is wrong?
  • Is there a second check before critical outputs hit the user?
  • Does the user know when the LLM is guessing?

If you answered "no" to any of those, your problem isn't the model. It's the moat you didn't build around it.

The best engineers shipping AI products aren't using better models than you. They're treating hallucination like a network packet loss—not a failure, a design constraint. And they're building the architecture to survive it.

Your model is fine. Your architecture is what needs fixing.

Work with me

I consult with engineering teams on AI adoption, cloud architecture, and engineering effectiveness. If this post surfaced a challenge you're facing, let's talk.

Get in touch →

Explore more on these topics:

Subscribe to new posts

Get an email when I publish something new. No spam, unsubscribe any time.