Ya conoces el mensaje. Llega un viernes por la tarde.
«Oye, la página no funciona».
Así que le contestas. ¿Qué página? ¿Qué estabas haciendo? ¿Qué navegador? ¿Puedes mandarme una captura de pantalla? ¿Había algún error en la consola? Bueno, da igual, deja que te explique cómo abrir la consola.
Cuatro mensajes después te enteras de que era Safari en un iPad, en una página que nunca has probado con ese ancho, y de que el «error» era un 502 que se resolvió solo hace veinte minutos. La información que necesitabas existía. Existía en su navegador, en el momento en que falló, y luego desapareció.
La brecha
En el reporte de bugs hay una asimetría permanente. Quien sufre el bug tiene todas las pruebas y no reconoce ninguna. Quien puede arreglarlo las reconoce todas y no tiene ninguna.
Toda herramienta de reporte de bugs es un intento de salvar esa brecha. La mayoría lo hace pidiendo al usuario que cargue con las pruebas hasta el otro lado, y fracasa, porque el usuario no sabe qué es una prueba.
Pedirle a un usuario que describa un bug es pedirle que haga la parte más difícil de la depuración, decidir qué es relevante, sin nada del contexto que lo hace posible. Te dice que el botón no funciona. No te dice que la petición devolvió un 500, porque nunca lo vio.
La otra dirección
Así que no preguntes.
Las pruebas ya están en el navegador. La consola tiene el error. El registro de red tiene la petición que falla. El DOM tiene la maquetación en el ancho en el que se rompió. El usuario está en medio de una escena del crimen completa, sin poder ver nada de ella.
La premisa de BugDump es que el único trabajo del usuario debería ser hacer clic en un botón y decir, con sus palabras, qué salió mal. Todo lo demás se recoge sin preguntar:
Logs de consola, incluidos los de antes de que se abriera el widget
Peticiones de red, con código de estado y tiempos
Una repetición de sesión del DOM
Sus clics, entradas de texto y navegación, en orden
Navegador, sistema operativo, viewport, URL de la página
Una captura de pantalla que puede anotar y difuminar antes de que salga de su máquina
El usuario escribe «el botón no funciona». Tú recibes esa frase junto con una respuesta 500, un stack trace y una repetición de los doce segundos antes de que se rindiera.
Qué cambia
La ventaja obvia es la velocidad. Los reportes que necesitaban cuatro idas y vueltas antes de poder trabajar con ellos llegan listos para trabajar.
La ventaja menos evidente es el volumen. La mayoría de los bugs nunca se reportan. No porque a los usuarios les dé igual, sino porque reportar sale caro: rellenar un formulario, explicar el contexto, responder preguntas y, probablemente, no volver a saber nada. Los usuarios hacen un cálculo rápido y deciden que no vale la pena. Simplemente dejan de usar la función rota.
Cuando reportar cuesta un clic, ese cálculo cambia. Te enteras de los bugs que nunca merecía la pena mencionar, que a menudo son los que te están costando usuarios sin hacer ruido.
Cerrar el ciclo también importa. Un reporte enviado al vacío enseña a la gente a no reportar. Por eso BugDump le da a cada proyecto un portal público en el que quienes reportan ven su tarea pasar de Confirmado a Hecho. Quien ve que su reporte se arregla envía el siguiente.
La parte que no esperaba
Construí primero la capa de captura, porque ese era el problema obvio. Después se volvió obvia otra cosa.
Cuando un reporte contiene telemetría completa y estructurada, deja de ser solo documentación para una persona. Es una entrada bien formada para un agente de IA.
Así que lancé un servidor MCP. Claude Code se conecta a BugDump y lee directamente tareas, reportes y la telemetría completa. El flujo de trabajo se convierte en esto:
Mira la tarea #42 en BugDump y arréglala.
El agente trae el error de consola, encuentra la petición que falla, localiza el código correspondiente y propone un arreglo. Nunca abres el panel.
Solo es posible porque el reporte está completo. Un agente no puede preguntarle a un usuario qué navegador usaba. Tiene una sola oportunidad con las pruebas, así que las pruebas tienen que estar completas: la misma propiedad que hace que un reporte sea bueno para una persona lo hace útil para una máquina.
Dónde está BugDump hoy
BugDump v1.0 ya está disponible. Una etiqueta script, un tablero de triaje, ocho integraciones, webhooks y el servidor MCP. El plan Gratis es un plan de verdad: 500 reportes por proyecto, para siempre, sin tarjeta.
Lo construyo en abierto. El registro de cambios es público, la hoja de ruta es pública y el tablero de sugerencias está abierto. Si a la herramienta le falta algo que tu flujo de trabajo necesita, dímelo, mejor a través del widget, así me llega también el log de consola.
Te puede interesar
¿Qué es BugDump? Reportes de bugs para sitios web con una etiqueta script — el botón de reporte que añade una sola etiqueta script, y qué trae cada reporte: consola, red, repetición y entorno.
Anatomía de un reporte de bug: qué captura BugDump y por qué — cada señal que recoge el widget, por qué se gana su sitio y cuáles resuelven bugs de verdad.
Tu agente de IA debería leer tus reportes de bug — cómo Claude Code lee reportes, logs de consola y trazas de red por su cuenta, sin que abras el panel.