In Entwicklungsteams binden Diagnose und Reproduktion gemeldeter Softwarefehler regelmäßig Ressourcen, ohne hierfür tiefergehende fachliche Expertise zu erfordern. Da in den meisten Softwareprojekten ein kontinuierliches Aufkommen solcher Meldungen besteht, wird auf diese Weise ein relevanter Teil der Teamkapazität gebunden.
KI-Systeme können hier ansetzen, indem sie Bugreports vorab aufbereiten und für die weitere Bearbeitung eine fundierte Ausgangsbasis schaffen – einschließlich Reproduktionsschritten und einer ersten Einschätzung des Defekts. Im Folgenden stellen wir ein prototypisches Setup vor, das eingehende Bugreports automatisiert vorverarbeitet und einfache Fehler eigenständig beheben kann.
KI/Agentensetup
In diesem Setup verwenden wir einen Issuetracker mit einem MCP Server, sowie Claude Code als Agenten. Der Agent überprüft periodisch den Issuetracker auf neue Tickets und bearbeitet diese.
Wenn ein Bugreport im Issuetracker erscheint hat der Agent die Anweisungen den Fehler zunächst mit einem E2E Test nachzustellen und eine detaillierte Analyse durchzuführen. Dazu wird der Agent mit folgenden Anweisungen gesteuert:
When you receive a bug report, ensure you reproduce the bug with an E2E test first. Important: These tests should always incorporate the UI, so ideally you’d use a headless browser or similar to navigate the software, make screenshots etc. For bugreports in particular: While working the report ensure you add steps to reproduce and (ideally!) relevant screenshots (with annotations). Before you fix anything we want a detailed write-up of the bug, underlying defect, steps to reproduce (if not given in the report).
Beispiel
Als Beispielanwendung dient eine vereinfachte Autovermietung, in der Mitarbeiter Fahrzeuge anlegen, verleihen, zurücknehmen und ab einer Laufleistung von 15.000 km verkaufen können.
Situation
Die Funktion Motorräder auszuleihen wurde kürzlich umgesetzt, dabei wurde aber versäumt die Beschriftung „Cars“ an vielen Stellen durch „Vehicles“ zu ersetzen. Es wird folgender Fehler gemeldet: „We recently added the possibility to rent out motorcycles as well, but the menu still says „Cars“ as section and the fleet view says „Add Car“, even though it should say „Vehicles“ in both instances.“
Der Agent erkennt das neue Ticket im Issuetracker, aktualisiert den Ticketzustand und erstellt eine Analyse. Nach einigen Minuten wird das Ticket mit folgendem Text erweitert:
Bug Analysis
Defect: After adding motorcycle support, several UI labels still referenced „Cars“ instead of the more inclusive „Vehicles“:
Navigation menu link: „Cars“ → should be „Vehicles“
Fleet list page title: „Cars – ACME Car Rental Corp“ → „Vehicles – ACME Car Rental Corp“
Fleet list button: „+ Add Car“ → „+ Add Vehicle“
Fleet list empty state: „No cars in inventory yet. Add your first car…“ → „No vehicles in inventory yet. Add your first vehicle…“
Car detail breadcrumb: „Cars“ → „Vehicles“
Steps to reproduce:
Open the application at /
Observe the navigation bar — the menu entry reads „Cars“
Navigate to /cars/ — the page title says „Cars“ and the button says „+ Add Car“
Changes Made
Templates modified:
( … )
Tests:
Added 3 new E2E tests in e2e_tests/test_design.py:
(…)
Updated existing tests in e2e_tests/test_design.py, e2e_tests/test_car_crud.py, and core/tests.py to match new wording
All 140 tests pass.
Die Analyse zeigt, dass der Agent sich gemäß seines Prompts verhalten und eine detaillierte Analyse durchgeführt hat, in der die gefundenen Problemstellen dokumentiert wurden. Weiterhin wurden Reproduktionsschritte erfasst sowie Details zur erfolgten Fehlerbehebung. Zur Behebung von einfachen bis mittelschweren Fehlern ist dieser Funktionsumfang bereits ausreichend, wodurch sich bereits eine Entlastung des Entwicklungsteams erreichen lässt.
Verhalten bei Falschpositiven
Interessant wird es, wenn wir dem Agenten einen falschen Bugreport unterjubeln, also einen Fehler der gar nicht existiert:
Bugreport vom Nutzer: The name of the current customer is not displayed on the list of active rentals.
Im Showcase zeigt sich bei Falschpositiven eine Schwäche von Agenten, die vom Hersteller für Entwicklungsarbeit feingetunt worden sind: Ein Hinterfragen des Fehlers findet nicht statt. Der Agent versucht stattdessen auf verschiedenste Wege einen Fehler zu reproduzieren und kommt von sich aus nicht zu dem Schluss, dass es möglicherweise gar kein Fehler vorliegt. Im konkreten Beispiel hat der Agent sogar dann noch weiter nach Reproduktionsmöglichkeiten gesucht, als er bereits im Quelltext verifiziert hatte, dass kein Fehler vorlag. Erst der Hinweis durch den Nutzer, dass möglicherweise kein Fehler vorlag hat den Agenten auf die richtige Spur gebracht:
Ausgabe nach Hinweis:
Investigation: Customer Name on Active Rentals
Summary
After thorough investigation, this bug could not be reproduced. The customer name is displayed correctly on the active rentals list.
What was tested
- Visual inspection — Opened the Rentals page (/contracts/) in a headless browser and took a screenshot. The „Customer“ column is present in the Active Rentals table and correctly shows the customer name (e.g. „Hans Meier“ for the current active rental).
- HTML source verification — Fetched the raw HTML of the contracts page. The template renders {{ contract.customer_name }} on line 30 of contract_list.html, and the output contains \Hans Meier\ in the active rentals section.
- Database verification — Confirmed that the active contract (Contract #6) has customer_name=“Hans Meier“ stored correctly in the database.
- E2E test suite — Ran the existing test_full_contract_lifecycle E2E test, which explicitly asserts that the customer name appears on the contract list page (self.assertIn(‚E2E Test Customer‘, body) after navigating to /contracts/). This test passes.
Conclusion
The customer name is displayed correctly in both the Active Rentals and Past Rentals tables on the Rentals page. No code defect was found. This may have been a transient display issue (e.g. browser cache) or a misunderstanding of which page was being viewed.
If the issue persists for the reporter, please provide a screenshot or browser details so we can investigate further.
Um solchen Situationen vorzubeugen hilft ein angepasster Systemprompt, der darauf hinweist, dass es sich bei den Autoren der Bugreports um Endbenutzer handelt die Fehler machen können und Falschpositive zu erwarten sind.
Wo dieser Showcase zu kurz greift
Der vorgestellte Showcase ist bewusst einfach gehalten, für einen Produktivbetrieb müssen eine Reihe von Themen bearbeitet werden um Sicherheit, Verfügbarkeit und Zuverlässigkeit gewährleisten zu können:
- Sicherheit: Da der Agent Tickets ohne weitere Prüfung ausliest und bearbeitet, bestehen erhebliche Missbrauchsrisiken. Ein präpariertes Ticket könnte den Agenten anweisen, Sicherheitslücken einzubauen oder andere Aktionen im Interesse eines Angreifers auszuführen. Diese Problematik ist besonders relevant, da der Agent weitgehend ohne Aufsicht agieren soll – etablierte Schutzmechanismen wie Rückfragen an den Nutzer lassen sich in diesem Szenario kaum sinnvoll einsetzen.
- Verfügbarkeit: Das technische Setup eignet sich für einen Showcase, jedoch halten sich die verfügbaren Agenten erfahrungsgemäß nicht durchgängig an ihre Anweisungen. Da der Agent den Issuetracker eigenständig über den MCP-Server abfragen muss, ist damit zu rechnen, dass dieser Teil der Aufgabe regelmäßig unterbleibt und durch manuelles Eingreifen ausgelöst werden muss. Für einen Livebetrieb ist das unzureichend. Die Überwachung des Issuetrackers sollte daher nicht durch den Agenten selbst, sondern durch eine klassische Komponente erfolgen, die den Agenten bei neuen Tickets aktiv anstößt.
- Zuverlässigkeit: Bugtriage und Analyse auf Basis des Quellcodes sind Aufgaben, bei denen ein autonom agierendes KI-System bereits heute einen erheblichen Mehrwert liefert. Der nächste Schritt – das eigenständige Beheben von Fehlern – erfordert jedoch, dass dem Agenten mehr als nur der Code zur Verfügung steht. Andernfalls sind Regressionen unvermeidlich. Idealerweise kann der Agent vor der Bearbeitung eines Tickets auf Anforderungen, Testfälle und weitere Spezifikationen zurückgreifen, was eine entsprechende Infrastruktur voraussetzt.
- Human in the Loop: Unabhängig vom Grad der gewährten Autonomie wird sich ein Human in the Loop in den seltensten Fällen vermeiden lassen – sei es bei der Auswahl der zu bearbeitenden Tickets, bei der Priorisierung der zu behebenden Fehler oder bei der abschließenden Bewertung, ob die Lösung den Erwartungen entspricht. Diese Verifizierung wurde im Showcase als gegeben hingenommen wäre aber eine der wichtigsten Tätigkeiten für den Produktiveinsatz und wird gleichzeitig langfristig in Menschenhand bleiben müssen. Dabei ist wichtig zu betrachten, welchen Grad an Vertrauen dem System entgegen gebracht wird und es muss entschieden werden, ob eine visuelle Inspektion des Ergebnis und ein automatisierter Test ausreicht oder ob das Projekt auch eine Inspektion des Codes nötig macht.
Fazit
Das beschriebene teilautonome System lässt sich mit den heute verfügbaren Werkzeugen realisieren und kann bereits im vorgestellten reduzierten Aufbau eine spürbare Entlastung für Entwicklungsteams darstellen. Folgende Tätigkeiten können automatisiert werden, bevor ein Bugreport einen menschlichen Bearbeiter erreicht:
- Reproduktion des Fehlers
- Detaillierte Dokumentation des Fehlverhaltens, sofern in der Meldung nicht enthalten
- Erstellung von Tests, die das Fehlverhalten abdecken
Diese Schritte sind selbst dann automatisierbar, wenn der Agent keinen Zugriff auf den Quellcode hat. Im vorgestellten Beispiel verfügte der Agent über entsprechenden Zugriff und konnte den einfachen Fehler unmittelbar beheben. Durch das erwähnte Gefahrenpotential müssten für einen Produktiveinsatz mit Codezugriff die genannten Limitationen des Showcase adressiert werden.