Michael JohnsonDu kan gi en agent en oppgave, vente på endringer i et repositorium og få et utkast til en pull request til gjennomgang. Men sammen med koden oppstår spørsmålet: Svarer resultatet på oppgaven, og har testene oversett et viktig problem?
4. februar 2026 kunngjorde GitHub en offentlig forhåndsvisning av Claude og Codex som kodeagenter. Selskapet opplyste at agenter kan tildeles oppgaver fra issues og pull requests, og at utkastet til PR som de utarbeider, deretter kan gjennomgås. Dette bekrefter at en slik arbeidsflyt er tilgjengelig i utviklingsgrensesnittet, men beviser verken tidsbesparelser eller høyere kodekvalitet.
Spørsmålet handler derfor ikke bare om hvorvidt en agent kan skrive kode. Det viktige er hvilket arbeid mennesket må utføre rundt den delegerte oppgaven: å sette rammer, følge med på arbeidet og vurdere resultatet.
Tilsyn er mer enn en avsluttende gjennomgang
I et preprint publisert på arXiv 21. september 2026 foreslår forskere at tilsyn med en kodeagent bør forstås som en sammenhengende prosess. Studien The Work Behind Delegation bygger på observasjoner og arbeidsflytskisser fra 19 erfarne utviklere. Forfatterne beskriver sju faser av tilsyn og bruker dette rammeverket på offentlige utviklerdiskusjoner på Reddit.
Blant tilnærmingene forfatterne beskriver, er å legge større vekt på planlegging, overlate noen tilsynsoppgaver til andre agenter og gjøre gjentatte instruksjoner om til materiale som kan brukes på nytt. Dette er et analytisk rammeverk, ikke en måling av tidsbruk: Studien fastslår ikke hvor mye tid utviklere bruker på kontroll, eller om prosessen går raskere enn manuelt arbeid. På arXiv-siden er preprintet markert som under fagfellevurdering, så konklusjonene bør regnes som foreløpige.
I praksis er det nyttig å skille mellom tre handlinger. Oppgaveformulering definerer målet og rammene. Oppfølging gjør det mulig å oppdage om agenten har beveget seg bort fra intensjonen. Kontroll gjør det mulig å vurdere om resultatet kan godtas, sett opp mot kravene, koden og testene. At én fase lykkes, garanterer ikke at den neste gjør det: En patch kan virke overbevisende, men løse feil oppgave eller kreve omfattende omarbeiding.
Erfaringer fra fellesskapet er ikke statistikk
I en diskusjon på r/LocalLLaMA skrev en deltaker at erfaringen med lokale modeller og agenter hadde vært skuffende: Ifølge deltakeren måtte resultatet rettes opp, og agentene måtte stadig minnes på instruksjonene. Andre deltakere i samme tråd beskrev en arbeidsmåte de hadde hatt større nytte av: å avgrense oppgaver, arbeide trinnvis og kontrollere koden nøye. Dette er enkeltstående brukererfaringer, ikke en sammenlignbar test av modeller eller en måling av teamproduktivitet.
Disse ulike tilbakemeldingene viser at erfaringen kan avhenge av oppgaven, modellen, miljøet og arbeidsmåten. Men én diskusjon kan ikke fastslå hvilke praksiser som i gjennomsnitt er mest effektive, eller hvor ofte problemer oppstår. Tråden handler om lokale modeller, så observasjonene derfra bør ikke automatisk overføres til alle agentverktøy.
At et menneske deltar, betyr ikke i seg selv at delegering er nytteløst. En utvikler kan dele oppgaven i deler, kontrollere endringer og presisere kravene – samtidig som vedkommende fortsatt har ansvaret for sluttresultatet. Men uten å ta med tiden som går med til oppgaveformulering, rettelser og kodegjennomgang, kan vi ikke si om den samlede arbeidsmengden er redusert.
Et PR-utkast er ikke en godkjent PR
I GitHub-arbeidsflyten som er beskrevet, kan en agent få tildelt en issue og produsere et utkast til en pull request. Mellom opprettelsen og godkjenningen gjenstår flere spørsmål: Oppfyller endringen kravene, er kanttilfellene tatt høyde for, er testene tilstrekkelige, og passer løsningen til prosjektets arkitektur?
Disse kriteriene kan ikke reduseres til én enkelt måling. Antallet endringer som opprettes, er ikke det samme som antallet som er brukbare, og beståtte tester bekrefter ikke nødvendigvis alle viktige egenskaper ved en patch. Selv et resultat som ser godt ut, viser ikke i seg selv hvor mye arbeid som gikk med til å lage og kontrollere det.
For å vurdere den samlede effekten må hele syklusen tas med: oppgaveformulering, venting på resultatet, kodegjennomgang, rettelser og senere vedlikehold av koden. Kildene som er gjennomgått, gir ingen slik samlet sammenligning.
Hva vi kan konkludere med
Preprintet foreslår et rammeverk for å diskutere tilsyn, og GitHub har beskrevet en arbeidsflyt der en agent får tildelt en oppgave og den utarbeidede PR-en kontrolleres. Reddit-diskusjonen viser at enkeltbrukere beskriver både utfordringer og nyttige måter å arbeide med lokale modeller på. Til sammen gjør dette det mulig å stille spørsmål om hvordan kontroll av delegert kode bør organiseres, men materialet gir ikke svar på netto produktivitet.
Det er ikke mulig å konkludere ut fra dette at utviklere generelt allerede har gått fra å skrive kode til å føre tilsyn, at agenter alltid skaper merarbeid, eller at de øker produktiviteten i bransjen. Slike konklusjoner krever sammenlignbare målinger av tid og kvalitet på tvers av ulike oppgaver og team.
Det praktiske spørsmålet for et team er mer konkret: Hvilke endringer kan agenten utarbeide på egen hånd, hva må kontrolleres før sammenslåing, og hvem har ansvaret for at resultatet løser den opprinnelige oppgaven? Delegering fjerner ikke dette ingeniørarbeidet – den endrer hvor det begynner, og hva det er rettet mot.