Debugging AI hallucinations — a triage workflow

The frustrating bugs in vibe-coded apps are not the ones where the model failed and you noticed. They are the ones where the model failed and you did not.

The function calls a method that does not exist. The import path is wrong by one folder. The library has a real name but the API the model invented is fictional. The test passes because it tests the wrong thing.

Here is a workflow for triaging these.

Step 1: Trust nothing the model invented in unfamiliar territory

The single best predictor of a hallucination is "I do not know this library well." If the model writes code against a familiar API and gets it wrong, you usually catch it. If it writes against an obscure SDK, you might not.

Whenever a feature uses a library or API you have not used before, slow down. Open the real docs. Confirm the function actually exists. This costs two minutes; finding the hallucination at 11pm costs two hours.

Step 2: Make the error talk

When something does not work, your first move is not to ask the model "why did this break?" — it is to make the error specific.

• Read the actual stack trace, not the message.
• Log the value the model was passing.
• Open the source of the library and check the signature it actually has.

This step bypasses the model's confidence. The model will happily explain why code that does not work should work. The runtime will not.

Step 3: Bring the evidence back to the model

Once you have a real error and a real signature, paste both. "The function foo.bar was called with { x: 1 } and returned this error: TypeError: bar is not a function. Here is the actual foo module:" — followed by the real types.

The model fixes correctly when given evidence. It hallucinates more when asked open-ended "why?" questions.

Step 4: Bisect when the bug is mysterious

If a feature worked yesterday and does not today, do not ask the model to find the bug. Use git. Run git log on the relevant files, find the diff that caused the change, and start there.

This is one place where being disciplined about small commits compounds — a 20-line diff is easy to bisect; a 400-line "added the feature" commit is not.

Step 5: Know the hallucination shapes

A few recurring patterns are worth memorizing because they fail silently:

• Invented API surfaces for popular libraries — methods that should exist but don't.
• Wrong version assumptions — the model wrote code for v2 of a library, you have v3 installed.
• Plausible but wrong file paths — src/lib/utils.ts when your repo uses src/utils/index.ts.
• Confident-but-broken regex — especially Unicode and lookaheads.
• Type assertions that hide real type errors — as any, !, and // @ts-ignore are red flags.

Search the diff for these patterns before you commit. It takes thirty seconds and prevents most of the bad days.

Step 6: When all else fails, write the code yourself

You can. You are allowed. Sometimes the fastest debugging move is to stop debugging the model's attempt and write the 20-line function yourself, knowing exactly what it does. The model is a tool, not an obligation.

The goal is shipped, working software — not maximum AI-generated lines.