Arbetsflöde för kodgranskning med flera agenter: två granskare, en slutlig skribent
Jag stöter hela tiden på samma begränsning när jag använder flera AI-kodningssessioner. Enligt min erfarenhet hittar parallella sessioner olika kodvägar, men deras meningsskiljaktigheter blir kvar i separata trådar. Jag blir meddelandebussen och kopierar en granskning till en annan session samtidigt som jag avgör vilken modell som förstod filen.
Den bättre designen är ett arbetsflöde för kodgranskning med flera agenter och tre tydliga roller. Två AI-sessioner granskar samma filrevision oberoende av varandra. De utbyter resultat och ifrågasätter varandras bevis. En tredje session tar emot beslutsunderlaget, skriver en patch och kör kontrollerna.
Behandla filen som en gemensam, oföränderlig indata under granskningen. Ge en session skrivrättigheter när granskningen har nått en slutsats.
Detta skiljer sig från min nuvarande hybridloop för AI-kodgranskning→, där en modell skriver och en andra modell granskar varje ändring. Den loopen ger redan granskaren användbar självständighet. Nästa experiment skjuter upp skrivandet: de två första sessionerna granskar båda, och en tredje session börjar koda först efter att deras oenighet har lett till ett beslutsunderlag.
Detta mönster ligger redan nära det som dagens agentverktyg stöder. OpenAI:s dokumentation om Codex-underagenter rekommenderar parallella agenter för läsintensiv utforskning, tester, triage och granskning, samtidigt som den varnar för att parallella skrivintensiva arbetsflöden skapar konflikter och samordningskostnader. Den saknade delen är ett förstklassigt lager för diskussion och syntes mellan granskarna och skribenten.
Varför behöver ett arbetsflöde för kodgranskning med flera agenter en enda skribent?
Parallell analys ger dig olika hypoteser om fel utan att skapa flera konkurrerande patchar.
En granskare kan följa beteenden och invarianta villkor. Den andra kan leta efter säkerhetsproblem, race conditions, saknade tester eller brutna API-kontrakt. De börjar från samma commit SHA och uppgift, men får olika granskningsinstruktioner. Den separationen minskar risken för att båda sessionerna följer samma första idé.
Anthropic beskriver ett närliggande produktionsmönster i Building effective agents: flera modellanrop kan granska kod ur olika perspektiv, medan ett orkestratör–arbetare-arbetsflöde delegerar arbete och sammanställer resultaten. Anthropic rekommenderar också team att bara lägga till agentisk komplexitet när den förbättrar uppmätta resultat. Tre sessioner kostar mer tokens och tid än en, så arbetsflödet behöver en anledning att finnas.
Samtidig mutation är sällan den anledningen. Om två agenter redigerar samma arbetskopia måste systemet hantera inaktuell kontext, överlappande hunkar och delvis tillämpade antaganden. Git erbjuder redan en säkrare primitiv: länkade worktrees låter separata sessioner använda isolerat `HEAD`- och indextillstånd samtidigt som de delar samma repositoryhistorik.
Granskarna kan använda worktrees för experiment, men endast integratören bör äga kandidatpatchen.
Vad äger varje AI-session?
| Session | Åtkomst | Obligatoriskt resultat | Får inte göra |
|---|---|---|---|
| --- | --- | --- | --- |
| Granskare A | Skrivskyddad ögonblicksbild | Beteenderisker, brutna invarianta villkor, radreferenser, föreslagna tester | Redigera den slutliga grenen |
| Granskare B | Skrivskyddad ögonblicksbild | Säkerhet, samtidighet, kantfall, motexempel | Kopiera Granskare A:s slutsats utan bevis |
| Integratör | Exklusiv skrivåtkomst | Accepterad patch, avvisade fynd med motiveringar, testresultat, slutlig diff | Skriva om utanför den överenskomna omfattningen |
Den tredje agenten är inte automatiskt smartare. Dess fördel kommer från ägarskapet. Den får avgränsade bevis, gör konfliktlösningen tydlig och producerar en enda granskningsbar diff.
Jag skulle också hålla granskarna ovetande om varandras första genomgång. En kontrollerad studie av debatt mellan flera agenter fann att majoritetstryck kan undertrycka oberoende korrigering. Tidig dialog kan förvandla två granskare till en upprepad åsikt. Oberoende fynd bör komma först; diskussionen bör börja efter att båda har lämnat sina första bevis.
Hur bör granskarna diskutera en fil?
Fritt formulerad chatt är användbar för människor, men ett kodningsarbetsflöde behöver en kompakt fyndlogg. Varje påstående bör innehålla tillräckligt med bevis för att integratören ska kunna verifiera det utan att återskapa en privat tankekedja.
{ "id": "F-03", "revision": "8a31f2c", "file": "src/auth/session.ts", "lines": "84-103", "claim": "A refresh failure can leave the previous session active", "evidence": "The error branch returns before clearSession()", "risk": "stale authorization state", "proposed_test": "refresh 401 clears the active session", "confidence": "high", "status": "disputed" }
Den andra granskaren kan acceptera fyndet, vederlägga det med ett argument baserat på nåbar kod eller begränsa dess omfattning. Loggen bevarar båda ståndpunkterna. Enighet bevisar inte i sig korrekthet, och ett självsäkert stycke bör inte väga tyngre än ett reproducerbart test.
Agentprotokoll rör sig i den här riktningen. Googles Agent2Agent-protokoll modellerar samarbete genom uppgifter, meddelanden, tillstånd och artefakter. Ett lokalt kodningssystem behöver inte hela protokollet för att låna kontraktet: använd typade meddelanden, stabila ID:n, explicit status och beständiga artefakter i stället för en ostrukturerad transkription.
Min brygga för AI-kollegial granskning→ paketerar redan en diff, fokusfrågor och ett strukturerat utlåtande för en andra modell. Ett arbetsflöde med tre sessioner behöver nästa lager: två granskningspaket som kan referera till, bestrida och lösa samma fynd-ID:n innan skribenten får dem.
Vad måste skribenten få innan redigering?
Integratören bör inte få två långa chatthistoriker. Den behöver ett litet överlämningspaket:
Skribenten läser sedan om den aktuella filen och jämför dess revision med överlämningen. En avvikelse stoppar skrivningen. Den enda kontrollen förhindrar att en giltig granskning av gårdagens fil blir en trasig patch mot dagens kod.
Det är också här behörigheter bör bli deterministiska. Jag har argumenterat för deterministiska AI-agentbehörigheter→ eftersom en prompt som ”redigera bara den här filen” är svagare än en verktygspolicy som gör alla andra sökvägar skrivskyddade. I det här arbetsflödet bör behörighetsmodellen upprätthålla rollfördelningen: granskare får inte skriva, och integratören får inte utöka omfattningen utan ett nytt beslut.
Förbättrar debatt programvarupatchar?
Bevisen stöder riktningen, men de visar inte att varje team bör använda exakt två granskare och en skribent.
Improving Factuality and Reasoning in Language Models through Multiagent Debate visar att flera modellinstanser kan föreslå, kritisera och förfina svar över flera rundor, vilket förbättrar resultaten i uppsatsens uppgifter för resonemang och faktakorrekthet. Experimenten testade inte Git-konflikter eller produktionsbaserade pull requests.
Ett närmare kodningsexempel publicerades i förtrycket från 2025, SWE-Debate. Dess agenter debatterar konkurrerande spår för fellokalisering, sammanställer en åtgärdsplan och lämnar över planen till en separat agent för patchgenerering. Uppsatsen rapporterar 207 lösta uppgifter av 500 på SWE-bench Verified, eller 41,4 %, jämfört med 38,8 % för de starkaste angivna baslinjerna. Benchmarken och arkitekturen skiljer sig från arbetsflödet jag föreslår, men separationen är talande: först mångsidig analys, därefter ett enda ändringssteg.
Det ärliga nästa steget är en liten kontrollerad utvärdering på verkliga pull requests. Jämför en enda kodningsagent med arbetsflödet med tre sessioner över 10 till 20 buggar. Mät giltiga fynd, falska positiva, merge-konflikter, tid till en godtagbar patch och regressioner som upptäcks efter det första utkastet. Fler agentmeddelanden är inget framgångsmått.
Hur producerar skribenten en enda granskningsbar patch?
Integratören bör följa en snäv loop:
Den sista granskningen bör inspektera patchen, inte starta om designdebatten. Varje granskare besvarar två frågor: implementerade skribenten det accepterade beslutet, och introducerade patchen en ny risk?
OpenAI:s nuvarande Codex-app använder redan separata trådar och worktrees så att agenter kan köras parallellt utan att röra samma lokala Git-tillstånd, och den låter utvecklare inspektera och kommentera varje diff. Tillkännagivandet av Codex-appen visar att isoleringslagret finns. En gemensam fyndlogg och en uttrycklig integratörsroll skulle omvandla parallella uppgifter till ett samordnat granskningsrum.
Vilka fel kvarstår?
En skribent tar bort redigeringsrace, inte modellfel.
Två granskare kan dela samma blinda fläck, särskilt när de använder samma modell, prompt och kontext. Integratören kan välja det mer övertygande argumentet i stället för det korrekta. Kommentarer i repositoryt kan innehålla opålitliga instruktioner. En godkänd testsvit kan missa det beteende som användarna är beroende av.
Arbetsflödet behöver skyddsräcken:
Min tidigare slutsats efter 21,54 miljarder tokens från kodagentaktivitet→ gäller fortfarande: systemet runt modellen avgör om mer intelligens blir användbart arbete eller snabbare städning.
När är ett arbetsflöde med tre sessioner värt det?
Använd det när en felaktig patch är dyr eller när koden har mer än en rimlig tolkning: autentisering, behörigheter, betalningar, migreringar, samtidighet, offentliga API:er och incidentfixar. Det kan också hjälpa när en senior ingenjör normalt skulle be två specialister att granska olika riskområden.
Hoppa över det för formatering, genererade filer, enkla namnbyten och ändringar med ett uppenbart testorakel. Anthropics team för flera agenter fann att samordningskomplexiteten växer snabbt, och dess produktionsbaserade forskningssystem är beroende av tydlig delegering och en ledande agent som sammanställer specialiserade resultat. Kodning behöver samma disciplin, med ännu mindre tolerans för tvetydiga skrivningar.
Jag vill att kodningsagenter ska debattera bevis innan någon av dem får markören. Två sessioner bör inspektera samma fil, vara oense öppet och lämna ett enda beslutsunderlag. En tredje bör skriva kandidatpatchen och bevisa den mot repositoryt.
Den kandidaten behöver fortfarande tester, diffgranskning och ett mänskligt releasebeslut. Tre AI-sessioner kan förbättra vägen till patchen; de gör inte patchen till sanning.
Vanliga frågor
Kan två AI-agenter redigera samma fil samtidigt?
De kan, men gemensamma skrivningar skapar inaktuell kontext och motstridiga ändringar. Låt båda agenterna analysera samma revision i skrivskyddat läge, eller isolera experiment i separata worktrees, och ge sedan en integratör exklusiv skrivåtkomst till den slutliga grenen.
Bör båda granskarna använda samma modell?
Det kan de, men olika prompts, roller eller modellsfamiljer kan minska korrelerade blinda fläckar. Mångfald garanterar inte korrekthet, så arbetsflödet kräver fortfarande bevis och tester.
Vad händer när granskarna inte är överens?
Dokumentera båda ståndpunkterna i fyndloggen. Integratören bör återskapa påståendet, köra det föreslagna testet eller markera frågan som olöst för en människa. Majoritetsröstning är en svag ersättning för verifierbara bevis.
Ersätter den tredje AI-sessionen mänsklig kodgranskning?
Nej. Den tredje sessionen äger syntesen och den föreslagna skrivningen. En människa avgör fortfarande om patchen passar det större systemet, produktens avsikt och release-risken.
Kan detta arbetsflöde hantera ändringar över flera filer?
Ja. Lås varje granskad fil till samma repositoryrevision, tilldela tydligt ägarskap och behåll en enda integrationsgren. Granskarna kan arbeta över isolerade worktrees, medan integratören förblir den enda sessionen som sätter samman den slutliga patchen.