Michael JohnsonDu kan ge en agent en uppgift, invänta ändringar i ett kodförråd och få ett utkast till pull request att granska. Men tillsammans med koden uppstår en fråga: motsvarar resultatet uppgiften, och har testerna missat något viktigt problem?
Den 4 februari 2026 meddelade GitHub en offentlig förhandsversion av Claude och Codex som kodningsagenter. Företaget uppgav att agenterna kan tilldelas uppgifter från issues och pull requests, varefter deras utkast till PR kan granskas. Det bekräftar att ett sådant arbetssätt har införts i utvecklingsgränssnittet, men bevisar varken tidsbesparingar eller högre kodkvalitet.
Frågan handlar därför inte bara om huruvida en agent kan skriva kod. Det viktiga är vilket arbete en människa måste utföra kring den delegerade uppgiften: formulera begränsningar, följa arbetets gång och bedöma resultatet.
Övervakning är mer än en slutgranskning
I ett förtryck publicerat på arXiv den 21 september 2026 föreslår forskare att övervakning av en kodningsagent ska ses som en process i flera steg. Studien The Work Behind Delegation bygger på observationer och arbetsflödesscheman från 19 erfarna utvecklare. Författarna beskriver sju steg i övervakningen och tillämpar ramen på offentliga utvecklardiskussioner på Reddit.
Bland de arbetssätt författarna beskriver finns att lägga större vikt vid planering, låta andra agenter hantera vissa övervakningsuppgifter och omvandla återkommande instruktioner till material som kan återanvändas. Detta är en analytisk ram, inte en mätning av tidsåtgång: studien fastställer inte hur mycket tid utvecklare lägger på kontroll eller om processen är snabbare än manuellt arbete. På arXiv-sidan anges förtrycket vara under granskning, så slutsatserna bör betraktas som preliminära.
För praktiskt arbete är det användbart att skilja mellan tre aktiviteter. Uppgiftsformulering anger mål och begränsningar. Övervakning hjälper till att upptäcka om agenten avviker från avsikten. Granskning gör det möjligt att bedöma om resultatet kan godkännas med hänsyn till krav, kod och tester. Framgång i ett steg garanterar inte framgång i nästa: en ändring kan verka rimlig men lösa fel uppgift eller kräva omfattande omarbetning.
Erfarenheter från communityn är inte statistik
I en diskussion på r/LocalLLaMA skrev en deltagare att erfarenheten av lokala modeller och agenter hade varit en besvikelse: enligt deltagaren behövde resultatet rättas till och agenterna påminnas om instruktionerna. Andra deltagare i samma tråd beskrev ett arbetssätt som fungerade bättre för dem: att begränsa uppgifterna, arbeta stegvis och granska koden noggrant. Det rör sig om enskilda användarerfarenheter, inte ett jämförbart test av modeller eller en mätning av teamens produktivitet.
De skilda omdömena visar att erfarenheten kan bero på uppgiften, modellen, miljön och arbetssättet. Men utifrån en enda diskussion går det inte att avgöra vilka metoder som är mest effektiva i genomsnitt eller hur ofta problem uppstår. Tråden handlar om lokala modeller, så erfarenheterna bör inte automatiskt generaliseras till alla agentverktyg.
Att en människa deltar innebär inte i sig att delegering är meningslös. Utvecklaren kan dela upp uppgiften, granska ändringarna och förtydliga kraven – och fortfarande ansvara för slutresultatet. Men utan att räkna in tiden för uppgiftsformulering, korrigeringar och granskning går det inte att säga om den totala arbetsinsatsen har minskat.
Ett utkast till PR är inte en godkänd PR
I det arbetssätt GitHub beskriver kan en agent tilldelas en issue och ta fram ett utkast till pull request. Mellan skapandet och godkännandet återstår flera frågor: uppfyller ändringen kraven, har gränsfall beaktats, räcker testerna och passar lösningen projektets arkitektur?
Dessa kriterier kan inte reduceras till ett enda mått. Antalet skapade ändringar är inte detsamma som antalet användbara, och att testerna går igenom bekräftar inte nödvändigtvis alla viktiga egenskaper hos ändringen. Även ett resultat som ser välgjort ut visar inte i sig hur mycket arbete som krävdes för att ta fram och granska det.
För att bedöma den totala effekten måste hela förloppet räknas in: uppgiftsformulering, väntan på resultatet, granskning, korrigeringar och fortsatt underhåll av koden. De källor som behandlas här ger ingen sådan helhetsjämförelse.
Vad går att dra för slutsatser?
Förtrycket erbjuder en ram för att diskutera övervakning, och GitHub har beskrivit ett arbetssätt där en agent tilldelas en uppgift och den förberedda PR:en granskas. Diskussionen på Reddit visar att enskilda användare beskriver både svårigheter och användbara metoder för att arbeta med lokala modeller. Tillsammans gör materialet det möjligt att ställa frågan om hur granskning av delegerad kod ska organiseras, men ger inget svar om nettovinsten i produktivitet.
Utifrån detta går det inte att dra slutsatsen att utvecklare i allmänhet redan har gått från att skriva kod till att övervaka den, att agenter alltid skapar merarbete eller att de ökar produktiviteten i hela branschen. Sådana slutsatser kräver jämförbara mätningar av tid och kvalitet för olika uppgifter och team.
Den praktiska frågan för ett team är mer konkret: vilka ändringar kan en agent förbereda självständigt, vad måste granskas före sammanslagning och vem ansvarar för att resultatet löser den ursprungliga uppgiften? Delegering tar inte bort detta ingenjörsarbete – den förändrar var det börjar och vad det fokuserar på.