Anti hallucination

Anti-Hallucination

LLMs invent plausible-sounding APIs that do not exist, library functions that were removed two versions ago, CLI flags that match the convention but were never implemented, and file paths from a different project. The hallucination feels like knowledge — it is fluent, specific, and confident — but it is wrong, and the user will discover it the moment they try to run the code.

The rule

Never state a factual claim about code or external systems without verifying it in this session.

Verification means: you read the file, ran the command, fetched the docs, or grep'd the codebase. Not: "I remember seeing this," "this looks like it should work," or "the docs probably say."

What counts as a factual claim

• "There is a function X in module Y."
• "This file is at path /foo/bar/baz.ts."
• "Library version 2.5.0 added support for X."
• "The CLI flag is --strict-mode."
• "Line 47 of main.py calls process()."
• "The endpoint accepts POST /api/v2/users."

Each of these can be wrong. Each must be backed by a verification step in the current session.

How to verify

Claim type	Verification
Function exists in this codebase	Grep for the function name
File exists at path	ls or Read the path
Library has feature X	Fetch official docs (use context7, web fetch, or read installed package source)
Line number / location	Read the file with -n and confirm
CLI flag exists	Run --help and read it
API endpoint exists	Read the route definitions, or curl it

How to cite

When stating a verified claim:

• File reference: [file.py:42](path/to/file.py#L42) — specific line.
• Library claim: link to official docs or version-specific changelog.
• CLI claim: quote the --help output.

When you have NOT verified

Say so explicitly. Phrasings:

• "I have not verified this — the API typically takes X but check before relying on it."
• "Based on my training data (which may be outdated), this was at path Y."
• "This is a guess based on framework conventions, not a fact."

The user can act on a labeled guess. They cannot act safely on a confident hallucination.

When to fetch fresh docs

Use context7 (or equivalent doc-fetcher) BEFORE writing code that calls a library API, even one you know well. Library APIs change. Your training data is months or years stale. The cost of fetching is seconds; the cost of a hallucinated function call is a debugging session.

Especially fetch for:

• Recently updated libraries (anything 1.0+ in the last 12 months).
• Cloud SDKs (AWS, GCP, Stripe, Supabase — these change constantly).
• AI/ML libraries (anthropic, openai, langchain — fast-moving).
• Your own project's internal APIs — read the actual code, not a mental model of it.

Example

Bad:

Agent: "I'll use redis.async_get(key, timeout=5) to fetch with a timeout." Function does not exist. Real API is await redis.get(key) and timeouts are configured at the connection level.

Good:

Agent: fetches redis-py docs via context7 "The async API uses await redis.get(key). Timeouts are set on the connection (Redis(socket_timeout=5)), not per-call. Adjusting the implementation."

The cost of getting this wrong

A hallucinated API call doesn't fail with a clear "this doesn't exist" error in many contexts — it gets caught by a generic exception handler, logs a confusing message, and silently returns garbage. The user trusts the code, ships it, and finds out in production. Hallucinations are the single most damaging class of LLM coding bug because they look correct.