# When you paste an error into an AI agent, you're handing it your conclusion

You hit a 500 in your API. You copy the stack trace, paste the last three lines into the agent, and write "why is this breaking?"

The agent dutifully suggests a null check on the line in the trace. You apply it. The test goes green. Production still fails on the third request, because the null was caused by the request shape from a client nobody on your team had tested with yet.

What you pasted wasn't the bug. It was your conclusion about which part of the bug mattered.

## The error text is the symptom, not the cause

Stack traces are useful to a human who already has the context of the whole system. They are close to useless to an agent that has only seen the file you opened and the line you quoted. The agent has no way to know:

- what request actually triggered the failure,
- what the database state looked like at that moment,
- which code path the request actually took,
- whether the null is the first one or the tenth one in a chain.

So it does the most reasonable thing it can with the evidence you gave it: it patches the line in the trace. That patch makes the error go away in the test you can run. It does not make the bug go away.

## The evidence that matters is almost never in the error

I used to paste just the trace. Now I paste three things, in order:

1. **The exact input that triggered the failure.** For an HTTP endpoint that means the request line, headers that matter, and the body. For a CLI tool that means the command and the cwd. Without this, the agent is guessing what the program was doing.
2. **The surrounding code path, not just the failing line.** The function that called the function that called the one in the trace, with the condition that picked that branch.
3. **A reproducible way to trigger it locally.** This is the one that turns a guess into a fix. If the agent can replay the failure, it can verify its own patch instead of just reasoning about it.

For API work specifically, the request/response pair is the unit of evidence. The error text tells you something broke. The pair tells you what broke it. Keeping that pair next to the spec locally is what makes the difference between the agent patching the symptom and the agent actually finding the contract drift that caused the 500 in the first place — which is exactly the workflow I ended up building into [Powerduck](https://www.powerduck.com/), a local-first OpenAPI studio where the request, the response, and the spec sit next to each other instead of living across three tabs.

## The cheap habit that catches this

After the agent proposes a patch, before I apply it, I ask one question back: "what input would still break this?"

Nine times out of ten the agent will immediately list a second case it had not considered — usually the one that was actually failing in production. That single follow-up costs ten seconds and saves a revert. The patch it proposed on the first paste was real code, but it was code that solved the problem you showed it, not the problem you had.

The error text is the smallest piece of evidence. Treat it that way.