GitHub hat Copilot Code Review am 11. September intern grundlegend erweitert. Im Lite-Level prüft nicht mehr ein einzelner Agent den Pull Request. Stattdessen arbeitet ein Ensemble aus mehreren Agenten parallel und GitHub führt deren Ergebnisse zu einem Review zusammen.
In den eigenen Experimenten meldet GitHub 47 Prozent mehr adressierte High-Severity-Kommentare pro Review, 31 Prozent mehr bei Medium und 11 Prozent mehr bei Low. Gleichzeitig seien die Review-Kosten im Durchschnitt um rund acht Prozent gesunken.
Das sind Herstellerdaten, keine unabhängige Benchmarkreihe. Technisch ist die Änderung trotzdem relevant, weil sie eine andere Frage beantwortet als die üblichen Modellvergleiche: Wie viel Qualität entsteht durch die Organisation mehrerer Agenten, selbst wenn das zugrunde liegende Modell gleich bleibt?
Lite bedeutet jetzt mehrere Perspektiven statt eines einzelnen Laufs
GitHub beschreibt das neue Verfahren als Ensemble of Agents. Jeder Agent untersucht den Code aus einer eigenen Perspektive. Die Ergebnisse werden anschließend zu einem gemeinsamen Review konsolidiert.
Damit verändert sich die Fehlerlogik. Ein einzelner Reviewer kann einen problematischen Pfad übersehen, weil er sich früh auf eine Erklärung festlegt oder nur einen Teil des Diffs verfolgt. Mehrere unabhängige Läufe erhöhen die Chance, dass mindestens ein Agent einen anderen Pfad nimmt.
Das ähnelt klassischen Ensemble-Verfahren aus Machine Learning, nur dass hier keine Klassifikatoren abstimmen. Stattdessen erzeugen mehrere agentische Analysen strukturierte Findings, die zu einem Review zusammengeführt werden.
GitHub veröffentlicht nicht im Detail, wie viele Agenten beteiligt sind, wie stark sie sich in Prompts oder Rollen unterscheiden und nach welchen Regeln Konflikte zwischen Findings aufgelöst werden. Ohne diese Informationen lässt sich der genaue Beitrag einzelner Komponenten nicht isolieren.
Mehr Tools verändern Code Review stärker als ein längerer Prompt
Parallel zum Agent-Ensemble erweitert GitHub die Tool-Nutzung des Review-Systems. Copilot kann jetzt den vollständigen Satz von Shell-Tools aus dem Copilot SDK verwenden. Die Ausführung läuft hinter GitHubs Agent Firewall.
Der Reviewer kann damit unter anderem Builds starten, Tests ausführen, gezielte Skripte verwenden und Informationen aus verfügbaren Tools oder APIs abrufen.
Ein Review wird dadurch von einer statischen Diff-Analyse zu einer kleinen, isolierten Entwicklungsaufgabe.
Wenn eine Änderung beispielsweise einen Typfehler erzeugt, muss der Agent den Fehler nicht ausschließlich aus dem Patch ableiten. Er kann den Build ausführen. Wenn eine neue Funktion bestehende Tests bricht, kann er das tatsächliche Testergebnis in seine Bewertung einbeziehen.
Diese Fähigkeit ist für die Qualität wichtiger als viele sprachliche Verbesserungen an einem Review-Modell. Ein System mit Zugriff auf Compiler und Tests kann Aussagen gegen deterministische Werkzeuge prüfen.
47 Prozent mehr adressierte High-Severity-Kommentare ist nicht gleich 47 Prozent bessere Reviews
Die von GitHub genannte Kennzahl braucht eine saubere Einordnung.
Gemessen wurde die durchschnittliche Zahl adressierter Kommentare pro Review. Für High-Severity-Findings stieg sie laut GitHub um 47 Prozent.
Das bedeutet nicht automatisch, dass das System 47 Prozent mehr reale Bugs findet. Ein Kommentar kann korrekt sein, aber auch unterschiedlich formuliert, priorisiert oder vom Entwickler verschieden behandelt werden. GitHub ergänzt, dass Entwickler in Experimenten mehr positives Feedback auf Kommentare gaben und weniger Nits auftraten. Die Rohdaten und vollständige Evaluationsmethodik sind im Changelog jedoch nicht veröffentlicht.
Für einen Produktvergleich wäre diese Datenlage zu dünn. Für die Architekturentscheidung ist sie trotzdem ein brauchbares Signal: GitHub selbst sieht offenbar genug Nutzen in paralleler agentischer Analyse, um sie sogar im günstigeren Lite-Level einzusetzen.
Multi-Agent muss nicht automatisch teurer sein
Naheliegend wäre die Annahme, mehrere Agenten vervielfachten die Kosten. GitHub meldet für das neue Verfahren stattdessen rund acht Prozent niedrigere Review-Kosten.
Wie diese Einsparung genau entsteht, wird nicht offengelegt. Möglich sind kürzere spezialisierte Läufe, besseres Routing oder weniger teure Nacharbeit. Ohne Token- und Laufzeitdaten wäre eine genauere Erklärung Spekulation.
Die Zahl passt aber zu einem Muster, das auch bei anderen agentischen Systemen sichtbar wird: Ein großer monolithischer Lauf ist nicht zwingend effizienter als mehrere begrenzte Tasks.
Ein Agent, der nur nach Sicherheitsproblemen sucht, muss nicht gleichzeitig Stil, Architektur und Tests vollständig analysieren. Wenn die Orchestrierung die Aufgaben sauber trennt und Ergebnisse dedupliziert, können spezialisierte Läufe trotz zusätzlicher Parallelität günstiger werden.
Selbstauflösende Review-Kommentare verändern den Workflow
GitHub hat neben der Analyse auch den Review-Zustand verändert. Wenn ein Entwickler einen Copilot-Kommentar in einem späteren Commit behebt, kann Copilot den Thread beim erneuten Review automatisch als gelöst markieren.
Das ist keine spektakuläre Modellfunktion, spart aber einen typischen manuellen Schritt: Nach einem Fix bleibt nicht zwangsläufig eine Liste veralteter Kommentare offen, die einzeln geschlossen werden muss.
Bei angewendeten Autofix-Vorschlägen erzeugt Copilot außerdem eine zum Änderungskontext passende Commit Message statt eines generischen Standardtexts.
Damit übernimmt der Agent zunehmend auch Verwaltungsarbeit rund um den eigentlichen Review.
Der relevante Vergleich ist Harness gegen Harness
Quavons bisherige Agent-Evals zeigen bereits, dass Repository-Kontext und Orchestrierung Modellranglisten deutlich verschieben können. Copilot Code Review liefert jetzt ein ähnliches Signal aus einer anderen Richtung.
GitHub nennt kein neues Review-Modell als Kern der Verbesserung. Geändert wurden Agent-Ensemble, Toolzugriff und Workflow-Logik.
Wenn sich die Herstellerwerte in realen Repositories bestätigen, wäre das ein Argument gegen eine zu einfache Bewertung von Coding-AI über Modellnamen. Zwei Produkte können dasselbe Basismodell verwenden und trotzdem sehr unterschiedliche Ergebnisse liefern, weil eines Tests ausführen, mehrere Analyseläufe kombinieren und Findings über den gesamten Pull-Request-Lebenszyklus verwalten kann.
Eine Zahl fehlt noch: Wie verändert das Ensemble die False-Positive-Rate? Mehr adressierte High-Severity-Findings sind hilfreich. Für Teams mit vielen Pull Requests ist aber ebenso wichtig, wie viele zusätzliche Kommentare am Ende doch keine Änderung rechtfertigen. GitHubs Changelog liefert dafür noch keinen Wert.