„Der Import geht nicht“ ist ein verständlicher Frustmoment. Für einen Coding-Agenten ist es noch kein brauchbarer Auftrag. Das Problem wird auch nicht dadurch klarer, dass die Eingabe dreimal so lang wird.
Ein gutes Fehlerbriefing trennt Beobachtung, Erwartung, Reproduktion, Kontext, Änderungsgrenzen und Abnahme. Diese sechs Felder kannst du zunächst frei erklären und anschließend ordnen lassen.
Ein Fehlerfall statt einer Vermutung
Beginne mit dem, was tatsächlich passiert. „Nach dem Hochladen bleibt der Status bei Verarbeitung“ ist eine Beobachtung. „Die Queue ist kaputt“ ist bereits eine Ursachenhypothese.
Wenn ein Eingabetool die Hypothese als gesicherte Ursache ausgibt, kann der Agent früh auf dem falschen Pfad landen. Eine gute Struktur hält beides getrennt.
Anthropic beschreibt Context Engineering als gezielte Auswahl und Pflege des relevanten Kontexts. Für ein Fehlerbriefing heißt das: reproduzierbare Informationen sind wichtiger als eine ungeordnete Menge vermeintlich hilfreicher Details. S08
Das gesprochene Beispiel
Dieses Beispiel ist konstruiert. Die Dateinamen bezeichnen keinen tatsächlich untersuchten Codebestand.
„Beim CSV-Import bleibt eine Datei mit leerer Kundennummer hängen. Mit ausgefüllter Nummer läuft sie durch. Ich habe es lokal zweimal gesehen. Eigentlich sollte eine verständliche Validierungsfehlermeldung kommen. Bitte erst reproduzieren, keine Datenbankmigration und keine neue Abhängigkeit. Am Ende brauche ich einen kleinen Fix und einen Test für den leeren Wert.“
Der daraus ableitbare Auftrag
Beobachtung:
Ein CSV-Import mit leerer Kundennummer bleibt im Verarbeitungszustand.
Erwartung:
Der Import meldet einen verständlichen Validierungsfehler.
Reproduktion:
Lokaler Test, bisher zweimal beobachtet.
Vergleichsdatei mit ausgefüllter Kundennummer funktioniert.
Testdateien vor Beginn bereitstellen oder anfordern.
Kontext:
Bereich CSV-Import; genaue Ursache noch unbekannt.
Grenzen:
Keine Datenbankmigration, keine neue Abhängigkeit.
Änderung auf den Fehlerfall begrenzen.
Abnahme:
Fehler reproduziert, minimaler Fix, Test für leeren Wert,
Vergleichsfall mit gültigem Wert weiterhin erfolgreich.
Die zusätzliche Aufforderung, Testdateien bereitzustellen, ist eine offen ausgewiesene Arbeitsvoraussetzung. Der Agent darf nicht so tun, als lägen sie bereits vor.
Was vor der Übergabe noch fehlt
Je nach Fall brauchst du Version, Umgebung und eine freigegebene Testdatei. Ein Logausschnitt kann hilfreich sein, muss aber auf vertrauliche Inhalte und Zugangsdaten geprüft werden.
Ein Sprachmodus sollte diese Informationen nicht aus dem Kontext erraten. Entweder sind sie tatsächlich verfügbar, oder der Auftrag fordert sie an. „Nicht bekannt“ ist ein zulässiger Zustand.
Auch Quellenzugriff gehört getrennt behandelt. Eine Anweisung kann ein Repository nennen, ohne dem Agenten bereits Zugriff zu geben. Das Briefing ist kein Berechtigungsnachweis.
Warum die Reviewzeit dazugehört
METR fand in einem Experiment mit 16 erfahrenen Open-Source-Entwicklern und damaligen KI-Werkzeugen Anfang 2025 eine längere Bearbeitungszeit mit KI. Das Ergebnis gilt für dieses Setting; das Methodenupdate von 2026 warnt bei neueren Daten vor relevanten Selektions- und Messproblemen. S05 S06
Für diesen Workflow folgt daraus keine pauschale Aussage gegen Coding-Agenten. Es folgt eine Messregel: Den gesamten Weg bis zum akzeptierten Fix betrachten. Nicht nur die Zeit, bis der Agent den ersten Patch ausgibt.
Eine kleine Pilotmethode
Nimm mehrere vergleichbare Fehlerberichte und bewerte das Briefing zunächst ohne Lösung: Kann eine andere Person den Fall reproduzieren? Sind Grenzen klar? Fehlt ein zwingendes Artefakt?
Vergleiche dann die Bearbeitung mit dem bisherigen Bericht und mit der sprachlich erstellten Struktur. Erfasse Rückfragen, Reviewaufwand und unnötige Änderungen. Halte Modell- und Toolversionen fest.
So prüfst du, ob die Spracheingabe wirklich das Briefing verbessert. Eine bloße Vorliebe für Sprechen oder Tippen ist eine andere Frage.
Wo 
helfen soll
Der intelligente Modus soll die Erklärung in eine verwendbare Form bringen. Er soll nicht die eigentliche Fehlerursache aus einem Diktat erfinden. Wer die Beobachtung kennt, liefert das Fachwissen. Die Aufbereitung sorgt für Ordnung und sichtbare Lücken.
Ein guter Bugreport macht es leichter, die richtige Frage zu untersuchen. Er versucht nicht, die Antwort vorwegzunehmen.
Weiterführende Ratgeber
- Coding-Agenten steuern: Warum ein guter Auftrag wichtiger ist als mehr parallele Fenster
- Prompts diktieren: Vom gesprochenen Gedanken zum klaren KI-Auftrag
- Intelligenter Modus: Welche Prompt-Technik passt zu welcher Aufgabe?
Quellen und Einordnung
- S05: METR (10.07.2025): Early-2025 AI and Experienced Open-Source Developer Productivity. 16 erfahrene Entwickler, 246 Aufgaben in vertrauten Repositories; 19 % längere Bearbeitungszeit mit damaligen Tools. Keine allgemeine 2026-Aussage.
- S06: METR (24.02.2026): We are Changing our Developer Productivity Experiment Design. Neue Stichprobe mit relevanten Selektions- und Messproblemen; Gleichzeitigkeit mehrerer Agenten erschwert Zeitmessung. Keine belastbare universelle Speedup-Zahl.
- S08: Anthropic (29.09.2025): Effective context engineering for AI agents. Empfehlungen zu gezieltem Kontextmanagement; kein Wirksamkeitsnachweis für .
Beispiel: Aus Frust wird ein reproduzierbarer Fehlerbericht
Aylin, fiktive Produktmanagerin, findet im neuen Dashboard einen Bug: Der Export bricht bei Umlauten in Dateinamen ab. Sie will das schnell an das Entwicklungsteam weitergeben und tippt frustriert „Export mit Umlauten geht nicht“. Dann stoppt sie, öffnet und spricht stattdessen strukturiert:
„Beobachtung: CSV-Export schlägt fehl, sobald ein Dateiname einen Umlaut enthält. Erwartung: Export läuft durch, Umlaute bleiben erhalten. Reproduktion: Dashboard öffnen, Export starten, Fehlermeldung bei zweitem Datensatz. Kontext: tritt seit dem letzten Release auf. Grenze: bitte nichts am Export-Format ändern. Abnahme: Test mit ä, ö, ü, ß im Dateinamen.“
bringt ihre Punkte in genau diese sechs Felder, ohne ihre Ursachenvermutung als Fakt zu verkaufen. Der Entwickler, der das Ticket liest, kann sofort loslegen – und Aylin hat in zwei Minuten mehr Klarheit geschaffen als in einer halben Stunde Slack-Hin-und-Her.
Die meisten Bugreports scheitern nicht an fehlendem Willen, sondern an fehlender Struktur. verwandelt dein gesprochenes „das ist kaputt“ in ein Briefing mit Beobachtung, Erwartung, Reproduktion und klaren Grenzen – so muss niemand deine Gedanken rückwärts entziffern. Das spart auf beiden Seiten Zeit und schützt vor falschen Annahmen. Wenn dein Team regelmäßig Fehler an KI-Agenten oder Entwickler weitergibt, schau dir diesen Ansatz an: https://ohnetippen.de/.
