Warum ich BugDump gebaut habe: „Geht nicht“ ist kein Fehlerbericht

Entwickler-ToolsDenis Povarov20. August 2026

Du kennst die Nachricht. Sie kommt am Freitagnachmittag.

„Hey, die Seite ist kaputt.“

Also schreibst du zurück. Welche Seite? Was hast du gemacht? Welcher Browser? Kannst du einen Screenshot schicken? Gab es einen Fehler in der Console – ach, vergiss es, ich erkläre dir erst mal, wie man die Console öffnet.

Vier Nachrichten später erfährst du, dass es Safari auf einem iPad war, auf einer Seite, die du in dieser Breite nie getestet hast, und dass der „Fehler“ ein 502 war, der sich vor zwanzig Minuten von selbst erledigt hat. Die Informationen, die du gebraucht hättest, gab es. Es gab sie in diesem Browser, in dem Moment, als es kaputtging, und dann waren sie weg.

Die Lücke

Beim Melden von Bugs gibt es eine dauerhafte Asymmetrie. Die Person, die den Bug erlebt, hat alle Belege und kann keinen davon erkennen. Die Person, die den Bug beheben kann, erkennt alle und hat keinen.

Jedes Tool zum Melden von Bugs versucht, diese Lücke zu überbrücken. Die meisten tun es, indem sie die meldende Person bitten, die Belege hinüberzutragen, und das scheitert, weil diese Person nicht weiß, was ein Beleg ist.

Wer jemanden bittet, einen Bug zu beschreiben, verlangt den schwierigsten Teil des Debuggings, nämlich zu entscheiden, was relevant ist, und das ohne den Kontext, der das erst möglich macht. Du erfährst, dass der Button nicht funktioniert. Du erfährst nicht, dass der Request 500 zurückgegeben hat, denn das hat die Person nie gesehen.

Die andere Richtung

Also frag nicht.

Die Belege sind schon im Browser. In der Console steht der Fehler. Im Netzwerk-Log steht der fehlgeschlagene Request. Das DOM hat das Layout in genau der Breite, in der es kaputtging. Die Person steht mitten am Tatort, alle Spuren liegen vor ihr, und sie sieht keine davon.

Die Grundidee von BugDump: Die einzige Aufgabe der Person ist, auf einen Button zu klicken und in eigenen Worten zu sagen, was schiefgelaufen ist. Alles andere wird gesammelt, ohne zu fragen:

Console-Logs, auch von vor dem Öffnen des Widgets
Netzwerk-Requests mit Status und Timing
Ein Session-Replay des DOM
Klicks, Eingaben und Navigation, in der richtigen Reihenfolge
Browser, Betriebssystem, Viewport, Seiten-URL
Ein Screenshot, den die Person annotieren und weichzeichnen kann, bevor er ihren Rechner überhaupt verlässt

Die Person schreibt „der Button geht nicht“. Du bekommst diesen Satz zusammen mit einer 500-Response, einem Stack-Trace und einem Replay der zwölf Sekunden, bevor sie aufgegeben hat.

Was sich ändert

Der offensichtliche Gewinn ist Tempo. Berichte, die vier Runden Rückfragen brauchten, bis man damit arbeiten konnte, kommen gleich brauchbar an.

Der weniger offensichtliche Gewinn ist die Menge. Die meisten Bugs werden nie gemeldet. Nicht weil sie den Leuten egal sind, sondern weil Melden teuer ist: ein Formular ausfüllen, den Kontext erklären, Rückfragen beantworten und wahrscheinlich nie wieder etwas hören. Die Leute rechnen kurz nach und entscheiden, dass es sich nicht lohnt. Sie benutzen die kaputte Funktion einfach nicht mehr.

Wenn Melden einen Klick kostet, geht diese Rechnung anders aus. Du erfährst von den Bugs, die nie der Rede wert waren, und das sind oft genau die Bugs, die dich still und leise Kundschaft kosten.

Auch das Schließen des Kreises zählt. Ein Bericht, der im Nichts verschwindet, bringt den Leuten bei, nichts mehr zu melden. Deshalb gibt BugDump jedem Projekt ein öffentliches Portal, auf dem Meldende verfolgen, wie ihre Aufgabe von Bestätigt nach Fertig wandert. Wer sieht, dass der eigene Bericht behoben wurde, meldet auch den nächsten.

Der Teil, mit dem ich nicht gerechnet hatte

Ich habe zuerst die Capture-Schicht gebaut, weil das das offensichtliche Problem war. Dann wurde etwas anderes offensichtlich.

Sobald ein Bericht vollständige, strukturierte Telemetrie enthält, ist er nicht mehr nur Dokumentation für einen Menschen. Er ist ein sauber aufbereiteter Input für einen KI-Agenten.

Also habe ich einen MCP-Server gebaut. Claude Code verbindet sich mit BugDump und liest Aufgaben, Berichte und die komplette Telemetrie direkt. Der Ablauf wird zu:

Schau dir Aufgabe #42 in BugDump an und behebe sie.

Der Agent holt sich den Console-Fehler, findet den fehlgeschlagenen Request, sucht den passenden Code und schlägt einen Fix vor. Das Dashboard öffnest du nie.

Das geht nur, weil der Bericht vollständig ist. Ein Agent kann niemanden fragen, welcher Browser es war. Er hat genau einen Versuch mit den Belegen, also müssen die Belege komplett da sein. Dieselbe Eigenschaft, die einen Bericht für einen Menschen gut macht, macht ihn für eine Maschine brauchbar.

Wo BugDump gerade steht

BugDump v1.0 ist live. Ein Script-Tag, ein Board für die Triage, acht Integrationen, Webhooks und der MCP-Server. Der kostenlose Plan ist ein echter Plan: 500 Berichte pro Projekt, für immer, ohne Kreditkarte.

Ich entwickle BugDump öffentlich. Das Changelog ist öffentlich, die Roadmap ist öffentlich, und das Feedback-Board ist offen. Wenn dem Tool etwas fehlt, das dein Workflow braucht, sag es mir, am besten über das Widget, dann bekomme ich das Console-Log gleich mit.