Cursor Bugbot: Einrichtung, Kosten und KI-Code-Reviews

Meine Einschätzung: Bugbot gehört auf die engere Auswahlliste, wenn ein Team Review-Befunde direkt mit der Fehlerbehebung in Cursor verbinden möchte. Die Freigabe durch Menschen und bestehende automatisierte Prüfungen bleiben dabei bestehen. Bei Azure DevOps zählt allein die Qualität der Reviews, denn Bugbot Autofix ist dort nicht verfügbar. Bei GitLab und Bitbucket sollte vor dem Aktivieren von Autofix geklärt sein, ob automatische Korrekturen direkt im PR-Branch zum Arbeitsablauf passen.

Was prüft Cursor Bugbot?

Bugbot sucht im Diff eines Pull Requests, also in den zum Zusammenführen vorgeschlagenen Änderungen, nach Bugs, Sicherheitsproblemen und Mängeln an der Codequalität. Das lässt sich mit der Prüfung eines Gebäudeumbaus vergleichen: Ausgangspunkt sind die veränderten Stellen, während die Repository-Regeln die Anforderungen des jeweiligen Gebäudes liefern.

Reviews können bei PR-Aktualisierungen starten oder durch die Kommentare cursor review und bugbot run ausgelöst werden. Vorhandene allgemeine und direkt am Code platzierte PR-Kommentare dienen als Kontext, damit Bugbot früheres Feedback berücksichtigen kann. Zu den Befunden gehören Erläuterungen, Korrekturvorschläge und Links, über die sich die Arbeit in Cursor oder im Web fortsetzen lässt. So funktioniert Bugbot.

Der praktische Nutzen liegt darin, früher auf einen Fehler aufmerksam zu werden, der das Review sonst womöglich überstanden hätte. Die Zahl der Kommentare sagt darüber wenig aus. Entscheidend ist, ob ein Befund ein tatsächliches Fehlverhalten benennt, dessen Auslöser erklärt und zu einer sinnvollen Korrektur führt. Tests, Sicherheitsscans und die Prüfung durch die zuständigen Codeverantwortlichen bleiben notwendig.

Bugbot für jedes Repository einrichten

Zunächst wird der Anbieter der Versionsverwaltung über das Integrations-Dashboard von Cursor verbunden. Anschließend lassen sich unter Bugbot in Automations die gewünschten Repositories aktivieren. Das Herstellen der Verbindung und das Aktivieren der Repositories sind getrennte Schritte. Cursor unterstützt GitHub, GitLab, Bitbucket und Azure DevOps Services sowie die dokumentierten selbst gehosteten Varianten der ersten drei Anbieter. Bugbot einrichten.

GitHub

Erforderlich sind Administratorrechte in Cursor und in der GitHub-Organisation. Unter Integrations wird neben GitHub Connect gewählt; besteht bereits eine Verbindung, lautet die Option Manage Connections. Nach der Auswahl von All repositories oder Selected repositories wird die Verbindung abgeschlossen. Danach werden die ausgewählten Repositories in Cursor für Bugbot aktiviert. Für GitHub Enterprise Server gibt es einen eigenen Einrichtungsbereich und Hinweise zur Netzwerkkonfiguration. GitHub-Integration von Cursor.

GitLab

Für GitLab.com werden Administratorrechte in Cursor, Maintainer-Rechte in GitLab und ein kostenpflichtiger Tarif GitLab Premium oder Ultimate benötigt. Cursor setzt Projektzugriffstoken voraus, die GitLab Free nicht bereitstellt. Unter Integrations führt Connect beziehungsweise Manage Connections zur GitLab-Installation. Danach werden die Repositories über Manage → Sync Repos synchronisiert, bevor sie in Bugbot aktiviert werden. Für selbst gehostete Installationen gelten separate Anleitungen zur Verbindung. GitLab-Integration von Cursor.

Bitbucket

Bitbucket Cloud befindet sich derzeit in einer öffentlichen Betaphase. Das Konto wird über Integrations verbunden und Cursor dabei autorisiert. Zusätzlich benötigt der Workspace die Cursor-App: Ein Bitbucket-Workspace-Administrator öffnet in Cursor das Verwaltungsmenü für Bitbucket, wählt Install Cursor app und installiert die App im Workspace. Anschließend öffnet ein Cursor-Teamadministrator mit Workspace-Zugriff in den Bitbucket-Workspace-Einstellungen Forge Apps → Cursor, wählt Connect to Cursor und verknüpft das Team. Danach werden die Repositories in Bugbot aktiviert. Allein die Verbindung eines persönlichen Kontos richtet noch keine App-Identität für Review-Kommentare ein. Für Bitbucket Data Center gibt es einen separaten Einrichtungsweg. Bitbucket-Integration von Cursor.

Azure DevOps

Für Azure DevOps Services gilt die spezielle Bugbot-Einrichtung. Sie erfordert die Zustimmung eines Administrators des Microsoft-Entra-Mandanten. Ein Project Collection Administrator verbindet Azure DevOps und aktiviert Bugbot für ein Repository. Dadurch wird Cursors Dienstprinzipal angelegt, also eine Anwendungsidentität in der Organisation. Ein Projektadministrator muss diese Identität für jedes zu prüfende Projekt der Gruppe Project Administrators hinzufügen. Nur so kann sie die Service Hooks verwalten, deren Benachrichtigungen Reviews auslösen.

Änderungen an Berechtigungen werden unter Umständen erst mit Verzögerung wirksam. Etwaige Einrichtungsfehler müssen behoben werden, bevor die Aktivierung des Repositorys erneut versucht wird. Bugbot unterstützt Team-Repositories, aber keine Repositories im persönlichen Bereich. Bugbot für Azure DevOps einrichten.

Festlegen, wann und für wen Reviews laufen

Für jedes aktivierte Repository lässt sich festlegen, ob Bugbot Aktualisierungen prüft oder nur einmal pro PR läuft. Außerdem können Zulassungs- und Ausschlusslisten für Autoren eingerichtet werden. Über persönliche Einstellungen können Autoren ihre Reviews auf ausdrückliche Erwähnungen oder einen Durchlauf pro PR beschränken und Entwürfe einbeziehen. In aktivierten Repositories kann Bugbot auch Beiträge von Personen prüfen, die nicht zum Cursor-Team gehören. Repository-Einstellungen und persönliche Einstellungen.

Bei Azure DevOps gilt für den manuellen Start eine zusätzliche Voraussetzung: Die Anmeldeadresse der kommentierenden Person bei Azure DevOps muss zu einem Cursor-Konto im Team gehören, dem das Repository zugeordnet ist. Für automatische Reviews gilt diese Einschränkung nicht. Review-Auslöser in Azure DevOps.

So wird .cursor/config/bugbot.yaml konfiguriert

Wenn auch Änderungen am Review-Verhalten ein Code-Review durchlaufen sollen, wird die Konfiguration im Repository abgelegt. Dieses Beispiel stammt aus Cursors Dokumentation zur Repository-Konfiguration:

# .cursor/config/bugbot.yaml
version: 1

triggers:
  drafts: false
  frequency: everyPush # everyPush | oncePerPr

review:
  effort: default # low | default | high | smart
  smartPrompt: ""
  incremental: true

prSummary:
  mode: comment # disabled | description | comment
  riskScore: true

autofix:
  mode: disabled # disabled | newBranch | existingBranch

Die Datei wird unter diesem Pfad relativ zum Stammverzeichnis des Repositorys abgelegt, committet und gepusht. Bugbot liest sie aus dem Basis-Branch des PR, also dem Branch, der die Änderungen aufnimmt. Die Version im Quell-Branch des PR wird nicht verwendet. Eine vorgeschlagene Änderung kann damit nicht ihre eigene Review-Konfiguration umschreiben. Über CODEOWNERS, den Mechanismus zur Zuordnung von Dateiverantwortlichen im Repository, lässt sich festlegen, wer Konfigurationsänderungen prüft.

Alle Felder sind optional. Bei fehlenden oder ungültigen Feldern greift die jeweils nächste Quelle für Einstellungen; Dateien über 64 KB werden ignoriert. Es gilt folgende Rangfolge:

1. Persönliche Einstellungen des PR-Autors für die eigenen PRs.
2. Die YAML-Datei im Repository.
3. Einstellungen im Team- und Organisations-Dashboard.

Diese Reihenfolge ist entscheidend: Ein Blick in die YAML-Datei allein belegt nicht, welche Einstellungen für einen Autor tatsächlich gelten. Außerdem kann autofix.mode die im Dashboard erlaubten Funktionen einschränken, Autofix aber nicht einschalten, wenn es dort deaktiviert ist. Konfigurationsverhalten und Rangfolge.

Das Beispiel legt fest, dass die Zusammenfassung als Kommentar erscheint; es bildet nicht sämtliche Standardwerte des Dashboards ab. Ohne diese Einstellung stehen PR-Zusammenfassungen standardmäßig in der Beschreibung. Inkrementelle Reviews prüfen die Änderungen seit dem vorherigen Bugbot-Review. Eine höhere Prüftiefe kann mehr Zeit und Nutzung für die Fehlersuche beanspruchen. Bei Smart bestimmen die hinterlegten Anweisungen die Prüftiefe. Zusammenfassungen, inkrementelle Reviews und Prüftiefe.

Review-Anweisungen in BUGBOT.md hinterlegen

In .cursor/BUGBOT.md gehört das Projektwissen, das für ein Review erforderlich ist. Die Datei im Stammverzeichnis wird immer einbezogen. Bugbot findet außerdem verschachtelte .cursor/BUGBOT.md-Dateien, indem es von den geänderten Dateien aus die Verzeichnishierarchie nach oben durchsucht. So können für ein Backend-Verzeichnis andere Anweisungen gelten als für das Frontend. Die Editor-Regeln von Cursor unter .cursor/rules/*.mdc gelten nicht für Bugbot. Projektregeln für Bugbot.

Eine hilfreiche Regel benennt eine Bedingung, die immer gelten muss, und den Fehler, auf den zu achten ist. Ein Team für Zahlungsfunktionen könnte beispielsweise festhalten, dass die Wiederholung eines Vorgangs einen Kunden nicht erneut belasten darf. Ein Backend-Team könnte erklären, welche Zustandswechsel einen Audit-Eintrag erfordern. Das sind Vorschläge für Regelthemen, keine Zusicherung, dass Bugbot jeden Verstoß erkennt.

Teamregeln, Projektregeldateien, gelernte Regeln und manuell hinterlegte Repository-Regeln werden kombiniert. Gelernte und manuelle Regeln im Dashboard setzen voraus, dass die Lernfunktion für die Organisation und das Repository aktiviert ist. Die Anweisungen sollten sich auf das Wesentliche beschränken: Jede Regel wird bei 30,000 Zeichen abgeschnitten, alle Review-Regeln zusammen sind auf 100,000 Zeichen begrenzt. Mit den Kommentaren bugbot run verbose=true oder cursor review verbose=true lässt sich prüfen, was tatsächlich geladen wurde. Die Antwort zeigt, welche Regeln einbezogen, gekürzt oder ausgelassen wurden. Regeln und Grenzen.

Wie wird Bugbot heute abgerechnet?

Bugbot wird nach Nutzung budgetiert; Autofix wird separat berücksichtigt. Cursor beschreibt die aktuelle Abrechnung so:

Das sind die aktuellen Abrechnungsbedingungen für Bugbot. Es sollte nicht davon ausgegangen werden, dass das Editor-Kontingent eines Teams auch Bugbot-Reviews abdeckt. Autofix verbraucht Cloud Agent credits, die zu den Konditionen des bestehenden Tarifs abgerechnet werden. Abrechnung von Autofix.

Die im Mai angekündigte Preisänderung gilt für bestehende Abonnements ab ihrer nächsten Verlängerung nach dem 8. Juni 2026. Ein älteres Jahresabonnement kann deshalb bis zur Verlängerung noch zu den bisherigen Konditionen laufen. Cursors Ankündigung zur Preisänderung.

Die aktuelle Bugbot-Dokumentation nennt keinen festen Preis pro Review, der sich einfach in eine Budgetrechnung einsetzen ließe. Die Komplexität des PR, die Häufigkeit der Reviews und die Prüftiefe beeinflussen den Aufwand. Durchschnittskosten pro Durchlauf, die ein Anbieter nennt, dienen als Orientierung; sie garantieren keinen bestimmten Preis für das eigene Repository.

Für die Wirtschaftlichkeitsrechnung werden Review-Kosten + Autofix-Kosten + Arbeitszeit für die Bewertung der Befunde dem vermiedenen Review- und Nachbesserungsaufwand gegenübergestellt. Das bestehende Budget für menschliche Reviews bleibt nötig. Ausschlaggebend sind brauchbare Befunde und eingesparte Aufmerksamkeit – nicht die Fähigkeit eines weiteren Bots, Kommentare zu schreiben.

Autofix und MCP: unterschiedliche Voraussetzungen

Autofix startet einen Cloud Agent, der den Code in einer entfernten Umgebung bearbeitet, Bugbot-Befunde behebt und im PR Rückmeldung gibt. Dafür müssen sowohl die Nutzung nach Verbrauch als auch die Speicherung aktiviert sein. Legacy Privacy Mode erfüllt diese Speicheranforderung nicht. Ein unterstützter Modus wird in Bugbot Automations ausgewählt. Voraussetzungen für Autofix.

Das sind die von Cursor dokumentierten Autofix-Modi. Der Modus für den bestehenden Branch erlaubt höchstens 3 Versuche pro PR, um Schleifen zu verhindern. Meine Empfehlung für den Einstieg: Autofix bleibt ausgeschaltet, bis das Team festgelegt hat, wie generierte Korrekturen geprüft werden. GitHub-Teams können anschließend den Modus mit neuem Branch wählen, um die Änderungen separat zu begutachten.

MCP ist ein Protokoll, über das ein KI-Tool auf andere Tools und zusätzlichen Kontext zugreifen kann. Damit lässt sich auch Bugbots Review-Prozess erweitern. Dazu wird der MCP-Server konfiguriert, und seine Tools werden Bugbot in Automations hinzugefügt. MCP-Unterstützung für Bugbot ist nur in den Tarifen Team und Enterprise verfügbar. Verfügbarkeit von MCP.

Bugbot, CodeRabbit und Greptile im Vergleich

Die Wahl hängt davon ab, welches Tool zum Arbeitsablauf passt und welches Kostenmodell sich verlässlich steuern lässt. Die folgenden Angaben sind veröffentlichte Preise, keine Ergebnisse eines Vergleichstests.

Quellen: Cursor Bugbot, CodeRabbit-Preise, Greptile-Preise. Die CodeRabbit-Beträge bei jährlicher Abrechnung sind auf einen Monat umgerechnet. Greptile-Credits lassen sich weder mit Cursors Nutzungseinheiten noch mit CodeRabbits Gebühren pro geprüfter Datei gleichsetzen.

Für die Budgetplanung unterscheiden sich die Modelle klar: CodeRabbit kombiniert ein Abonnement pro Nutzerplatz mit möglichen Gebühren für zusätzliche Reviews. Greptile verbindet Nutzerplätze mit Credits. Bei Bugbot steht im aktuellen Modell die tatsächliche Review-Nutzung im Mittelpunkt. Allein anhand der Preise pro Nutzerplatz lässt sich nicht seriös bestimmen, welches Tool für ein Team am günstigsten ist.

Den direkten Vergleich vertieft Greptile vs. CodeRabbit. Eine breitere Auswahl bieten CodeRabbit-Alternativen und die besten KI-Tools für Code-Reviews in kleinen Teams.

Wo Bugbot einem Team besonders helfen könnte

Ich würde dort anfangen, wo ein übersehener Fehler mehr kostet als die Aufmerksamkeit, die zur Prüfung eines Befunds nötig ist. Die folgenden Einsatzmöglichkeiten sind nach meiner empfohlenen Reihenfolge geordnet. Sie beschreiben keine gemessenen Ergebnisse.

Die Review-, Kontext-, Regel- und Autofix-Funktionen hinter diesen Beispielen sind in Cursors Bugbot-Anleitung dokumentiert. Ihr Nutzen hängt vom Code und den prüfenden Personen ab.

Welche ergänzenden Tools sich rund um Bugbot lohnen könnten

Die überzeugendste Möglichkeit liegt darin, Entwicklungsverantwortlichen einen klaren Blick auf Review-Kosten und Ergebnisse zu geben. Ein weiterer Kommentargenerator dürfte sich schwerer behaupten, wenn etablierte Tools die Reviews bereits übernehmen.

Kosten und Ergebnisse von Reviews erfassen

Ein Plattformteam könnte ein Dashboard entwickeln, das die Ausgaben eines Repositorys mit den Befunden verknüpft, die Entwickler bestätigt, verworfen oder behoben haben. Käufer wären Entwicklungsverantwortliche. Greptiles Pro-Preis von $30 pro Nutzerplatz und Monat belegt, dass es einen etablierten Markt für kostenpflichtige Review-Tools gibt. Er belegt jedoch nicht, dass diese Kunden auch für eine solche Erweiterung zahlen würden. Greptile-Preise.

Die kleinste sinnvolle Version würde Befunde und Abrechnungsdaten mit einer menschlichen Bewertung ihres Nutzens verbinden. Cursors Enterprise-Review-API stellt Review-Analysen einschließlich Befunden und abgerechneten Kosten bereit; im Kostenfeld kann allerdings ein abgerechneter Betrag fehlen. Eine Version für Kunden ohne Enterprise-Tarif müsste auf freigegebene manuelle Eingaben zurückgreifen, statt Zugriff auf diese API vorauszusetzen. Bugbot-API und Analysen.

Der Haken: Erledigte Kommentare sind nur ein unvollkommener Maßstab für relevante Fehlerfunde. Auch eine lückenhafte Zuordnung von Abrechnungskosten kann ein irreführendes Bild erzeugen. Ich würde diese Lösung zuerst entwickeln, weil sie die wiederkehrende Frage vor einer Vertragsverlängerung beantwortet: Ist dieses Review-Tool seine Gesamtkosten wert?

Review-Richtlinien in Repositories prüfen

Eine Plattform-Engineering-Gruppe könnte ein Tool gebrauchen, das Repositories auf freigegebene Bugbot-Konfigurationen, fehlende Projektregeln und ungeprüfte Änderungen an Richtlinien untersucht. Der monatliche Preis von CodeRabbit Team von $60 pro Entwickler und Monat zeigt, dass Review-Abläufe für Teams eine kostenpflichtige Produktkategorie sind. Ob auch Zahlungsbereitschaft für ein separates Richtlinien-Tool besteht, müsste erst geprüft werden. CodeRabbit-Preise.

Die kleinste Version könnte Repository-Dateien lesen und einen Bericht zur Prüfung durch die Verantwortlichen erstellen. Der Haken: Persönliche Einstellungen haben Vorrang vor YAML. Eine reine Dateiprüfung kann deshalb das tatsächlich wirksame Review-Verhalten nicht bestätigen. Diese Grenze muss sichtbar bleiben. Dashboard-Einstellungen sollten in den Prozess einbezogen werden, soweit autorisierter Zugriff dies ermöglicht. Rangfolge der Bugbot-Konfiguration.

Merge-Freigaben bewusst regeln

Ein verpflichtender Bugbot-Check bedeutet nicht automatisch, dass offene Befunde den Merge blockieren. Standardmäßig führen Befunde zu einem neutralen Ergebnis. Ein vorgeschriebener Status-Check stellt sicher, dass die Prüfung läuft. Die Einstellung fail-on-unresolved-issues sorgt dafür, dass offene Befunde zu einem fehlgeschlagenen Status führen, sofern sie für die Organisation verfügbar ist. Vor dem Vertrauen auf den Branch-Schutz muss diese Einstellung geprüft werden. Statusmeldungen von Bugbot-Checks.

Meine Empfehlung ist, Bugbot als zusätzliche Informationsquelle für die prüfende Person einzusetzen. Ein Bericht ohne Befunde belegt nicht, dass ein Feature seine Anforderungen erfüllt. Auch ein automatisch erzeugter Patch muss genauso gründlich geprüft werden wie anderer Code.

So gelingt der Einstieg am Montag

Als Ausgangspunkt eignet sich ein Repository, dessen Verantwortliche die Fehler benennen können, die Bugbot finden soll. Der zuständige Administrator stellt die Verbindung zum Anbieter her und aktiviert Bugbot für dieses Repository. Die Konfiguration wird in den Basis-Branch committet, dazu kommen gezielte Review-Regeln. Die Budgetverantwortung wird festgelegt; über Autofix wird separat entschieden. Bevor der Einsatz ausgeweitet wird, werden im normalen Review-Alltag hilfreiche Befunde, verworfene Vorschläge und der Zeitaufwand für die Bewertung beider erfasst.

Wenn Review-Berichte oder Repository-Kontrollen in den Entwicklungs- und Auslieferungsprozess integriert werden sollen, unterstützen wir mit KI-Automatisierung.