Michael JohnsonSeit dem 5. November können Teams, die GitHub Copilot Code Review verwenden, in API-Berichten sehen, auf welche Kommentare Entwickler reagieren. Am selben Tag ergänzte GitHub Felder, mit denen Administratoren Lücken in der Telemetrie und veraltete Editor-Versionen erkennen können. Die Aktualisierungen geben Führungskräften und Organisationsverantwortlichen eine konkretere Möglichkeit, die Wirkung von KI-Reviews und die Vollständigkeit der Copilot-Nutzungsdaten zu überprüfen.
So lässt sich die Reaktion auf KI-Kommentare messen
Die tägliche Berichtszeile pro Repository `repos-1-day` enthält jetzt das Objekt `copilot_code_review`. Zu den Feldern gehören `total_comments_evaluated`, die Zahl der geprüften Kommentare, und `total_comments_addressed`, die Zahl der Kommentare, auf die Entwickler reagiert haben. Um den Anteil bearbeiteter Kommentare für ein Repository zu berechnen, teilt man den zweiten Wert durch den ersten. Die neuen Felder werden in der Aktualisierung der Copilot Usage Metrics API beschrieben.
GitHub wertet einen Kommentar als bearbeitet, wenn Entwickler den vorgeschlagenen Fix übernehmen, Copilot um dessen Umsetzung bitten, den Code selbst bearbeiten oder antworten, dass der Fix in den nächsten Pull Request aufgenommen wird. Der Bericht schlüsselt Kommentare außerdem nach Schweregrad, Review-Stufe, Kommentartyp sowie danach auf, ob zusätzliche Anweisungen oder Tools vorhanden waren. So kann ein Team beispielsweise untersuchen, ob sich die Reaktionen auf Sicherheitskommentare von denen auf andere Hinweise unterscheiden oder welche Kategorien mehr manuelle Arbeit erfordern.
Die Metrik erfasst eine dokumentierte Reaktion, nicht die bestätigte Qualität der Korrektur. Deshalb sollte man sie zusammen mit der Code-Prüfung und dem Status des Pull Requests betrachten: Ein hoher Anteil bearbeiteter Kommentare zeigt, dass auf die Hinweise reagiert wurde, beweist aber nicht, dass alle Änderungen richtig oder notwendig sind. Wichtig ist auch: Kommentare werden am Tag der Zusammenführung des Pull Requests gezählt, nicht am Tag ihrer Veröffentlichung durch Copilot.
Warum sich die Bearbeitungsquote von der Annahme von Vorschlägen unterscheidet
Die bisherigen Felder erfassten Copilot-Code-Review-Ausführungen und Fälle, in denen Nutzer auf die Schaltfläche zum Übernehmen eines fertigen Vorschlags klickten. Die neue Metrik umfasst weitere Reaktionsmöglichkeiten: Entwickler können den Fix selbst einarbeiten, Copilot darum bitten oder die Änderung auf den nächsten Pull Request verschieben. `total_comments_addressed` gibt daher Auskunft über Reaktionen auf Kommentare, während `total_copilot_applied_suggestions` nur Vorschläge erfasst, die sich mit einer einzigen Aktion übernehmen lassen.
Der Bericht enthält auch `total_merged_no_human_change_request_after_review`: die Zahl der zusammengeführten Pull Requests, die Copilot geprüft hat und bei denen nach dem ersten Review keine Person Änderungen angefordert hat. Die Kennzahlen beschreiben unterschiedliche Arbeitsschritte und lassen sich am besten gemeinsam betrachten: Die erste zeigt die Reaktion auf Kommentare, die zweite den Verlauf des Reviews bis zur Zusammenführung.
Neue Felder zeigen, warum Berichte unvollständig sind
Eine separate Aktualisierung vom 5. November ergänzt Angaben zur Client-Telemetrie und zu Tool-Versionen. Das Feld `client_telemetry_present` zeigt, ob an einem bestimmten Tag Ereignisse aus dem Editor eines Nutzers eingegangen sind; `usage_metrics_requirements` gibt an, ob IDE und Erweiterungen die Mindestversionen für die Metriken erfüllen. Administratoren erhalten außerdem tägliche Zahlen zu Nutzern ohne Telemetrie und zu Nutzern mit mindestens einer veralteten Komponente. Weitere Einzelheiten finden sich im Hinweis zu Lücken in Copilot-Daten.
So lässt sich die Aktivität eines Nutzers von der Vollständigkeit der Berichterstattung unterscheiden. GitHub erklärt, dass ein Nutzer auch dann als aktiv gelten kann, wenn keine Ereignisse aus dem Editor eingegangen sind – in diesem Fall fehlen dem Bericht Details wie die Aufschlüsselung der Nutzung nach Funktionen und Modellen. Mögliche Ursachen sind eine veraltete IDE oder Erweiterung, deaktivierte Editor-Telemetrie sowie ein Proxy oder eine Firewall, die Ereignisse blockieren.
Die beiden Lückenzähler dürfen nicht als Zahl eindeutiger Nutzer addiert werden: Eine Person kann in beiden Gruppen auftauchen. Außerdem garantiert eine aktuelle Editor-Version nicht, dass Telemetrie eingeht – etwa wenn Netzwerkbeschränkungen bestehen bleiben. Fehlt ein Wert oder ist er `null`, kennzeichnet GitHub ihn als nicht verfügbare Daten und nicht als null oder als Beleg dafür, dass kein Problem vorliegt.
Was sich dadurch für Teams ändert
Die Neuerungen ermöglichen es, die allgemeine Copilot-Aktivität durch zwei konkretere Prüfungen zu ergänzen: Was geschieht mit den Kommentaren von Code Review, und wie zuverlässig sind die Daten, auf denen interne Berichte beruhen? Führungskräfte in Entwicklungsteams können Kommentararten und Repositories vergleichen; Administratoren können Nutzer ausfindig machen, für die ein Update der IDE oder Erweiterung oder eine Prüfung der Netzwerkeinstellungen erforderlich ist.
Die Berichte sind auf Organisations- und Unternehmensebene für Nutzer mit den entsprechenden Berechtigungen zum Anzeigen von Copilot-Metriken verfügbar; die Richtlinie für Copilot Usage Metrics muss aktiviert sein. Die Code-Review-Daten finden sich in den Zeilen `repos-1-day`, die Telemetrie- und Versionsfelder in Nutzerberichten für einen und 28 Tage. Die Aktualisierung ist daher vor allem für Organisationen nützlich, die Copilot bereits zentral verwalten: Sie können nun nicht nur die Nutzung des Assistenten untersuchen, sondern auch die Reaktionen auf seine Reviews und die Gründe für unvollständige Messwerte.
