AI Code Review, das behebt, was es findet
Kadmo Bugbot ist ein Set aus Playbooks, das jeden Pull Request auf seinem Branch prüft, jedes Release auf der Live-Site testet und einen Bug von der Meldung bis zum geprüften Fix bringt.
- 92,5 % der Pull Requests der Agenten bestehen das menschliche Review ohne Nacharbeit
- Commits auf dem Branch statt Kommentaren im Diff, die CI läuft vor dem Merge
- Live QA im Browser auf der deployten Site, nach einem Merge
Dort fangen, wo es am wenigsten kostet
Ein Bug, der im Review auffällt, kostet Minuten. Derselbe Bug, von einem Nutzer gefunden, kostet ein Release, und in Produktion kostet er jemandem die Nacht. Kadmo Bugbot stellt an jede dieser Türen ein Playbook: eine Regel auf Ihren Pull Requests, einen Durchlauf über das, was deployt ist, einen Lauf für jeden neuen Bug.
Jeder dieser Wege bearbeitet ein Ticket, und das Ticket bewahrt den Verlauf: den Bericht jedes Schritts, sein Verdict und wer was entschieden hat. Von den Pull Requests, die Kadmos Agenten öffnen, bestehen 92,5 Prozent das menschliche Review ohne Nacharbeit.
Jeder Pull Request geprüft, auf seinem Branch
Eine Regel auf der Kadmo-App für GitHub startet das Review, sobald ein Pull Request geöffnet wird oder sich ändert: von Menschen, von Ihren Agenten oder von beiden, in den Repositories, die Sie wählen, oder nur auf eine Erwähnung oder ein Label eines Collaborators.
Der Reviewer checkt den Branch auf seiner eigenen Maschine aus, liest das Ticket, behebt, was er findet, lässt die CI laufen und berichtet im Ticket. Seine Änderungen sind Commits, keine Vorschläge. Ein QA-Agent liest denselben Pull Request gegen die Akzeptanzkriterien.
Der Merge bleibt bei Ihnen, oder das Playbook mergt und hält bei einem Konflikt oder einer fehlgeschlagenen CI an.
Playbook · Pull-Request-Review
Getestet auf der Live-Site, dort, wo Ihre Nutzer sind
Das Review liest den Code. Der QA-Durchlauf benutzt das Produkt: Ein Agent klickt sich in einem eigenen Browser durch einen Bereich der deployten Site, über Sessions hinweg, und postet jeden Befund im Epic, sobald er ihn findet.
Die Konsolidierung führt die Befunde nach Ursache zusammen, schlägt die Tickets vor und legt sie auf Ihr Ja an. Nach einem Merge läuft zehn Minuten später ein Regressionstest auf der deployten Site, oder aus Ihrer CI, sobald ein Workflow endet.
Lassen Sie eine Bildschirmaufzeichnung mitlaufen, und ein Befund kommt mit dem Video dessen, was der Agent gesehen hat.
Playbook · QA Pass
Von der Bugmeldung zum geprüften Fix, in einem Lauf
Bug Fix sind fünf Agentenschritte, jeder endet in einem Verdict, das ein Gate liest: auf der Live-Site reproduzieren, die Ursache finden, beheben und den Pull Request öffnen, mergen, nach dem Deploy erneut testen.
Eine Meldung, die sich nicht reproduzieren lässt, beendet den Lauf ohne Pull Request. Ein fehlgeschlagener Retest hält ihn für einen Menschen an. Ist das Ticket erledigt, prüft Validate resolution das Repository gegen das, was das Ticket verlangt hat.
Er startet so, wie Ihr Team Bugs ohnehin meldet: über eine Regel auf neue Bugs, den Issue-Typ, @kadmo auf dem Ticket, eine Nachricht in Slack oder Teams oder einen Sentry-Fehler, der zum Ticket mit Belegen wird. Hotfix lässt Triage und Regression für die dringenden Fälle aus.
Playbook · Bug Fix
Ein Reviewer, der Ihr Produkt kennt
Ein Reviewer ist so gut wie das, was er weiß. Skill Discovery schickt einen Agenten durch Ihre Repositories und Ihr Produkt und schreibt, was er findet, Modul für Modul in Ihr Skill Pack, jedes mit einem Konfidenzwert.
Das Pack ist Ihr Git-Repository, geprüft wie Code. Ein Reifewert pro Bereich sagt, wo QA-, Engineering- und Planungsjobs sinnvoll sind. Setzen Sie eine Zielkonfidenz, und Kadmo entdeckt weiter, bis sie erreicht ist.
Playbook · Skill Discovery
Neben einem Reviewer im Diff
Cursors Bugbot und GitHubs Copilot Code Review kommentieren die Zeilen eines Diffs, und den Fix machen Sie, oder Sie nehmen den Vorschlag an. Wo ein zweites Augenpaar der Engpass ist, ist das das richtige Werkzeug. Kadmo Bugbot beginnt an demselben Pull Request und macht weiter.
| Ein Reviewer im Diff | Kadmo Bugbot | |
|---|---|---|
| Das Review | Kommentare an den Zeilen | Commits auf dem Branch, die CI läuft, bevor jemand mergt |
| Der Test | Der Diff | Das deployte Produkt, im Browser |
| Nach dem Fix | Ihr Editor | Ein Regressionstest auf der Live-Site, die Lösung validiert |
| Was er weiß | Eine Regeldatei | Ihr Skill Pack, mit einem Reifewert pro Bereich |
| Wo er läuft | Die Maschinen des Anbieters | Kadmos Maschinen, Ihr Cloud-Konto oder Ihre eigene |
Sie wählen das Modell für jeden Schritt und setzen ein Budget mit Obergrenze.
So beginnt es
Der erste Schritt ist ein Gespräch. In 30 Minuten gehen wir durch, wie Ihr Team heute prüft und testet, und wählen die Repositories für einen Piloten. Der Pilot läuft auf Ihren eigenen Pull Requests und Bugs, auf den Maschinen, die Sie wählen. Was es kostet, folgt aus dem Plan, auf dem Sie es betreiben, und die Seite Preise führt die Pläne auf.
- Gespräch · Sie und KadmoIhr Review- und QA-Setup, durchgegangen und abgesteckt30 Minuten
- Pilot · die AgentenReviews auf Ihren Pull Requests, ein QA Pass auf Ihrer Site, Bugs von Anfang bis Ende behobenIhre Tickets
- Entscheidung · SieWas die Reviews gefunden haben und was jeder Fix gekostet hat, auf den TicketsSie entscheiden
- Rollout · Ihr TeamDie Regel auf jedem Repository, Agenten auf den Maschinen Ihrer WahlLäuft
Einrichten
Eine Regel unter Automations startet es: ein GitHub-Trigger auf geöffnete und aktualisierte Pull Requests, der den Review-Workflow oder Ihr eigenes Playbook startet. Leiten Sie Ihren QA-Issue-Typ auf QA Pass, legen Sie eine Regel für das Ende der CI an, schicken Sie Bugs per Issue-Type-Routing an Bug Fix und starten Sie Skill Discovery aus Capabilities › Skills. Eine Bildschirmaufzeichnung ist ein Häkchen beim Start des Laufs.
Fragen
Braucht Kadmo Bugbot Jira?
Nein. Es bearbeitet das Ticket dort, wo Ihr Team es führt: Jira, Linear, Notion oder Kadmos eigener Tracker, wenn keiner verbunden ist. Eine GitHub-Regel bearbeitet das Ticket, das die Beschreibung des Pull Requests nennt.
Welche Git-Hosts starten ein Review?
Die Regeln hören auf die Kadmo-App auf GitHub. Die Agenten arbeiten auf GitHub, GitLab, Bitbucket und Kadmo Git, und ein Merge-Gate prüft den Pull Request auf dem Host, der ihn hält.
Prüft es auch die Pull Requests meiner eigenen Agenten?
Ja. Der Autorenfilter der Regel wählt jeden Autor, nur Menschen, nur Ihre Agenten oder einen einzelnen Login. Der eigene Kommentar eines Bots startet die Regel nie erneut, ein Reviewer kann sich also nicht selbst auslösen.
Mergt es von allein?
Nur, wo das Playbook es so festlegt. Der Review-Schritt ohne Merge hält bei bereit zum Merge an und überlässt ihn Ihnen. Review + Merge mergt, und ein Konflikt oder eine fehlgeschlagene CI hält den Lauf für einen Menschen an.
Was weiß der Reviewer über unseren Code?
Das Skill Pack Ihres Kontos: die Module, die Skill Discovery geschrieben hat, die Rollen-Guides Ihres Teams, Ihre Claude Code Skills. Ein Bereich ohne Modul wird allein aus dem Repository gelesen, und die Seite Skills sagt das, bevor Sie starten.
Wo läuft der Code?
Auf der eigenen Maschine des Agenten: bei Kadmo, in Ihrem Cloud-Konto oder auf Ihrer eigenen auf Ubuntu, Docker oder Kubernetes mit einer ausgehenden Verbindung. Der Branch wird dort ausgecheckt und nirgendwo sonst.
Setzen Sie es auf den nächsten Bug, den Ihr Team meldet.
Buchen Sie ein Gespräch, und wir richten das Review mit Ihnen auf einem Ihrer Repositories ein.