Why Bug Reports Don't Work for AI-Generated Code

A bug report written for a person leans on a person's ability to ask. "Which page? What did the console say?" A coding agent cannot ask. It acts on what is in the report, and when the report is thin it guesses, usually with confidence.

The report an agent can act on

Four things turn a vague report into one an agent can fix from:

1. The element. Its label, the component it belongs to and a selector. This is the difference between searching the repo and opening a file.
2. The failing request with its body. Bugs in generated code are often a response shaped differently than the component expects, or a null that was never guarded.
3. The error with file and line. The shortest route to the code that threw.
4. The steps before it. Repro steps from the session, so the agent can reproduce or test its fix.

Why screenshots and descriptions fall short

A screenshot shows the symptom. "Total shows $0.00" is a symptom; the cause is a null in a response body the screenshot never contained. A description relies on the user knowing what matters, and users do not.

What this looks like over MCP

• get_issue_context returns the element, errors, request summary and steps for a report by key.
• get_issue_payload returns one full request or response body when the agent needs the detail.
• find_issues searches open reports.
• get_related_history returns earlier bugs like this one and the changes that fixed them.
• mark_issue_resolved closes it and sends the reporter a "fixed" email.

What stays a human job

Deciding whether the fix is right. The report gives the agent what it needs to propose a change; a person still reviews it. And the person who found the bug still has to be the one who points at it, which takes one click.

Further Reading

• AI writes more code. Here is how to fix the bugs it ships
• The element picker
• SnagRelay for coding agents
• The SnagRelay MCP server
• Pricing
• Start free, no credit card required