GitHub hat am 23. April 2025 die Sprachabdeckung von Copilot Code Review erweitert. C, C++, Kotlin und Swift werden nun ausdrücklich unterstützt; hinzu kommen laut GitHub weitere verbreitete Sprachen. Für Unternehmen ist das mehr als eine zusätzliche Komfortfunktion: Teams mit nativen Anwendungen, mobilen Produkten oder systemnaher Software können KI-gestützte Review-Hinweise jetzt in mehr Pull Requests einbeziehen. Die entscheidende Frage ist jedoch nicht, ob die Funktion verfügbar ist, sondern unter welchen Bedingungen sie einen verlässlichen Beitrag zum bestehenden Review-Prozess leisten kann.
Was GitHub am 23. April 2025 bestätigt hat
Bestätigt ist zunächst die erweiterte Unterstützung für C, C++, Kotlin und Swift. GitHub erklärte außerdem, Copilot Code Review decke damit mehr als 90 Prozent der Dateitypen ab, die typischerweise in Pull Requests vorkommen. Zugleich soll die Qualität der Vorschläge durch einen besseren Umgang mit Ergebnissen niedriger Konfidenz und unterdrückten Ergebnissen gestiegen sein. Für C# hob GitHub eine verbesserte Versionssensitivität hervor.
Ebenfalls bestätigt ist eine Änderung beim Kontext: Die Prüfung betrachtet laut Veröffentlichung nicht mehr hauptsächlich nur den Diff eines Pull Requests, sondern bezieht die gesamte Datei ein. Daraus können ganzheitlichere Hinweise entstehen. Nicht belegt ist dagegen, dass die Funktion menschliche Reviews ersetzt, Fehler vollständig erkennt oder für jedes Repository dieselbe Trefferqualität erreicht. Solche Schlussfolgerungen dürfen erst aus einem eigenen, kontrollierten Pilotbetrieb gezogen werden.
Welche Repositories eignen sich für einen Pilot?
Aus der Veröffentlichung lässt sich für Unternehmen ein pragmatischer Entscheidungsrahmen ableiten. Ein geeigneter Pilot braucht genügend reale Pull Requests, wiederkehrende Qualitätsprobleme und ein Team, das Vorschläge konsequent bewerten kann. Besonders kritisch sind Repositories, deren Fehler unmittelbar Sicherheit, Zahlungen, Gesundheit oder physische Systeme betreffen. Dort kann die Funktion getestet werden, die Freigaberegeln sollten aber während des Piloten unverändert streng bleiben.
- Sprache und Dateitypen: Enthält das Repository tatsächlich relevante Anteile an C, C++, Kotlin oder Swift?
- Review-Volumen: Entstehen regelmäßig genug Pull Requests, um Nutzen und Fehlalarme nachvollziehbar zu bewerten?
- Risikoklasse: Welche Auswirkungen hätte ein übersehener Fehler, und welche manuellen Gates bleiben deshalb zwingend?
- Messbarkeit: Können angenommene, verworfene und korrigierte Hinweise ohne zusätzliche Schattenprozesse dokumentiert werden?
- Verantwortung: Ist eindeutig geregelt, wer einen Hinweis prüft und wer den Pull Request freigibt?
Rolloutplan: sechs Schritte statt flächendeckender Aktivierung
- Ein abgegrenztes Repository und eine verantwortliche Person bestimmen; bestehende Branch- und Freigaberegeln unverändert lassen.
- Vor dem Start drei bis fünf Qualitätskriterien festlegen, etwa Relevanz, technische Korrektheit, Umsetzbarkeit, Doppelungen und erforderliche Nacharbeit.
- Copilot-Hinweise für einen definierten Zeitraum zusätzlich zum normalen menschlichen Review erfassen, ohne daraus automatische Freigaben abzuleiten.
- Vorschläge nach angenommen, angepasst, verworfen und sicherheitsrelevant klassifizieren; personenbezogene Leistungsrankings vermeiden.
- Nach dem Pilot gemeinsam mit Engineering, Security und gegebenenfalls Compliance entscheiden, welche Repository-Klassen folgen dürfen.
- Für den Betrieb Eigentümer, Eskalationsweg, regelmäßige Stichproben und einen Abschaltweg dokumentieren.
Dieser Ablauf begrenzt Einführungskosten, weil nicht sofort alle Teams Schulungen, Auswertungen und neue Prozessregeln benötigen. Gleichzeitig entsteht eine belastbare Entscheidungsgrundlage. Der Pilot sollte nicht allein die Zahl der Vorschläge messen. Wichtiger ist, ob relevante Hinweise früher sichtbar werden, ob Reviewer weniger Zeit mit Routineproblemen verbringen und wie viel zusätzliche Arbeit durch unklare oder unzutreffende Vorschläge entsteht.
Kosten, Risiken und Betriebsfolgen realistisch bewerten
Die unmittelbare Funktionserweiterung kann den Kreis nutzbarer Repositories vergrößern. Daraus folgt jedoch kein automatischer wirtschaftlicher Vorteil. Kosten entstehen unter anderem durch Konfiguration, interne Abstimmung, Schulung, Auswertung und die Bearbeitung falscher oder wenig relevanter Hinweise. Bei C und C++ kommen projektspezifische Besonderheiten wie Compiler, Standards, Build-Varianten und Speicherverhalten hinzu; bei Kotlin und Swift spielen Framework- und Plattformkontext eine wichtige Rolle. Die Veröffentlichung belegt nicht, dass Copilot jede dieser Besonderheiten gleich gut abdeckt.
Auch der erweiterte Dateikontext sollte zweifach betrachtet werden. Er kann die Relevanz von Vorschlägen erhöhen, verändert aber die Menge des für eine Bewertung herangezogenen Codes. Unternehmen sollten deshalb ihre bestehenden Vorgaben zu Repository-Zugriff, zulässigen Inhalten und sensiblen Komponenten prüfen. Entscheidend bleibt: Ein KI-Hinweis ist ein Prüfimpuls. Die verantwortliche Person muss nachvollziehen können, warum eine Änderung akzeptiert oder verworfen wurde.
Entscheidung für Unternehmen
Für Unternehmen mit C-, C++-, Kotlin- oder Swift-Code ist das Update ein sinnvoller Anlass für einen begrenzten Pilot. Es ist kein Grund, bestehende Reviews zu ersetzen oder sofort alle Repositories einzubeziehen. Der stärkste Rollout verbindet einen passenden Anwendungsfall, unveränderte Schutzgates, wenige verständliche Qualitätsmetriken und eine klare Betriebsverantwortung. Erst wenn die eigenen Ergebnisse zeigen, dass relevante Hinweise die zusätzliche Prüf- und Verwaltungsarbeit überwiegen, sollte die Nutzung schrittweise ausgeweitet werden.