Ta dig ur flaskhalsen. Behåll hantverket.

Med en kodningsagent är du en pairprogrammerare: den skriver snabbare, du styr. Med flera byter jobbet form. Molnagenter körs i sina egna isolerade miljöer, arbetar på sina egna branches och lämnar tillbaka pull requests — inget av det rör din maskin. [1] Löftet om parallellism är verkligt. Men din genomströmning slutar vara din skrivhastighet. Den blir hur väl du håller en flotta pekandes åt samma håll.

Och flottor misslyckas på ett specifikt sätt. Peka en andra agent mot samma checkout som den första och, inom minuter, redigerar båda samma fil — en skriver över den andra mitt i en ändring, och du får halvapplicerade diffar och en trasig build utan att veta vilken agent som gjorde vad. [2] Kostnaden är inte bara trasig kod. Det är de tokens dina agenter bränner på att upptäcka kollisionen, lösa den och bygga om — en leverantör av verktyg för parallella agenter pekar på API-krediter som slösas bort på merge-konflikter och halvfärdiga ändringar [3] — och det är du, i slutändan, som reder ut diffar du aldrig ville skulle existera.

Lösningen är inte en smartare agent. Det är att behandla koordinering som infrastruktur: explicita uppgiftsgränser, isolerad körning och evidensbaserade sammanslagningar. [2] Får du det rätt tar du dig verkligen bort som flaskhals — agenterna bygger, och du lägger dina timmar på de beslut bara du kan fatta.

De flesta kodningsagenter antar att de äger projektkatalogen — de läser och skriver filer direkt. Sätt två av dem i samma checkout och tre saker går snabbt fel: filkollisioner, där agent A skriver om en fil medan agent B omstrukturerar den och git bara ser den senaste skrivningen; kontextkontaminering, där B läser en fil A håller på att ändra och resonerar om ett tillstånd som aldrig funnits; och byggstörningar, där båda agenterna triggar builds och tester som tävlar om samma utdatakataloger och portar. [4] Inget av det här är sällsynta specialfall. De dyker upp första gången du provar två sessioner mot en och samma repo.

Standardlösningen är git worktrees: en länkad arbetskatalog på sin egen branch som delar samma .git-historik — isolering utan kloning. Kommandot har funnits sedan 2015; vad som förändrats är att det blivit standardsättet att köra fler än en agent mot en och samma kodbas. [2] Varje agent får sin egen katalog och sin egen branch, så den kan inte röra någon annans filer — och konflikter flyttas till sammanslagningstillfället, där vanliga git-verktyg upptäcker dem, istället för att ske tyst medan arbetet pågår. [5]

Worktrees isolerar filer, men inte allt annat. Varje agent behöver också sin egen databas (eller databasgren) och en unik dev-serverport — annars krockar två agenter ändå i datan och på nätverket. [2]

Hur många är för många? De som kör lokala worktrees rapporterar fem till sju agenter på en bärbar dator som det praktiska taket — därefter hinner rate limits, disk och granskningsbörda ikapp. [2] Andra rekommenderar tre till fem, så säg tre till sju, beroende på vem du frågar. [4] Molnagenter tar bort begränsningarna från den bärbara datorn, men inte granskningsbegränsningen.

Isolering stoppar agenter från att trampa på varandras filer. Det stoppar dem inte från att bygga oförenliga saker. Riktiga repon har delade hotspot-filer — routes, konfigurationer, register — och att säga åt agenter att hålla sig till olika filer hjälper mindre än man önskar: en verktygstillverkare noterar att en refaktorering som rör ett modulgränssnitt påverkar varje fil som importerar det, och två agenter som lägger till olika endpoints behöver ofta samma router-fil. [6]

Så andra halvan av lösningen är uppdelning. Tilldela icke-överlappande uppgifter, så att överlapp blir svårt by design istället för undvikt genom tur. [5] Testet är rakt på sak:

"Om två uppgifter har överlappande fillistor behöver de köras sekventiellt, inte parallellt." [7]

I vår erfarenhet är den renaste snittytan efter gräns, inte lager: ge varje agent en feature eller en sömnad, inte en skiva av samma vertikala story. Slå sedan ihop branches en i taget i beroendeordning, kör build och tester efter varje sammanslagning, så att varje del landar i en kodbas nästa agent kan bygga vidare på. [2]

När två delar verkligen är beroende av varandra, kör dem inte parallellt och hoppas på det bästa. Markera den ena som blockerad av den andra i Linear, och låt den andra starta först när den första slagits ihop. Beroendet blir synligt på tavlan istället för att leva i ditt huvud.

Varje del behöver fortfarande samma kontrakt som vilken enagent-story som helst: uppdraget, begränsningarna, vad som är förbjudet och vad klart betyder. En väl avgränsad story är vad som gör två agenters antaganden kompatibla utan ett möte — vi går igenom hur man skriver en i vår guide om stories för kodningsagenter.

Med flera agenter igång kan du inte ögna igenom varje diff — och du ska inte behöva heller. Vårt råd: flytta kvalitetsribban in i automationen. Kräv tester och automatisk verifiering innan något slås ihop, och gör själva sammanslagningen evidensbaserad snarare än hoppfull. Rollfördelningen som uppstår är koordinator, specialister och verifierare — du planerar och bedömer, agenter utför, och kontroller verifierar.

Det här är också vad som håller tokens flödande mot användbart arbete. När acceptanskontrollerna finns i storyn misslyckas en agent som driver iväg med sina egna tester istället för att skicka sin avvikelse till en granskare — eller värre, till en annan agent som bygger vidare på den. När de inte gör det uppstår misslyckandet som en konflikt mellan två självsäkra, trovärdiga, felaktiga pull requests.

Vinsten är var din uppmärksamhet hamnar: granskningstid spenderad på bedömning — är detta rätt beteende, rätt form, rätt namn — istället för konfliktarkeologi och mystiska diffar.

Det finns en tystare kostnad än merge-konflikter, och den landar på människor som har kodat hela sina liv. Agenter äter exakt det arbete som brukade göra dagen tillfredsställande — de små, kompletta vinsterna — och kvar blir att besluta vad som ska byggas, bedöma avvägningar, granska och fånga subtiliteter. [8] En del som levererar funktioner på det här sättet känner ingenting efteråt: arbetet hände nära dem istället för genom dem. [9]

En utvecklare spårade känslan till sina egna val. AI tog inte glädjen, drog han slutsatsen — han gav bort den genom att välja hastighet:

"Jag slutar vara personen som gjorde det och blir personen som godkände det." [11]

En annan beskriver det som en värderingsfråga: vi automatiserar uppgifter vi inte värderar — så var ärlig med om det är resultatet eller förståelsen du vill ha, och när det är förståelsen, gör den den svåra vägen. [10] Det är känslan bakom "jag har blivit en kodgranskningsrobot." Det är ingen naturlag för AI-kodning. Det är vad som händer när arbetsfördelningen avgörs av default istället för av val. Så bestäm — medvetet — vad som förblir ditt:

Det visar sig att kul också är ett designproblem. Låt agenterna ta standardkoden, och stanna själv kvar i de svåra, tillfredsställande problemen. [8] En utvecklare argumenterar för medveten långsamhet och för att välja ambitiösa projekt:

"Nyckeln till att ha kul är att utmana dig själv precis vid gränsen för din förmåga." [9]

Att optimera rent för att leverera snabbt dränerar precis det. Som samma skribent uttrycker det: "Förmågan att tänka igenom komplexa problem bara försvinner." [9]

Det finns en ärlig motinvändning som förtjänar att höras: "Om du kör fem agenter parallellt programmerar du inte längre, du är flygledare." [8] Det stämmer när koordineringen bor i ditt huvud. Det är precis därför koordineringen — vem som kör härnäst, vad som är blockerat, vad som behöver granskas — bör vara verktyg, inte din uppmärksamhet.

Några konkreta grepp som överlever kontakt med en riktig vecka: ta den svåraste delen av en story själv och ge resten till flottan. Behåll en del av systemet som alltid är ditt — platsen där du fortfarande skriver varje rad. Avsluta dagen med en granskning som är arkitektur, inte inspektion: du är den som bestämmer vad koden ska bli härnäst.

Det här är inte nostalgi. Motivation är en produktionsinsats: ingen orkar driva en flotta från ett jobb som känns som att övervaka maskiner. Behåll hantverket, så blir agenterna en hävstång.

Den här guidens råd kokar ner till tre vanor: dela upp arbete så det inte kan krocka, slå ihop en branch i taget i beroendeordning, och låt kontroller — inte dina ögon — vara den första kvalitetsgrinden. Aerunit gör de vanorna till automation för team på Linear och Cursor Cloud Agents.

Det följer Linears blocks / blocked-by-relationer: när en pull request slås ihop hittar Aerunit de issues den PR:en blockerade och köar dem till Cursor Cloud Agents, så att nästa del börjar ovanpå sammanslagen kod. Det är sekventiell sammanslagning, gjord åt dig. När en agent öppnar en PR kör Aerunit en kodgranskning på den och kan skicka tillbaka resultaten till agentsessionen. Och Aerunit läser varje repository en story rör vid innan den skrivs, så arbete över flera repon får en sammanhängande plan och ett underissue per repo. Du bestämmer fortfarande vad som körs; Aerunit hanterar "vad som är härnäst" när en blockerare slås ihop.