How do you describe a bug to an AI assistant so it can diagnose it accurately?

Question

Accepted Answer

A good bug report to an AI is the same as a good bug report to a human: give it **enough context to reproduce the problem in its head**, and cut the noise. The AI can only reason about what you paste — vague descriptions produce vague guesses.

## What to include

- **The exact error message and full stack trace** — copy it verbatim, not a paraphrase. The file and line in the trace are the single most useful clue.
- **The relevant code** — the function that throws plus its immediate callers, not the whole repo.
- **Expected vs actual behavior** — "I expect X, but I get Y" is the core of any bug report.
- **Repro steps** — the exact input or sequence that triggers it.
- **Environment/versions** — language, framework, and library versions (a bug can be version-specific).
- **DB schema or sample data** — when the bug touches a query or data shape.

## What to leave out

Unrelated files, your whole config, secrets/API keys, and "I think it might be X" theories that bias the diagnosis. Give facts, not hunches.

## Weak vs strong report

```text
❌ WEAK: "My login is broken, it throws an error. Why?"
   → no error text, no code, no repro → the AI can only guess

✅ STRONG:
   Error (verbatim):
     TypeError: Cannot read properties of undefined (reading 'id')
       at getUser (auth.js:42)
   Code (auth.js:40-43):
```

```js
function getUser(token) {
  const session = sessions.find(s => s.token === token); // returns undefined if not found
  return session.user.id; // line 42: crashes when session is undefined
}
```

```text
   Expected: return null for an unknown token.
   Actual:   throws TypeError above.
   Repro:    call getUser('expired-token').
   Env:      Node 20, no framework.
```

With the strong version, the AI can point straight at the missing `undefined` check and propose a guard, because every fact it needs is on the page.

## Why it matters

An AI assistant has **no access to your running system** — it reasons only from what you provide. A weak report forces it to guess at the error, the code, and the environment all at once, and a wrong guess wastes a round-trip. A strong report (exact trace + relevant code + expected/actual + repro + versions) turns diagnosis into a focused task and usually gets the right fix on the first try. Learning to write tight bug reports also makes you a better debugger yourself, because it forces you to isolate the facts before asking.