Einen besseren Bugbot bauen
Als Coding-Agents leistungsfähiger wurden, stellten wir fest, dass wir immer mehr Zeit mit Reviews verbrachten. Um dieses Problem zu lösen, haben wir Bugbot entwickelt – einen Code-Review-Agent, der Pull Requests auf Logikfehler, Performance-Probleme und Sicherheitslücken analysiert, bevor sie in Produktion gehen. Bis zum letzten Sommer funktionierte er so gut, dass wir beschlossen, ihn für Nutzer zu veröffentlichen.
Der Prozess zur Entwicklung von Bugbot begann mit qualitativen Bewertungen und entwickelte sich schrittweise zu einem systematischeren Ansatz weiter, bei dem wir eine benutzerdefinierte, KI-gestützte Metrik nutzten, um die Qualität iterativ zu steigern.
Seit dem Launch haben wir 40 größere Experimente durchgeführt, die Bugbots Lösungsrate von 52 % auf über 70 % erhöht haben, während die durchschnittliche Zahl der pro Lauf gemeldeten Bugs von 0,4 auf 0,7 stieg. Das bedeutet, dass sich die Zahl der pro PR behobenen Bugs mehr als verdoppelt hat – von etwa 0,2 auf etwa 0,5.
Bescheidene Anfänge
Als wir zum ersten Mal versuchten, einen Code-Review-Agent zu bauen, waren die Modelle nicht leistungsfähig genug, damit die Reviews wirklich hilfreich waren. Doch als sich die Basismodelle verbesserten, erkannten wir, dass wir mehrere Möglichkeiten hatten, die Qualität der Fehlermeldungen zu erhöhen.
Wir experimentierten mit verschiedenen Konfigurationen von Modellen, Pipelines, Filtern und ausgeklügelten Kontextverwaltungsstrategien und holten dabei regelmäßig Feedback von unseren internen Engineers ein. Wenn eine Konfiguration offenbar weniger Fehlalarme produzierte, übernahmen wir sie.
Eine der wirkungsvollsten Qualitätsverbesserungen, die wir früh entdeckt haben, war das parallele Ausführen mehrerer Bug-Finding-Durchläufe und das Kombinieren ihrer Ergebnisse per Mehrheitsabstimmung. Jeder Durchlauf erhielt eine andere Reihenfolge des Diffs, was das Modell zu unterschiedlichen Gedankengängen anregte. Wenn mehrere Durchläufe unabhängig voneinander dasselbe Problem markierten, werteten wir das als ein stärkeres Signal dafür, dass der Bug real war.
Nach wochenlangen internen, qualitativen Iterationen landeten wir bei einer Version von Bugbot, die andere Code-Review-Tools auf dem Markt übertraf und uns das Vertrauen gab, sie zu veröffentlichen. Sie verwendete folgenden Ablauf:
- Acht parallele Durchläufe mit zufälliger Diff-Reihenfolge ausführen
- Ähnliche Bugs in einer Gruppe zusammenfassen
- Mehrheitsabstimmung, um Bugs herauszufiltern, die nur in einem Durchlauf gefunden wurden
- Jede Gruppe zu einer einzigen, klaren Beschreibung zusammenführen
- Unerwünschte Kategorien herausfiltern (z. B. Compiler-Warnungen oder Dokumentationsfehler)
- Ergebnisse durch ein Validierungsmodell laufen lassen, um Fehlalarme zu erkennen
- Gegen Bugs aus früheren Läufen deduplizieren
Vom Prototyp zur Produktion
Damit Bugbot in der Praxis einsetzbar ist, mussten wir neben der eigentlichen Review-Logik in eine Reihe grundlegender Systeme investieren. Dazu gehörte, den Repository-Zugriff schnell und zuverlässig zu machen, indem wir unsere Git-Integration in Rust neu aufgebaut und die Menge der abgerufenen Daten minimiert haben, sowie Rate-Limit-Monitoring, Request-Batching und eine Proxy-basierte Infrastruktur hinzuzufügen, um innerhalb der Einschränkungen von GitHub zu arbeiten.
Mit zunehmender Nutzung brauchten Teams außerdem eine Möglichkeit, codebase-spezifische Invarianten wie unsichere Migrationen oder falsche Verwendung interner APIs festzuhalten. Als Antwort darauf haben wir Bugbot-Regeln hinzugefügt, um diese Prüfungen zu unterstützen, ohne sie fest im System zu verdrahten.
Zusammen machten diese Bausteine Bugbot praxistauglich im Betrieb und anpassungsfähig an reale Codebases. Aber sie sagten uns nicht, ob die Qualität tatsächlich besser wurde. Ohne eine Kennzahl zur Erfolgsmessung konnten wir Bugbots Leistung im Einsatz nicht quantitativ bewerten – und das setzte eine Obergrenze dafür, wie weit wir es weiterentwickeln konnten.
Messen, was zählt
Um dieses Problem zu lösen, haben wir eine Kennzahl namens Resolution Rate entwickelt. Sie nutzt KI, um zum Zeitpunkt des PR-Merges zu bestimmen, welche Bugs vom Autor im finalen Code tatsächlich behoben wurden. Bei der Entwicklung dieser Kennzahl haben wir intern jedes Beispiel gemeinsam mit dem PR-Autor stichprobenartig überprüft und festgestellt, dass das LLM fast alle Fälle korrekt als behoben oder nicht behoben klassifiziert hat.
Teams fragen uns oft, wie sie den Impact von Bugbot für sich bewerten können, daher heben wir diese Kennzahl im Dashboard deutlich hervor. Für Teams, die die Wirksamkeit bewerten, ist sie ein deutlich klareres Signal als anekdotisches Feedback oder Reaktionen auf Kommentare. Die Resolution Rate beantwortet direkt, ob Bugbot echte Probleme findet, die von Entwicklerinnen und Entwicklern behoben werden.
Hill-Climbing
Die Definition der Lösungsrate veränderte grundlegend, wie wir Bugbot gebaut haben. Zum ersten Mal konnten wir anhand eines echten Signals Hill-Climbing betreiben, anstatt uns nur auf unser Gefühl zu verlassen. Wir begannen, Änderungen online anhand der tatsächlichen Lösungsraten zu bewerten und offline mithilfe von BugBench zu testen, einem kuratierten Benchmark aus realen Code-Diffs mit manuell annotierten Bugs.
Wir führten Dutzende Experimente mit unterschiedlichen Modellen, Prompts, Iterationszahlen, Validatoren, Kontextverwaltung, Kategoriefiltern und Agent-Designs durch. Viele Änderungen verschlechterten zu unserer Überraschung unsere Metriken. Es stellte sich heraus, dass viele unserer ersten Einschätzungen aus den frühen qualitativen Analysen korrekt waren.
Agentenbasierte Architektur
Wir erzielten die größten Fortschritte, als wir im Herbst Bugbot auf ein vollständig agentenbasiertes Design umgestellt haben. Der Agent konnte über den Diff nachdenken, Tools aufrufen und entscheiden, wo er genauer hinschauen sollte, anstatt einer festen Abfolge von Durchläufen zu folgen.
Die agentenbasierte Schleife zwang uns dazu, unser Prompting neu zu denken. Bei früheren Versionen von Bugbot mussten wir die Modelle einschränken, um Fehlalarme zu minimieren. Mit dem agentenbasierten Ansatz hatten wir jedoch das gegenteilige Problem: Er war zu vorsichtig. Wir wechselten zu aggressiven Prompts, die den Agent dazu ermutigten, jedem verdächtigen Muster nachzugehen und im Zweifel eher potenzielle Probleme zu markieren.
Außerdem eröffnete die agentenbasierte Architektur eine reichhaltigere Grundlage für Experimente. Wir konnten mehr Informationen aus dem statischen Kontext in den dynamischen Kontext verlagern, die Menge des anfänglichen Kontexts für das Modell variieren und beobachten, wie es sich anpasste. Das Modell zog sich zur Laufzeit konsistent den zusätzlichen Kontext, den es benötigte, ohne dass im Voraus alles bereitgestellt werden musste.
Dasselbe Setup ermöglicht es uns, direkt am Toolset selbst zu iterieren. Da das Verhalten des Modells durch die Tools geprägt wird, die es aufrufen kann, hatten selbst kleine Änderungen im Tooldesign oder in der Verfügbarkeit einen überproportional großen Einfluss auf die Ergebnisse. Durch mehrere Iterationsrunden passten wir diese Schnittstelle an und verfeinerten sie, bis das Verhalten des Modells zuverlässig mit unseren Erwartungen übereinstimmte.
Wie geht es weiter
Heute überprüft Bugbot jeden Monat mehr als zwei Millionen PRs für Kunden wie Rippling, Discord, Samsara, Airtable und Sierra AI. Wir setzen Bugbot außerdem für den gesamten internen Code bei Cursor ein.
Mit Blick nach vorn rechnen wir damit, dass regelmäßig neue Modelle mit unterschiedlichen Stärken und Schwächen erscheinen werden – sowohl von anderen Anbietern als auch aus unserer eigenen Trainingsarbeit. Weitere Fortschritte erfordern, die richtige Kombination aus Modellen, Harness-Design und Review-Struktur zu finden. Bugbot ist heute um ein Vielfaches besser als zum Zeitpunkt des Launches. In ein paar Monaten erwarten wir erneut deutliche Verbesserungen.
Wir arbeiten bereits aktiv an dieser Zukunft. Wir haben gerade Bugbot Autofix als Beta gestartet, das automatisch einen Cloud Agent startet, um Bugs zu beheben, die während PR-Reviews gefunden werden. Die nächsten großen Neuerungen umfassen, Bugbot Code ausführen zu lassen, um seine eigenen Bug-Reports zu verifizieren, und tiefgehende Analysen zu ermöglichen, wenn es auf komplexe Probleme stößt. Außerdem experimentieren wir mit einer Always-on-Variante, die eure Codebasis kontinuierlich scannt, anstatt auf Pull Requests zu warten.
Wir haben bereits große Fortschritte gemacht, die ohne die Beiträge einiger wichtiger Teammitglieder nicht möglich gewesen wären, darunter Lee Danilek, Vincent Marti, Rohan Varma, Yuri Volkov, Jack Pertschuk, Michiel De Jong, Federico Cassano, Ravi Rahman und Josh Ma. Gemeinsam ist es weiterhin unser Ziel, euren Teams zu helfen, die Codequalität aufrechtzuerhalten, während sich eure KI-Entwicklungs-Workflows skalieren.