GitHub gjør agentbruk målbar for ledelsen

GitHub gjør nå Copilot-bruk mer lesbar for ledere. Selskapet har lagt inn AI-adopsjonsfaser i Copilot usage metrics API, slik at virksomheter ikke bare ser hvem som bruker Copilot, men hvordan utviklerne faktisk bruker verktøyet.

Endringen kom i GitHubs changelog 29. mai. Den nye klassifiseringen bygger på Copilot-bruk over et rullerende 28-dagers vindu. På brukernivå får rapportene feltet ai_adoption_phase. På organisasjons- og enterprise-nivå får rapportene en samlet visning per fase gjennom totals_by_ai_adoption_phase.

Det høres smalt ut. Det er det ikke. Dette er et tegn på at AI i utviklingsmiljøene flytter seg fra generell adopsjonsprat til styrbare driftsdata. For CIO-er, CTO-er og økonomisjefer er det forskjell på å vite at 72 prosent har åpnet Copilot, og å vite om utviklerne fortsatt primært bruker kodefullføring, eller om de har begynt å jobbe med agentbaserte arbeidsflyter.

GitHub deler brukerne inn i fire faser. Fase 0 er ingen kohort, for brukere som ikke møter kravene. Fase 1 er «code first», der brukeren har jobbet med kodefullføring eller agentmodus i IDE. Fase 2 er «agent first», der brukeren har brukt én GitHub-basert agentflate, for eksempel Copilot cloud agent, Copilot code review eller Copilot CLI. Fase 3 er «multi-agent», der brukeren har brukt to eller flere slike agentflater, eller den nye GitHub Copilot-appen.

Kravet er ikke ett tilfeldig klikk. GitHub skriver at fasene bygger på flater brukeren har brukt minst to dager i løpet av de siste 28 dagene. Klassifiseringen får også et versjonsfelt, først v1, slik at GitHub kan endre logikken når Copilot-produktet får flere flater uten å ødelegge historiske sammenligninger.

For ledelsen er dette mer nyttig enn klassiske aktivitetsmålinger. Rapporteringen kan gruppere engasjerte brukere, brukerinitierte interaksjoner, kodegenerering og aksept, linjer lagt til og slettet, pull requests opprettet, slått sammen og reviewet, samt median tid til merge. GitHub presiserer at aggregerte tall er gjennomsnitt per bruker i fasen, ikke summer. Det betyr at store team ikke automatisk ser mer modne ut bare fordi de er store.

Den praktiske konsekvensen er at AI-programmer kan måles på modenhet, ikke bare forbruk. En utviklingsorganisasjon som har mange «code first»-brukere, men få «agent first»- eller «multi-agent»-brukere, har en annen endringsreise enn en organisasjon der agentflater allerede brukes i code review, CLI og skybaserte utviklingsløp. Det bør gi ulike tiltak. Den første trenger kanskje opplæring og bedre arbeidsmønstre. Den andre trenger sterkere styring, sikkerhetskontroller og klare regler for hva agenter får gjøre på egen hånd.

Dette blir også en ny type styringssignal for AI-investeringer. Mange virksomheter har kjøpt dyre AI-lisenser og rapporterer fremdrift med aktive brukere. Det sier lite om verdien. En utvikler som bruker autocomplete fem ganger i uken, er ikke det samme som et team som lar agenter skrive, teste, reviewe og koordinere endringer i flere repoer. Kost, risiko og gevinst er forskjellig.

CISO bør lese endringen med samme alvor. Når brukere beveger seg fra kodefullføring til agentflater, endres trusselbildet. Agentene kan få bredere kontekst, kjøre kommandoer, foreslå endringer, åpne pull requests eller påvirke review-prosesser. Da holder det ikke å telle aktive seter. Man må vite hvilke arbeidsformer som vokser, hvilke repoer og team som ligger foran, og om kontrollene følger etter.

Det er samtidig lett å misbruke slike tall. En multi-agent-kohort er ikke automatisk mer produktiv. Den kan også ha mer støy, flere feil eller mer review-belastning. GitHubs faseinndeling bør derfor kobles mot kvalitet, sårbarheter, incident-data, testdekning, lead time og kost. Hvis ledelsen kun belønner høyere agentfase, får man fort intern gamification. Det problemet har mange AI-programmer allerede møtt: ansatte optimaliserer for målingen, ikke for bedre leveranser.

Den beste bruken er mer nøktern. Sett en baseline per divisjon og team. Se om agentbruk faktisk henger sammen med kortere tid til merge, bedre review-flyt og lavere repetitivt arbeid. Se også om enkelte team får økt kompleksitet eller flere sikkerhetsavvik. Da kan AI-adopsjon styres som en portefølje, ikke som en intern kampanje.

For norske virksomheter med store utviklingsmiljøer er signalet klart: AI i kodearbeid blir en målt produksjonsmodell. Neste budsjettspørsmål blir ikke om selskapet har Copilot. Det blir hvilke deler av utviklingsapparatet som har gått fra assistanse til agentbasert arbeid, og om styringen er moden nok til å tåle det.

Kilder og medier

Primærkilde: GitHub Changelog, «Copilot usage metrics API adds cohorts for AI adoption», publisert 29. mai 2026: https://github.blog/changelog/2026-05-29-copilot-usage-metrics-api-adds-cohorts-for-ai-adoption/

Kildekreditering: GitHub.

Thumbnail: OpenAI Image 2 / hogby.ai.