Blog

Bug reports developers can act on: what to capture

2026-10-08 · The difference between "the checkout is broken" and a report that gets fixed in ten minutes is four pieces of context, all of which the browser already has.

Ask a developer what they want from a bug report and the answer is always the same: how do I make it happen? Most reports do not say. "The checkout is broken" is a feeling; a report is a path. The good news is that the browser already holds everything a report needs at the moment the bug appears. The job is to capture it then, not to reconstruct it later.

The four things to capture

The page and the screenshot. The URL, the title, and what the screen showed, marked up so the problem is circled rather than described. A screenshot with a circle around a greyed-out button says more than a paragraph.

The steps that led there. The last navigations, clicks and inputs before the capture. Not a description of them; the actual trail, with the element each click landed on. This is what turns a report into a reproduction, and later into a test.

The console. The error the page logged when it broke. In most front-end bugs the console names the function and the line, and a developer who has that skips the first hour of work.

The network. The request that failed and its status. "The save button does nothing" is a network bug nine times out of ten, and the failed request says which endpoint and which status.

What not to capture

Anything the reporter typed into a password field, and anything that would embarrass them in a screenshot. A capture tool should blur on demand and never record secrets. A report that leaks a password is worse than no report.

From report to fix, without a meeting

With those four things attached, the triage conversation changes. Severity can be set from the evidence. The developer can start without asking a question. And a coding agent can do the same: give it the report over MCP and it has the error, the request and the steps, which is more than most humans get.

From fix to proof

The last step is the one most teams skip. The steps in the report are a test. Run them again after the fix on a fresh session and assert that the error is gone. Then the bug stays fixed, and the next agent that changes the page finds out before a customer does.