Jeder Commit, den ich pushe, wird jetzt von einer KI überprüft, bevor ein Mensch ihn sieht. Das liegt nicht daran, dass ich meinem eigenen Code nicht vertraue — es liegt daran, dass ich meinem Fokus um 23 Uhr an einem Freitag, wenn ich versuche, einen Fix vor dem Wochenende zu deployen, nicht vertraue.
Die KI-Revisionssoftware erkennt Dinge, die ich übersehe: eine deklarierte, aber nie verwendete Variable, einen versehentlich in einem Kommentar gelassenen API-Schlüssel, eine Funktion, die den Glückspfad abdeckt, aber mit einer leeren Eingabe abstürzt. Kleinigkeiten. Die Art von Dingen, die Code-Reviews fangen sollen, aber auch von erschöpften menschlichen Prüfern übersehen werden.
Hier ist, wie ich OpenClaw mit GitHub Actions für eine KI-gestützte automatisierte Codeüberprüfung verbunden habe.
Die Konfiguration
Trigger: Ein GitHub Action-Workflow, der bei jeder Pull Request ausgeführt wird. Wenn eine PR eröffnet oder aktualisiert wird, wird der Workflow ausgelöst.
Was er tut: Der Workflow extrahiert den Diff der PR, sendet ihn zur Überprüfung an OpenClaw und veröffentlicht die Überprüfung als Kommentar zur PR. Gesamtlaufzeit: 30 bis 60 Sekunden, abhängig von der Größe des Diffs.
Was OpenClaw überprüft:
1. Bugs: null-Referenzen, Versatzfehler, unhandled edge cases
2. Sicherheit: Hardcodierte Secrets, SQL-Injection-Muster, unsichere Standardwerte
3. Stil: Inkonsistenzen im Code, unklare Variablennamen, fehlende Kommentare zu komplexer Logik
4. Leistung: Offensichtliche Ineffizienzen, unnötige Schleifen, nicht optimierte Abfragen
Was er nicht überprüft: Architektonische Entscheidungen, Funktionalitätsdesign, Richtigkeit der Geschäftslogik. Dies erfordert menschlichen Kontext, den die KI nicht hat.
Der GitHub Action-Workflow
Der Workflow ist einfach:
1. Code auschecken
2. Diff zwischen dem PR-Branch und main extrahieren
3. Den Diff über die OpenClaw API (oder CLI) senden
4. Die Antwort als PR-Kommentar formatieren
5. Den Kommentar veröffentlichen
Die Extraktion des Diffs ist der entscheidende Schritt. Sie senden nicht den gesamten Code, sondern nur die Änderungen. Das hält die Anzahl der Tokens in einem vernünftigen Bereich (und die Kosten niedrig), während der Fokus der Überprüfung auf dem liegt, was sich tatsächlich geändert hat.
Für große PRs (500+ geänderte Zeilen) teile ich den Diff nach Datei auf und überprüfe jede Datei separat. Das sorgt für ein gezielteres Feedback, als alles auf einmal an das Modell zu senden.
Die Qualität der Überprüfung
Nach 3 Monaten und etwa 200 überprüften PRs:
Wahre Positives (tatsächlich erkannte Probleme): Etwa 25 % der Überprüfungen. Im Grunde genommen hat jede vierte PR etwas, das die KI erkennt und zählt. Am häufigsten: fehlende Fehlerbehandlung, inkonsistente Namen, ungenutzte Variablen.
Nützliche Vorschläge (keine Bugs, sondern Verbesserungen): Etwa 40 % der Überprüfungen. Stilverbesserungen, Lesbarkeitshinweise, Lücken in der Dokumentation. Keine Kritiken, aber hilfreich.
Falsche Positives (Fehler oder irrelevant): Etwa 35 % der Überprüfungen enthalten mindestens einen falschen Vorschlag. Die KI versteht den Kontext nicht, schlägt Änderungen vor, die die Funktionalität brechen, oder markiert absichtliche Muster als Probleme.
Die Fehlerrate von 35 % scheint hoch, aber in der Praxis ist sie handhabbar. Die Kommentare sind klar als von der KI generiert gekennzeichnet, und die Entwickler lernen schnell, welche Vorschläge ernst genommen und welche ignoriert werden können.
Das Nützlich Machen, Anstatt Störend zu Sein
Der Unterschied zwischen einem nützlichen und einem störenden KI-Revisor:
Priorisiere die Erkenntnisse. Kennzeichne jede Erkenntnis mit: 🔴 Bug (beheben, bevor du fusionierst), 🟡 Warnung (in Erwägung ziehen zu beheben), 🟢 Vorschlag (optionale Verbesserung). Die Entwickler kümmern sich um die roten Punkte, ziehen die gelben in Betracht und überfliegen die grünen.
Sei spezifisch. „Es könnte ein Problem mit der Fehlerbehandlung geben“ ist nutzlos. „Die Funktion `processOrder()` in Zeile 47 behandelt nicht den Fall, dass `order.items` undefiniert ist, was eine TypeError auslösen wird“ ist umsetzbar.
Wiederhole nicht das Offensichtliche. Die Entwickler wissen, dass sie Tests schreiben müssen. Sag ihnen nicht bei jeder PR, dass sie das tun sollen. Konzentriere dich auf spezifische und nicht offensichtliche Erkenntnisse.
Begrenze die Anzahl der Kommentare. Begrenze die KI-Überprüfung auf 5 Kommentare pro PR. Wenn es mehr Probleme gibt, priorisiere und zeige die 5 besten an. Eine PR mit 20 KI-Kommentaren wird komplett ignoriert; eine PR mit 3 bis 5 gezielten Kommentaren wird gelesen.
Über die Codeüberprüfung hinaus
Sobald die GitHub Actions-Integration funktioniert, kannst du sie erweitern:
Generierung von PR-Beschreibungen. Wenn eine PR mit einer leeren Beschreibung eröffnet wird, liest die KI den Diff und erstellt eine Zusammenfassung: was sich geändert hat, warum es sich wahrscheinlich geändert hat und worauf bei der Überprüfung geachtet werden sollte.
Analyse der Testabdeckung. Die KI überprüft, ob der geänderte Code entsprechende Tests hat. „Du hast `auth.js` geändert, aber `auth.test.js` nicht aktualisiert — war die Aktualisierung des Tests absichtlich oder vergessen?“
Vorschlagen eines Changelog-Eintrags. Basierend auf dem Diff schlägt die KI einen Changelog-Eintrag im entsprechenden Format vor. Der Entwickler genehmigt oder bearbeitet ihn.
Zusammenstellung von Versionshinweisen. Wenn es an der Zeit ist zu veröffentlichen, fasst die KI alle seit der letzten Veröffentlichung gemergten PRs zusammen und erstellt die Versionshinweise. Das spart 30 bis 60 Minuten pro Veröffentlichung.
Die Kosten
Durchschnittliche Kosten pro PR-Überprüfung: etwa 0,08 $.
Monatliche Kosten für 200 PRs: etwa 16 $.
Um einen Vergleich zu bieten: Ein Mensch, der 15 Minuten für die Überprüfung jeder dieser PRs aufwendet, würde 50 Stunden pro Monat mit der Codeüberprüfung verbringen. Die KI ersetzt nicht die menschliche Überprüfung — sie bereitet sie vor, indem sie mechanische Probleme erfasst, sodass die Menschen sich auf das Design und die Logik konzentrieren können.
Der Überprüfungsprozess meines Teams sieht jetzt so aus: Zuerst die KI-Überprüfung (automatisiert, 30 Sekunden). Dann die menschliche Überprüfung (konzentriert auf das, was die KI nicht bewerten kann, normalerweise 5 bis 10 Minuten anstelle von 15). Die Gesamtqualität der Überprüfung: besser als zuvor, in weniger Zeit.
🕒 Published: