Jeder Commit, den ich jetzt pushe, wird zuerst von einer KI überprüft, bevor ein Mensch ihn sieht. Nicht, weil ich meinem eigenen Code nicht vertraue – sondern, weil ich meiner eigenen Aufmerksamkeit um 23 Uhr an einem Freitag nicht vertraue, wenn ich versuche, vor dem Wochenende einen Fix zu veröffentlichen.
Der KI-Reviewer findet Dinge, die ich übersehe: eine deklarierte, aber nie verwendete Variable, einen API-Schlüssel, der versehentlich in einem Kommentar gelassen wurde, eine Funktion, die den positiven Pfad behandelt, aber bei leerem Input abstürzt. Kleinigkeiten. Die Art von Dingen, die man durch eine Code-Prüfung erfassen möchte, die aber auch müde menschliche Prüfer übersehen.
So habe ich OpenClaw mit GitHub Actions für eine automatisierte KI-unterstützte Code-Prüfung verbunden.
Die Einrichtung
Trigger: Ein GitHub Action Workflow, der bei jedem Pull Request ausgeführt wird. Wenn ein PR eröffnet oder aktualisiert wird, wird der Workflow ausgelöst.
Was es macht: Der Workflow extrahiert den PR-Diff, sendet ihn zur Überprüfung an OpenClaw und veröffentlicht die Überprüfung als PR-Kommentar. Gesamtzeit der Ausführung: 30-60 Sekunden, abhängig von der Größe des Diffs.
Worauf OpenClaw prüft:
1. Bugs: Nullreferenzen, Off-by-One-Fehler, nicht behandelte Randfälle
2. Sicherheit: hartecodierte Geheimnisse, SQL-Injection-Muster, unsichere Standardeinstellungen
3. Stil: Inkonsistenzen im Code, unklare Variablennamen, fehlende Kommentare bei komplexer Logik
4. Leistung: offensichtliche Ineffizienzen, unnötige Schleifen, nicht optimierte Abfragen
Worauf es nicht prüft: Architekturentscheidungen, Funktionsdesign, Richtigkeit der Geschäftslogik. Diese erfordern 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 dem Hauptbranch extrahieren
3. Diff über die API (oder CLI) an OpenClaw senden
4. Antwort als PR-Kommentar formatieren
5. Kommentar veröffentlichen
Die Extraktion des Diffs ist der wichtige Schritt. Man sendet nicht den gesamten Code – nur die Änderungen. Dies hält die Tokenanzahl im Rahmen (und die Kosten niedrig), während die Überprüfung auf das fokussiert, was tatsächlich geändert wurde.
Bei großen PRs (500+ Zeilen Änderungen) teile ich den Diff nach Datei auf und prüfe jede Datei separat. Dies liefert gezielteres Feedback, als alles auf einmal an das Modell zu werfen.
Die Qualität der Überprüfung
Nach 3 Monaten und etwa 200 überprüften PRs:
Wahre Positiven (reale Probleme erkannt): Etwa 25 % der Überprüfungen. Ungefähr einer von vier PRs hat etwas, das die KI erkennt und das wichtig ist. Am häufigsten: fehlende Fehlerbehandlung, inkonsistente Benennungen, ungenutzte Variablen.
Nützliche Vorschläge (keine Bugs, aber Verbesserungen): Etwa 40 % der Überprüfungen. Stilverbesserungen, Vorschläge zur Lesbarkeit, Dokumentationslücken. Nicht kritisch, aber hilfreich.
Falsche Positiven (falsch oder irrelevant): Etwa 35 % der Überprüfungen enthalten mindestens einen falschen Vorschlag. Die KI missversteht den Kontext, schlägt Änderungen vor, die die Funktionalität beeinträchtigen würden, oder kennzeichnet absichtliche Muster als Probleme.
Die 35 % Falscher-Positive-Quote klingt hoch, ist aber in der Praxis handhabbar. Die Kommentare sind klar als KI-generiert gekennzeichnet, und Entwickler lernen schnell, welche Vorschläge ernst genommen werden sollten und welche ignoriert werden können.
Nützlich Statt Nervig Gestalten
Der Unterschied zwischen einem hilfreichen AI-Reviewer und einem nervigen:
Priorisiere die Ergebnisse. Beschrifte jedes Ergebnis als: 🔴 Bug (beheben vor dem Mergen), 🟡 Warnung (überlegen, zu beheben), 🟢 Vorschlag (optionale Verbesserung). Entwickler befassen sich mit den roten Punkten, überlegen die gelben, und überfliegen die grünen.
Sei konkret. „Es könnte ein Problem mit der Fehlerbehandlung geben“ ist nutzlos. „Die Funktion `processOrder()` in Zeile 47 behandelt nicht den Fall, in dem `order.items` undefiniert ist, was zu einem TypeError führen wird“ ist umsetzbar.
Wiederhole nicht das Offensichtliche. Entwickler wissen, dass sie Tests schreiben sollten. Sag es ihnen nicht bei jedem PR. Konzentriere dich auf spezifische, nicht offensichtliche Ergebnisse.
Kommentaranzahl begrenzen. Begrenze die KI-Überprüfung auf 5 Kommentare pro PR. Wenn es mehr Probleme gibt, priorisiere und zeige die Top 5. Ein PR mit 20 KI-Kommentaren wird völlig ignoriert; ein PR mit 3-5 fokussierten Kommentaren wird gelesen.
Über die Codeprüfung hinaus
Sobald die Integration mit GitHub Actions funktioniert, kannst du sie erweitern:
Generierung von PR-Beschreibungen. Wenn ein PR mit einer leeren Beschreibung eröffnet wird, liest die KI den Diff und erstellt eine Zusammenfassung: was sich geändert hat, warum es wahrscheinlich geändert wurde und worauf man bei der Überprüfung achten sollte.
Analyse der Testabdeckung. Die KI prüft, ob der geänderte Code entsprechende Teständerungen hat. „Du hast `auth.js` geändert, aber `auth.test.js` nicht aktualisiert – war das Update des Tests beabsichtigt oder vergessen?“
Vorschlag für einen Changelog-Eintrag. Basierend auf dem Diff schlägt die KI einen Changelog-Eintrag im entsprechenden Format vor. Der Entwickler genehmigt oder bearbeitet ihn.
Zusammenstellung von Release-Notizen. Wenn es Zeit ist, zu veröffentlichen, fasst die KI alle gemergten PRs seit der letzten Veröffentlichung zusammen und erstellt Release-Notizen. Dies spart 30-60 Minuten pro Veröffentlichung.
Die Kosten
Durchschnittliche Kosten pro PR-Überprüfung: etwa 0,08 $.
Monatliche Kosten für 200 PRs: etwa 16 $.
Zum Kontext: Ein Mensch, der 15 Minuten für die Überprüfung jedes dieser PRs aufwendet, würde 50 Stunden pro Monat für die Codeprüfung aufwenden. Die KI ersetzt die menschliche Überprüfung nicht – sie verarbeitet sie vor, indem sie die mechanischen Probleme erfasst, sodass Menschen sich auf Design und Logik konzentrieren können.
Der Überprüfungsprozess meines Teams jetzt: Zuerst die KI-Überprüfung (automatisiert, 30 Sekunden). Zweitens die menschliche Überprüfung (fokussiert auf das, was die KI nicht bewerten kann, typischerweise 5-10 Minuten statt 15). Gesamte Überprüfungsqualität: höher als zuvor, in kürzerer Zeit.
🕒 Published: