GitHub gjør kodeagenter til et målepunkt

GitHub gjør kodeagenter til et målepunkt

GitHub prøver å flytte diskusjonen om kodeagenter fra modellnavn til driftstall. I en ny gjennomgang av Copilot sitt agent-harness skriver selskapet at modellen gir rå intelligens, mens harnesset avgjør hvordan intelligensen faktisk brukes: hvilke verktøy som kalles, hvordan kontekst håndteres, og hvor mye arbeid som blir gjort per token.

Det er en nyttig presisering for virksomheter som kjøper AI-koding på alvor. Mange ledergrupper spør fortsatt om de skal velge GPT, Claude, Gemini eller en lokal modell. GitHubs poeng er at samme modell kan gi ulike resultater avhengig av agentløpet rundt den. Det er ikke modellkortet alene som bestemmer kostnad, stabilitet eller gjennomføringsevne.

GitHub skriver at Copilot-harnesset er en felles komponent i Copilot SDK, og brukes på tvers av Copilot CLI, Copilot-appen, Copilot code review og flere Microsoft- og GitHub-flater. Dermed får forbedringer i harnesset effekt på flere produkter samtidig. Selskapet presenterer egne målinger på tvers av benchmarker som SWE-bench Verified, SWE-bench Pro, SkillsBench, TerminalBench og et internt Windows-container benchmark kalt Win-Hill.

Metoden er viktigere enn reklameverdien. GitHub sier at de kontrollerer så mange variabler som mulig når Copilot CLI sammenlignes med modell-leverandørenes egne harnesser, som Claude Code for Claude-modellene og Codex CLI for GPT-modellene. Samme modell, samme oppgave, normalisert kontekstvindu, resonneringsinnsats, verktøyvalg og MCP-servere skal brukes i sammenligningene.

GitHubs konklusjon er at Copilot-harnesset ligger på nivå med de andre harnessene på oppgaveløsning, men bruker færre tokens i flere konfigurasjoner. På TerminalBench 2.0 viser selskapet også variasjon mellom kjøringer, ikke bare et pent gjennomsnitt. Det er en modenere måte å snakke om kodeagenter på. Agentresultater svinger, og en enkelt demo er ikke bevis på produksjonsevne.

Samtidig må tallene leses nøkternt. Dette er GitHubs egne målinger, ikke en uavhengig revisjon. Flere av benchmarkene er interne eller kjørt med valgte innstillinger. Det gjør ikke funnene ubrukelige, men det betyr at CIO og CTO ikke bør kopiere konklusjonen ukritisk. De bør kopiere måten å tenke på.

For virksomheter som ruller ut kodeagenter, er riktig måleenhet ikke "hvilken modell svarte best på én oppgave?". Riktig måleenhet er "hva kostet en løst oppgave, hvor ofte lyktes agenten, hvor mye varierer resultatet, og hvilke kontroller ble brukt?" Det er denne overgangen GitHub peker mot.

Copilot støtter ifølge GitHub mer enn 20 modeller på tvers av GPT-, Claude-, Gemini- og MAI-familiene, i tillegg til egne nøkler for åpne og lokale modeller. Det gir et annet innkjøpsbilde enn én leverandør og én modell. Modellen kan velges etter oppgavetype, pris, tilgjengelighet og risikoprofil. Auto-valg kan optimalisere for intensjon og modellhelse. Cross-model critique, som GitHub omtaler som Rubber Duck, kan la én modell kritisere en annens arbeid.

Dette er nyttig, men også krevende. Flere modeller gir mer fleksibilitet, men også mer styring. Hvem bestemmer når en dyr modell brukes? Hvilke data sendes til hvilken leverandør? Logges modellbytte på en måte revisjon og sikkerhet faktisk kan lese? Kan utviklere overstyre policy? Hva skjer når en modell blir midlertidig utilgjengelig eller får nye vilkår?

For CISO er kodeagenter en supply-chain-sak. De kan lese repoer, foreslå patcher, kjøre tester, åpne PR-er og noen ganger kalle interne verktøy. Da holder det ikke å måle "akseptgrad" i IDE-en. Virksomheten må måle hvilke rettigheter agenten har, hvilke kommandoer som kjøres, hvilke hemmeligheter den ikke får se, og hvordan feil håndteres.

For CFO er dette en kostsak. Tokenforbruk er ikke en teknisk detalj når tusen utviklere bruker agenter daglig. Hvis to agentoppsett løser samme type oppgave med ulik tokenbruk og ulik variasjon, påvirker det budsjett, kapasitetsplanlegging og leverandørforhandlinger.

GitHubs innlegg bør derfor ikke leses som at Copilot har vunnet agentkampen. Det bør leses som et tegn på at markedet modnes. Leverandører må nå vise task resolution, kost per løst oppgave, variasjon, metode og kontrollflate. Det er bra for kundene.

Neste steg for norske teknologiledere er å bygge egne evalueringssett. Bruk faktiske repoer, faktiske feil, faktiske sikkerhetskrav og faktiske utviklingsflyter. Sammenlign modell, harness og policy som én pakke. Da blir AI-koding et styrt produktivitetsprogram, ikke en dyr konkurranse i demoer.

Kilder og medier

Primærkilde: GitHub Blog, "Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks", https://github.blog/ai-and-ml/github-copilot/evaluating-performance-and-efficiency-of-the-github-copilot-agentic-harness-across-models-and-tasks/

Kildekreditering: GitHub beskriver egne benchmarker, metode, sammenligning mot Claude Code og Codex CLI, tokeneffektivitet, modellvalg og Copilot-harnesset.

Thumbnail: OpenAI Image 2 / hogby.ai