Why "I Can't Reproduce This" Is Still the Most Annoying Sentence in Software

Shweta Kumari — Tue, 23 Jun 2026 11:37:34 +0000

Been part of a dev team longer than a few months? You’ve experienced the cycle: The bug comes in the door. You open the ticket.

It says something to the effect of “the button doesn’t work” or "the page becomes stuck on occasion.”

No reproduction steps. No screenshot. I have no idea which browser, user profile, or specific actions the user took just before everything went wrong. So, you inquire about more info.

A day goes by, and you get a response.

You ask again: what do the browser’s developer tools say in the Console tab? Are there any failed network requests? Are you on Windows, Mac, or Linux? Which version? Another couple of days pass. Eventually, you have enough context to start actual debugging. Sometimes it resolves immediately, or somehow ‘fixes itself.’

This issue is systemic, not just an isolated incident or a minor inconvenience. Testers, support staff, and even other developers do not approach problems with the same understanding of stack traces. They generally work in a “This looks broken" mode, and frankly, they probably should work in that mode, because it’s not their job to know that that indicates a 500 Internal Server Error.

But it is your job to determine, not theirs.

The usual bug reporting tools don’t really close the gap. A screenshot shows you the moment something went wrong, but not the five steps that led there. A screen recording captures the what but not the why — no console logs, no failed network requests, nothing about device or browser state. And tools like Jira or Linear are great at tracking that a bug exists, but they were never built to actually collect the debugging context around it. You still end up pasting logs manually, if anyone even thought to grab them.

I’ve seen a couple of browser extensions try to address this gap over the years, and Brie.io is one browser extension for bug reports I’ve actually kept on my browser. It helps teams reproduce bugs without repeated back-and-forth. When something fails, I click it, and it records a screenshot or a few seconds of session replay alongside the browser's console logs, network activity, and basic device information into a bundle. (Nope, you’re not asking your users for the HAR file or copy-pasting inscrutable error messages).

The aspect I really appreciate is that it doesn't try to replace your issue tracker—instead, it ensures that the bug you finally submit to Jira or Linear is actually useful at the other end.

If your team is doing browser-based QA testing or you manage a support queue taking “it’s broken” emails from your non-technical colleagues, this becomes meaningful—you get a head start at resolving the problem instead of the first hour on a bug spent trying to get the reporter to reproduce the issue again. Certainly not a silver bullet, and you still get tricky ones that won't be captured that easily, but for many common "works on my machine" scenarios, being able to automatically send the session along has already saved our team a lot of back-and-forth while trying to reproduce bugs.

DEV Community: Shweta Kumari

Why "I Can't Reproduce This" Is Still the Most Annoying Sentence in Software