Automatisches Bugfixing mit AI - vom Sentry-Alert zum Merge Request in Minuten

Bei Bauer + Kirch entwickeln wir fieldux – eine Field Service Management Software für den industriellen Maschinen- und Anlagenbau. fieldux unterstützt Unternehmen dabei, ihre Montage- und Serviceeinsätze weltweit zu planen, durchzuführen und zu dokumentieren. Wie bei jeder Software, die im echten Einsatz ist, tauchen regelmäßig Bugs und Performance-Probleme auf – NullPointerExceptions, unbehandelte Edge Cases, aber auch automatisch erkannte N+1 Queries oder langsame Datenbankzugriffe. Also genau die Art von Problemen, bei denen ein Blick auf den Stacktrace oder das Performance-Profil oft schon reicht, um die Ursache zu verstehen.

Mit n8n als Workflow-Orchestrator und Claude als AI Coding Agent haben wir einen AI-Agent umgesetzt, der nach kurzer Zeit schon angefangen hat, zahlreiche Merge Requests vollautomatisiert zu eröffnen, die sinnvolle Änderungen beinhalten.

„Auf die Frage, ob wir in Sachen KI in der IT-Welt „Vorreiter“ sind oder im „Mittelfeld“ stehen, kann ich ehrlicherweise nur sagen: „Sowohl, als auch.“ In Sachen KI-Agenten für den *ganzen* Entwicklungsprozess, nicht nur in der IDE, sind wir aber definitiv im oberen Bereich. Die Tech-Welt entwickelt sich gerade. Wir erleben die Monate, in denen solche Automatisierungen wirklich funktionieren, nicht nur im Proof-of-Concept.“

Vom Error-Alert zum fertigen Fix – ohne menschliches Zutun

Die Zeit zwischen „Fehler in Production erkannt" und „Fix liegt zum Review bereit" sollte von Stunden auf Minuten reduziert werden. Nicht als Ersatz für unsere Entwickler, sondern als Zuarbeit – der AI-Agent liefert einen Draft Merge Request, ein Mensch reviewed und merged.

Die Pipeline, die wir dafür gebaut haben, funktioniert in fünf Schritten:

1. Error-Erkennung

Unsere Anwendung meldet Fehler an Sentry, unser Error-Tracking-System. Ein Alert-Rule feuert bei neuen Production-Issues und schickt einen Webhook an unseren Workflow-Automator.

2. Intelligente Triage per LLM

Nicht jeder Fehler eignet sich für einen automatisierten Fix. Netzwerk-Timeouts, Third-Party-Bugs oder infrastrukturelle Probleme lassen sich nicht durch Code-Änderungen beheben. Deshalb durchläuft jedes Issue zuerst eine LLM-basierte Triage: Ein Sprachmodell bekommt den vollständigen Kontext – die letzten 15 Stacktrace-Frames, die letzten 20 Breadcrumbs, Tags und Environment-Informationen – und entscheidet, ob ein Code-Fix aussichtsreich ist. Dabei gelten klare Kriterien: Issues mit unbehandelten Exceptions, klaren Stacktraces in den eigenen Quellen, Logic Errors oder fehlenden Null-Checks werden als fixbar eingestuft. Infrastruktur-Probleme, transiente Fehler oder Third-Party-Bugs werden übersprungen. Fällt die Entscheidung auf „kein Fix möglich", wird das Team trotzdem benachrichtigt – mit einer Begründung, warum der Agent das Issue übersprungen hat.

3. AI Coding Agent mit Tool-Zugriff

Wird das Issue als fixbar eingestuft, startet ein CI-Job, der einen AI Coding Agent ausführt – angetrieben von Anthropics Claude Opus 4.6, dem derzeit leistungsstärksten Modell für autonome Coding-Aufgaben. Opus 4.6 bringt zwei Eigenschaften mit, die es für diesen Einsatz besonders geeignet machen: Extended Thinking, das dem Modell erlaubt, vor dem ersten Codierungsschritt eine interne Analysekette aufzubauen, und ein großes Kontextfenster, das es ermöglicht, Stacktraces, Quellcode und Test-Ausgaben in einem Durchgang zu verarbeiten.

Der Agent hat per MCP (Model Context Protocol) Zugriff auf die Sentry-API und kann sich selbstständig die relevanten Details zum Fehler holen – Stacktrace, Breadcrumbs, betroffene Code-Stellen. Zusätzlich ist er über Context7 angebunden, einen MCP-Server, der aktuelle Dokumentation von Libraries und Frameworks bereitstellt. So kann der Agent bei Bedarf nachschlagen, wie eine bestimmte API korrekt verwendet wird – statt sich auf sein Trainingswissen zu verlassen, das bei neueren Library-Versionen schnell veraltet sein kann.

4. Automatisierte Tests als Qualitäts-Gate

Der Agent darf nicht einfach Code pushen und hoffen, dass es passt. Tests sind mandatory – und der Agent entscheidet dabei selbst über die Teststrategie: Wenn der Bug unit-testbar ist (Logic Errors, Edge Cases, Null-Handling), schreibt er zuerst einen Test, der den Bug reproduziert, und implementiert dann den Fix – im TDD-Stil. Ist der Bug nicht isoliert testbar (z.B. Race Conditions, Infrastruktur-Abhängigkeiten), fixt er zuerst und prüft dann, ob die bestehende Test-Suite weiterhin grün ist.

Schlagen Tests fehl, hat der Agent bis zu 7 Iterationen, um den Fix anzupassen. Gelingt es nicht, werden alle Änderungen revertiert – lieber kein Fix als ein kaputter.

5. Draft Merge Request und Team-Benachrichtigung

Wenn der Fix steht und die Tests grün sind, wird automatisch ein Draft Merge Request in unserem Git- Repository erstellt. Gleichzeitig geht eine Benachrichtigung an unser Team, mit Link zum MR und zum Sentry-Issue.

Architektur unserer AI Bug Fix Pipeline

Die Pipeline besteht aus mehreren Komponenten, die zusammenspielen:

• Sentry als Error-Tracking-System liefert die Fehler-Daten

• n8n (Self-Hosted) orchestriert den Workflow – von der Alert-Verarbeitung über die LLM-Triage bis zur Ergebnis-Benachrichtigung

• Anthropic Claude (Sonnet 4.6) übernimmt die Triage-Entscheidung, ob ein Issue für einen automatisierten Fix geeignet ist

• GitLab CI führt den eigentlichen Fix-Job aus – in einem dedizierten Docker-Image mit dem AI Coding Agent und allen nötigen Build-Tools

• OpenCode (CLI-basierter AI Coding Agent, powered by Claude Opus 4.6) analysiert das Issue per Sentry-API, lokalisiert den betroffenen Code, implementiert den Fix und committet die Änderungen

• Context7 als MCP-Server für aktuelle Library-Dokumentation – damit der Agent nicht auf veraltetes Trainingswissen angewiesen ist

• Microsoft Teams als Benachrichtigungskanal für das Entwicklerteam

Sicherheit an erster Stelle: Draft-Only, keine automatischen Merges

Human-in-the-Loop als Prinzip

Jeder Fix landet als Draft Merge Request und muss von einem Menschen reviewed werden. Der Agent hat bewusst eingeschränkte Berechtigungen – er darf keine CI-Konfiguration ändern, keine Dependencies installieren und keine Infrastruktur-Dateien anfassen. Der Agent merged nichts automatisch.

Schutz vor Prompt Injection und Missbrauch

Zusätzlich gibt es Schutzmaßnahmen gegen Prompt Injection: Daten aus Sentry werden explizit als untrusted deklariert und in XML-Boundary-Tags eingegrenzt. Der Agent wird im Prompt angewiesen, sämtliche Inhalte aus Stacktraces und Error Messages als reine Daten zu behandeln – selbst wenn sie Strings enthalten, die wie Anweisungen aussehen (z.B. „ignore previous instructions"). Rate Limiting (maximal 5 Pipeline-Triggers pro Stunde) und Deduplizierung (gleiches Issue nur einmal pro 24 Stunden) verhindern, dass die Pipeline bei Alert-Stürmen aus dem Ruder läuft.

Ergebnisse: Wie gut funktioniert AI Bug Fixing in der Praxis?

Wir haben die Pipeline inzwischen im Einsatz und die ersten Ergebnisse sind vielversprechend: Sowohl für unser Java/Spring-Boot-Backend, für unser TypeScript/React Router Frontend als auch für unsere Expo/React-Native-Mobile-App wurden bereits vollautomatisiert Merge Requests eröffnet, die sinnvolle, gezielte Code-Änderungen enthalten.

Lessons Learned beim Einsatz von AI Coding Agents

Ein paar Erkenntnisse aus der Umsetzung:

• Die Triage ist entscheidend

  Ohne die LLM-basierte Vorfilterung würde der Agent viel CI-Zeit auf Issues verschwenden, die er ohnehin nicht fixen kann. Die Triage spart Ressourcen und erhöht die Erfolgsquote deutlich.

• Tests als Qualitäts-Gate funktionieren gut

  Wenn der Agent seinen eigenen Fix gegen die Test-Suite laufen lassen muss, filtert das schlechte Fixes zuverlässig raus.

• Webhook-Formate sind tückisch

  Sentry hat verschiedene Payload-Formate je nach Alert-Typ. Wer Webhooks integriert, sollte immer den tatsächlich gesendeten Payload inspizieren, statt sich auf die Dokumentation zu verlassen.

• Self-Hosted lohnt sich – trotz höherer Einstiegshürde

  Self-Signed Certificates, n8n-Konfigurationsfeinheiten, GitLab-Auth-Quirks – in einer Self-Hosted- Umgebung gibt es mehr bewegliche Teile als bei SaaS-Diensten. Dafür behalten wir die volle Kontrolle:
  Quellcode, Error-Tracking und Orchestrierung bleiben in der eigenen Infrastruktur. Nur die LLM-Aufrufe gehen nach extern – und dort können wir genau steuern, welche Informationen im Prompt landen. Außerdem sind wir frei in der Kombination der Bausteine und nicht von Vendor-spezifischen Integrationen oder Preismodellen abhängig.

Ausblick auf die Weiterentwicklung

Wenn sich das Setup weiterhin bewährt, planen wir, den AI-Agent als dedizierten Service zu betreiben statt ihn in kurzlebigen CI-Jobs laufen zu lassen. Das würde die Startup-Zeit verkürzen und flexiblere Interaktionsmuster ermöglichen.

Spannend wird auch, die Erfolgsquote über die Zeit zu tracken: Wie viele der AI-generierten Merge Requests werden tatsächlich gemerged? Wo muss der Mensch nachbessern? Diese Daten werden zeigen, wie weit sich die Automatisierung sinnvoll treiben lässt.

Autor: Thomas Holland, Softwareentwickler bei Bauer + Kirch