Einen GitHub-Copilot-Pilot jenseits von Vorschlagszahlen messen

Was die Copilot-Metriken von GitHub messen

GitHub gliedert die Copilot-Nutzungsmetriken in Adoption, Engagement, Akzeptanzrate, Codezeilen und Pull-Request-Lebenszyklus. Sie stehen in einem Dashboard mit 28-Tage-Trends, einem Impact-Dashboard, einer API mit Berichten für Organisationen, Repositories und Nutzer sowie in NDJSON-Exporten bereit. Die Daten eines Tages liegen innerhalb von zwei vollen UTC-Tagen vor.

Das meiste stammt aus clientseitiger IDE-Telemetrie, für die vollständigsten Daten braucht es also aktivierte Telemetrie und eine unterstützte IDE- und Erweiterungsversion. Serverseitige Telemetrie zählt Nutzer, deren Client-Telemetrie nicht ankommt, trotzdem mit, die Zahl aktiver Nutzer bleibt also belastbar, ihre Aufschlüsselung nach Funktionen und Codezeilen bleibt aber leer. Copilot Chat auf GitHub.com und GitHub Mobile sind nicht enthalten.

Ebene eins: Hat der Pilot tatsächlich stattgefunden?

Nutzungsdaten beantworten, ob das Tool genug verwendet wurde, um es zu beurteilen. GitHubs Leitfaden zur Interpretation nennt ein Verhältnis von wöchentlich aktiven Nutzern zu Lizenzen über 60 Prozent eine gesunde laufende Nutzung. Das Impact-Dashboard ordnet Nutzer Kohorten zu: passiv, code first, agent first und multi-agent, je nachdem, welche Oberflächen sie an mindestens zwei Tagen der letzten 28 genutzt haben.

Nutzen Sie diese Ebene als Voraussetzung, nicht als Urteil, und lesen Sie die Kohorten genau. Passiv heißt nicht untätig: GitHub weist darauf hin, dass jemand, der Copilot Chat oder dem Agent-Modus Fragen stellt, ohne Code-Änderungen zu übernehmen, in der passiven Kohorte bleiben kann. Ein großer passiver Anteil ist ein Grund herauszufinden, wie die Gruppe tatsächlich mit Copilot arbeitet, über Lizenzen, IDE-Setup und eine kurze Umfrage, bevor Sie irgendetwas anderes auswerten.

Ebene zwei: Was mit den Pull Requests passiert

Die API für Nutzungsmetriken liefert tägliche Pull-Request-Aktivität, darunter von Copilot Cloud Agent erstellte Pull Requests, wie viele davon gemergt wurden, ihre mediane Zeit bis zum Merge sowie Vorschläge von Copilot Code Review und wie viele davon übernommen wurden, aufgeschlüsselt nach Kommentartyp. Berichte auf Repository-Ebene ergänzen die Dauer der Review-Phasen für Pull Requests, die Menschen geöffnet und andere Menschen geprüft haben.

Die Tageswerte zeigen den Durchsatz: pro Tag erstellte und gemergte Copilot-Pull-Requests. Erstellung und Merge sind getrennte Ereignisse an unterschiedlichen Tagen, deshalb ist das Verhältnis von Merges zu Erstellungen in derselben Woche keine Merge-Quote und kann über 100 Prozent liegen. Für eine Merge-Quote verfolgen Sie eine feste Menge von Copilot-Pull-Requests anhand ihrer ID von der Erstellung über ein festgelegtes Zeitfenster, etwa 14 Tage, mit den Daten Ihres Git-Hosts. Der Review-Aufwand ist eine weitere Lücke: GitHubs Dauer der Review-Phasen schließt von Bots erstellte Pull Requests aus, Copilot Cloud Agent eingeschlossen, ebenso solche, die ohne qualifizierendes menschliches Review gemergt wurden. Messen Sie die Review-Zeit für Agenten-Pull-Requests daher ebenfalls aus den Ereignissen Ihres Git-Hosts.

Ebene drei: Daten, die GitHub nicht hat

Ob gemergte Arbeit gehalten hat, steht in Ihrer eigenen Historie. Commits von Copilot Cloud Agent haben Copilot als Autor und den anfragenden Entwickler als Co-Autor, sodass sich seine Änderungen leicht kennzeichnen lassen. Erfassen Sie über diese Kennzeichnung pro Team und Repository:

• Nacharbeit: Folge-Commits, die eine gemergte Änderung innerhalb eines vereinbarten Zeitfensters korrigieren
• Reverts sowie Copilot-Pull-Requests, die ohne Merge geschlossen wurden
• Review-Zeit und Review-Runden pro Copilot-Pull-Request aus den Ereignissen Ihres Git-Hosts, da GitHubs Phasendauern von Bots erstellte Pull Requests auslassen
• Ausgaben aus Ihren Abrechnungsdaten, geteilt durch gemergte Änderungen ohne Nacharbeit

Wo die Zahlen in die Irre führen

• Akzeptanzrate und Codezeilen zählen Output. GitHub nennt Codezeilen ein richtungsweisendes Maß, und Bearbeitungen durch den Agenten folgen keinem Ablauf aus Vorschlagen und Annehmen.
• Der Adoption Multiplier vergleicht unterschiedliche Nutzergruppen. GitHub selbst sagt, dass Teamzusammensetzung und Erfahrung ihn ebenso beeinflussen können wie die Nutzung und dass seine ROI-Ansicht Zusammenhänge zeigt, keine Ursachen.
• Berichte auf Teamebene lassen Teams mit weniger als fünf Copilot-Lizenzen aus, sodass die Teamzeilen in Summe unter der Gesamtzahl der Organisation liegen.
• Metriken auf Organisationsebene zählen einen Nutzer in jeder Organisation, der er angehört, deshalb lassen sich Organisationswerte nicht addieren.

Ein Entscheidungsblatt für die Fortsetzung

Die folgenden Schwellen sind hypothetisch und sollten durch Ihre eigenen ersetzt werden, die vor dem Pilot vereinbart und pro Team und Aufgabentyp ausgewertet werden:

• Ausweiten: Die aktive Nutzung ist in der Pilotgruppe stabil, die Merge-Quote der verfolgten Copilot-Pull-Requests erreicht einen vorab festgelegten Wert, und Nacharbeit, Reverts und Review-Zeit liegen nicht über der Ausgangslage.
• Halten und nachbessern: Die Nutzung ist gesund, aber Nacharbeit oder Review-Runden haben zugenommen. Verbessern Sie Repository-Anweisungen, Setup-Schritte und das Formulieren von Aufgaben und messen Sie erneut.
• Verlängern: zu wenig Nutzung oder zu wenige gemergte Pull Requests für ein Urteil. Der Pilot hat die Frage noch nicht beantwortet.
• Beenden: Die Nutzung blieb nach der Einführung niedrig, oder der Review-Aufwand stieg, ohne dass mehr Arbeit gemergt wurde.

Einen fairen Pilot für Coding-Agenten planenEinführung von GitHub Copilot