Why Various LLM Smells Keep Breaking Production Launches

We’ve seen this movie before.

A team demos an LLM feature on Thursday, everyone claps, somebody says “we’re basically done,” and by Monday the thing is either hallucinating refund policies, calling the wrong tool, leaking internal prompts into logs, or burning money like a V8 engine with a hole in the fuel line.

The weird part is that the failure usually wasn’t hidden. It smelled bad the whole time.

That’s the useful part of the phrase various llm smells. Not because it’s cute. Because it gives engineers a practical way to talk about early warning signs before those signs turn into production incidents. The original framing from Shvbsle’s post is simple and sharp: LLM systems often exhibit recurring “smells” that hint at deeper design problems, much like code smells do in software engineering Shvbsle.

And yes, we think this framing is better than another fluffy “best practices” article.

Because “best practices” don’t help when your agent confidently books the wrong room type.

Key Takeaways

• Various LLM smells are early indicators of prompt, retrieval, tool, eval, or guardrail problems — treat them like failing tests, not vibes.
• If your team can’t map a smell to a measurable check, you’re still in demo mode.
• Prompt quality alone won’t save a weak system; most production failures come from orchestration, missing constraints, and bad eval coverage.
• The fastest way to ship safer LLM products is to turn smells into a production readiness checklist.
• Hot take: if you haven’t built evals before polishing prompts, you’re decorating a house with a cracked foundation.

The Smells Aren’t the Problem. They’re the Smoke.

The Shvbsle article does a nice job naming recurring issues in LLM behavior and design, and that matters because unnamed problems tend to survive way too long in sprint boards Shvbsle.

We’d put those various llm smells into four buckets:

1. Prompt smells — the model needs psychic powers because your instructions are vague, conflicting, or brittle.
2. Eval smells — the team is judging quality from cherry-picked examples and founder demos.
3. Tooling smells — the model has access to tools but no real policy for when or how to use them.
4. Production smells — logging, fallback behavior, cost controls, latency budgets, and safety checks were apparently “future work.”

That last one is where launches go to die.

Here’s the trap: teams often treat weird model behavior as a model problem. Sometimes it is. Usually it’s a system design problem wearing a model-shaped hat.

The First Smell: “It Works on My Prompt”

We hate this one because it looks like progress.

Somebody on the team has a magical prompt in a private Notion page. It works beautifully for three examples. Then it hits production traffic, where users type like raccoons fighting over a keyboard, and the whole thing falls apart.

That’s not a prompt. That’s a stage prop.

A prompt smell usually shows up as one of these:

• Instructions spread across system prompt, hidden middleware, and tool descriptions with contradictions
• Output format compliance that drops the second the input gets messy
• Prompt length growing every sprint like a junk drawer nobody wants to clean
• “Few-shot fixes” added without understanding why the model failed

We’ve tried the giant-kitchen-sink prompt approach before. It was a disaster. Every new edge case made the prompt longer, slower, and more fragile. The model didn’t become smarter. It became more confused, just with better formatting.

Prompt readiness checklist

Before launch, check these:

• Is there one canonical system instruction set, versioned and reviewed?
• Are constraints explicit, testable, and placed in the highest-priority prompt layer?
• Does the model know when to say “I don’t know” or ask a clarifying question?
• Are output schemas enforced with structured generation or validation?
• Have you tested prompt behavior against adversarial, incomplete, and noisy inputs?

If not, you don’t have prompt engineering. You have prompt folklore.

Here’s a simple way to think about it: prompt design is like writing a recipe for a tired line cook during a dinner rush. If the instructions are ambiguous, you’re getting chaos with garnish.

Before we get into evals, here’s the architecture smell map we use mentally:

Why Your Evals Are Probably Theater

This is the most expensive smell because it creates fake confidence.

A lot of teams say they’ve “tested” their LLM feature. What they mean is they ran ten handpicked prompts, saw eight decent outputs, and called it validation. That’s not evaluation. That’s fan fiction.

The Shvbsle framing is useful here because smells should trigger checks. If the system feels brittle, inconsistent, or oddly confident, you need evals that expose those failure modes, not a prettier demo Shvbsle.

Our hot take: manual spot checks are overrated after week one.

They’re fine for discovery. They’re terrible for release decisions.

Turn smells into eval categories

If you notice a smell, create a corresponding eval set:

• Overconfidence smell → cases where the answer should be refusal, uncertainty, or escalation
• Instruction drift smell → long-context tests with conflicting user intent
• Tool obsession smell → prompts where tool use is unnecessary and should be avoided
• Tool avoidance smell → prompts where a tool is required for correctness
• Retrieval perfume smell → the answer sounds polished but ignores source evidence
• Latency panic smell → worst-case tool chain and long-context load tests
• Cost leak smell → repeated multi-turn sessions with token and tool usage budgets

That’s the shift. Don’t ask “is it good?” Ask “what kind of bad is it, and can we measure that bad repeatedly?”

Here’s how that flow should work:

flowchart TD
  A[Observed LLM smell] --> B[Name the failure mode]
  B --> C[Create eval set]
  C --> D[Define pass/fail threshold]
  D --> E[Ship guardrail or prompt/tool fix]
  E --> F[Re-run evals before release]

Simple beats clever.

And yes, this applies whether you’re building AI agents, internal copilots, or customer-facing assistants.

The Tool-Use Smells Get Weird Fast

Tool use is where impressive demos become expensive outages.

A model that can call APIs, search docs, update records, or trigger workflows is useful. It’s also one bad policy away from becoming an intern with production access and no supervision. Charming in theory. Terrifying in practice.

The common smells:

• It calls tools when a direct answer would do
• It refuses to call a tool even when freshness matters
• It chains too many tools because “more reasoning” looked sophisticated in testing
• It passes malformed arguments
• It invents fields that your backend never defined
• It retries bad actions with confidence instead of escalating

We’ve found that teams often over-index on model selection here. They argue about GPT vs Qwen vs whatever is trending, while the real issue is that tool contracts are sloppy and the execution policy is barely a suggestion.

That’s backwards.

Tool-use readiness checklist

Before launch:

• Define tool eligibility rules: when must the model call a tool, and when must it not?
• Validate arguments with strict schemas before execution
• Add idempotency protection for mutating actions
• Separate read tools from write tools
• Require confirmation for destructive or irreversible actions
• Log tool decisions, inputs, outputs, and failures
• Add fallback behavior when tools time out or return partial data

If you’re building voice systems, this gets even more sensitive. In voice AI, a bad tool call isn’t just wrong — it’s wrong out loud, in real time, to a human who’s already annoyed.

That’s why on-device and tightly scoped systems can be the smarter choice in some environments. For products like RunHotel, or broader on-device AI deployments, narrower execution paths often beat “general intelligence” every day of the week.

Retrieval Smells: When RAG Lies Politely

RAG has a special kind of failure mode: it sounds sourced.

That’s what makes it dangerous.

A retrieval pipeline can fetch irrelevant chunks, stale policies, duplicated passages, or half-matching documents, and the model will still produce something smooth enough to pass a casual glance. It’s like a student citing three books they clearly didn’t read.

We’ve seen teams celebrate citation support while ignoring citation quality. Bad move.

RAG readiness checklist

Check these before you ship:

• Are retrieved chunks actually relevant on difficult queries, not just obvious ones?
• Is chunking strategy tested against your document types?
• Do you deduplicate overlapping context?
• Do you expose source provenance clearly to the model and, where useful, to the user?
• Does the system abstain when retrieval confidence is weak?
• Are stale documents expired or versioned?

If your assistant answers confidently from weak retrieval, that’s not intelligence. That’s autocomplete in a suit.

And if you need domain-specific behavior, this is often where custom models or tighter task-specific pipelines start making sense.

Production Smells Nobody Wants to Own

This is where the grown-up work lives.

A lot of LLM launches fail not because the model is dumb, but because the ops around it are childish. No cost budgets. No rate limiting. No fallback path. No red-team prompts. No monitoring for drift. No human review lane for high-risk actions. Just vibes and a launch date.

We’re opinionated here: if you don’t have production guardrails, you don’t have a product. You have a demo with invoices.

Production readiness checklist

1. Reliability

• Set latency budgets for each step: model, retrieval, tools, post-processing
• Define fallback responses for timeout, model failure, and tool failure
• Add retries only where safe; blind retries can multiply bad actions

2. Safety

• Classify high-risk intents that require refusal or escalation
• Test prompt injection and instruction override attempts
• Filter secrets, PII, and internal chain-of-thought-like artifacts from logs and outputs

3. Cost

• Track token usage per route, feature, and customer segment
• Set budget alerts and hard caps where appropriate
• Compare architecture choices before launch; our AI cost estimator is useful for sanity-checking this stuff

4. Observability

• Log prompts, retrieved context IDs, tool calls, model version, and final outcomes
• Build dashboards around failure categories, not just aggregate success
• Review real conversations weekly, because users will invent failure modes your test set missed

5. Governance

• Version prompts, eval sets, tool specs, and safety policies
• Require release notes for model or prompt changes
• Keep a rollback path that actually works under pressure

Here’s where it gets unglamorous.

That’s also where good systems survive.

A Practical Smell-to-Checklist Table in Plain English

When we help teams through AI consulting, we try to convert fuzzy complaints into engineering actions fast.

If someone says:

• “The model is inconsistent” → check prompt hierarchy, schema enforcement, and eval coverage
• “It’s too expensive” → inspect context bloat, unnecessary tool calls, and model routing
• “It gives polished nonsense” → audit retrieval quality, abstention behavior, and evidence grounding
• “It does the wrong action” → tighten tool permissions, confirmations, and argument validation
• “It was fine in staging” → your test set is weak, your traffic assumptions were fantasy, or both

Usually both.

The Checklist We’d Actually Use Before a Launch

If you want one practical pre-launch pass, use this.

Prompt and behavior

• Canonical system prompt is versioned
• Structured outputs are validated
• Refusal and clarification behaviors are explicit
• Adversarial and messy-input tests pass

Evals

• Eval set covers normal, edge, adversarial, and abstention cases
• Pass/fail thresholds are defined before release
• Regression suite runs on every prompt/model/tool change

Retrieval

• Retrieval precision is manually reviewed on hard queries
• Sources are versioned and stale content is handled
• The model can abstain when evidence is weak

Tools and agents

• Tool schemas are strict
• Write actions require stronger controls than read actions
• Tool timeouts, retries, and fallback paths are tested
• Agent loops are capped

Production guardrails

• Latency and cost budgets are enforced
• Logs are privacy-safe and useful for debugging
• Monitoring covers failure modes, not vanity metrics
• Rollback path is documented and tested

Human operations

• Escalation path exists for risky or unresolved cases
• Support and QA teams know expected failure modes
• Someone owns post-launch review for the first two weeks

That last one matters more than people think.

Because production is where users start free-style jazzing on your carefully designed workflow.

One More Hot Take: Most Teams Don’t Need a Smarter Model First

They need a stricter system.

We’ve watched teams swap models three times to solve what was clearly a prompt contract problem, or a retrieval issue, or a missing tool policy. That’s like replacing your car engine because one tire is flat. Expensive, dramatic, and deeply stupid.

Better models help. Of course they do.

But if you haven’t cleaned up the various llm smells in your architecture, the shiny new model will just fail in more articulate ways.

What to Do Next

Start with your last ten bad outputs.

Label the smell behind each one. Then map each smell to one checklist item: prompt fix, eval case, retrieval change, tool constraint, or production guardrail. If a failure can’t be mapped, you haven’t understood it yet.

If you want help turning that mess into a real release process, that’s exactly the kind of work we do across AI agents, custom models, on-device AI, and production-grade delivery. You can contact us when you’re ready.

Because the goal isn’t to make your demo look smart.

It’s to make your production system boring.

And boring, in this business, is beautiful.

Sources

• Shvbsle — Various LLM Smells