AI-Code-Review wird in CI/CD integriert und beseitigt den Engpass der Überprüfung. Wir analysieren, wie die Orchestrierung von Agenten die Latenz und den Lärm reduziert.
Das Problem zeigt sich nicht sofort — bis zu dem Zeitpunkt, an dem die Warteschlange der Merge-Requests schneller wächst, als das Team sie abarbeiten kann. Klassische Code-Reviews erfassen Bugs gut, skalieren jedoch schlecht: Der Reviewer wechselt den Kontext, hinterlässt Anmerkungen, der Autor antwortet, der Zyklus wiederholt sich. Infolgedessen wird die Latenz der ersten Antwort in Stunden gemessen. Der Versuch, den Prozess durch AI-Code-Review zu beschleunigen, ging zunächst den naiven Weg: ein LLM, großer Prompt, Analyse des Diffs. Dies führte zu dem erwarteten Effekt — Lärm, Fehlalarme und Ratschläge ohne Kontext. Bei komplexen Codebasen degradiert dieser Ansatz, da das Modell die Grenzen der Aufgabe nicht hält und die Prioritäten nicht versteht.
Die Lösung verschob sich von „einem intelligenten Modell“ zur Orchestrierung spezialisierter Agenten innerhalb des CI/CD-Pipelines. Anstelle einer universellen Überprüfung wird ein Satz spezifischer Prüfungen verwendet: Sicherheit, Leistung, Codequalität, Dokumentation, Compliance. Ein zentrales Element ist der Koordinator, der die Ausgaben aggregiert, Duplikate beseitigt und die Schwere bewertet. Dies ist ein Kompromiss: mehr Komponenten und Orchestrierungskomplexität, aber weniger Lärm und höhere Genauigkeit. Zusätzlich entsteht eine Kostenkontrolle — verschiedene Aufgaben werden Modellen unterschiedlicher Ebenen zugewiesen, was die Gesamtkosten für Token ohne Qualitätsverlust in kritischen Phasen senkt.
Die Implementierung basiert auf einer Plugin-Architektur. Der Einstiegspunkt delegiert die Konfiguration an Plugins, von denen jedes einen Teil des Verhaltens über den gemeinsamen ConfigureContext hinzufügt. Dies beseitigt die starre Kopplung: VCS, AI-Anbieter und interne Regeln sind isoliert. Der Lebenszyklus wird in drei Phasen unterteilt: Bootstrap (nicht fatale parallele Schritte), Konfigurieren (kritische sequenzielle Abhängigkeiten) und PostConfigure (asynchrone Feinabstimmung). Dieses Design verringert die Wahrscheinlichkeit eines vollständigen Ausfalls der Pipeline aufgrund von nebensächlichen Fehlern und vereinfacht den Austausch von Komponenten.
Die Orchestrierung erfolgt in zwei Schichten. Außen startet der Prozesskoordinator OpenCode und übergibt Daten über stdin, um die Einschränkungen von ARG_MAX für große Merge-Requests zu umgehen. Innen — ein Runtime-Plugin, das parallele Sitzungen von Agenten hochfährt. Jeder Agent arbeitet isoliert, liest nur relevante Patch-Dateien und gibt ein strukturiertes Ergebnis zurück. Dies ist wichtig für den Durchsatz: Es ist nicht notwendig, das vollständige Diff in jeden Prompt zu übergeben, was die Tokenisierung und Latenz erheblich reduziert.
Ein separates ingenieurtechnisches Detail ist die Verwendung von JSONL anstelle von gewöhnlichem JSON für das Logging. In langen CI-Aufgaben kann der Stream abbrechen, und nicht geschlossener JSON wird nutzlos. JSONL löst dies: Jede Zeile ist ein gültiges Objekt. Dies ermöglicht das Lesen von Ereignissen in Echtzeit, das Verfolgen von Nutzungen, Fehlern und Retry-Triggern ohne Pufferung der gesamten Ausgabe. Wenn beispielsweise das Modell die Antwort aufgrund von max_tokens abgeschnitten hat, startet das System den Schritt automatisch neu.
Ein ernsthaftes Problem ist die Wahrnehmung durch den Benutzer. Leistungsstarke Modelle können lange „denken“, was wie ein hängender Job aussieht. Eine einfache Heartbeat-Nachricht alle 30 Sekunden beseitigt fast vollständig falsche Abbrüche. Dies ist ein Beispiel dafür, wie UX die Zuverlässigkeit der Pipeline nicht weniger beeinflusst als die Architektur.
Die Qualität der Überprüfung wird nicht so sehr durch die Modelle, sondern durch die Einschränkungen sichergestellt. Jeder Agent erhält einen strengen Prompt mit Anweisungen, was zu ignorieren ist. Beispielsweise markiert die Sicherheitsprüfung nur tatsächlich ausnutzbare Schwachstellen. Ohne dies verwandelt sich das System in einen Generator hypothetischer Risiken, die das Team schnell zu ignorieren beginnt. Die Ausgabe ist in XML mit Schweregraden standardisiert: kritisch, Warnung, Vorschlag. Dies ermöglicht eine direkte Verknüpfung des Ergebnisses mit den Aktionen des CI — von Genehmigungen bis zur Blockierung von Merge.
Die endgültige Entscheidung trifft der Koordinator. Er führt die Duplikatsbeseitigung durch, verteilt die Kategorien neu und verwirft Fehlalarme. Wenn keine Sicherheit besteht, liest er den Code erneut. Die Politik ist auf das Überspringen ausgerichtet: Einzelne Warnungen blockieren nicht den Merge. Dabei bleibt ein Escape Hatch — ein Kommentar „Break Glass“ erlaubt Änderungen zwangsweise. Dies ist wichtig für Produktionsvorfälle, bei denen die Latenz wichtiger ist als die formale Korrektheit.
Die Ergebnisse werden ohne spezifische Metriken beschrieben, aber verhaltensmäßig macht das System drei Dinge: Es genehmigt automatisch saubere Änderungen, findet genau echte Bugs und blockiert gefährliche Merges. Zusätzlich wird die Latenz der Überprüfung gesenkt und die kognitive Belastung der Ingenieure durch die Filterung von Lärm verringert. Dieser Ansatz erscheint als evolutionäre Verbesserung von CI/CD: LLM ersetzt nicht die Überprüfung, sondern wird zu einem Filter und Priorisierer.