Shell Hygiejne — Luksusproblemet med at køre for mange agenter

Jeg kører flere kodeagenter parallelt nu. Som regel Claude Code, nogle gange flere på samme projekt, nogle gange spredt ud over forskellige kundeprojekter. Det er målbart den største produktivitetsforandring jeg har haft i et årti.

Og det har skabt et problem, jeg ikke havde forudset.

For et par uger siden skrev jeg en simpel forespørgsel ind i en shell på mit skrivebord — jeg bad om nogle layout-ændringer og lidt indholdsjustering. Intet dramatisk. Shell’en kørte Claude Code imod det umage.ai-site jeg arbejdede på på det tidspunkt. Troede jeg. Det gjorde den ikke. Den kørte imod et af mine egne hobbyprojekter — et af de “lad-mig-lige-prøve-noget”-repos jeg havde ladet stå åbent et par timer tidligere.

Det næste der skete var stille imponerende. Claude læste forespørgslen, konkluderede at de ord jeg brugte ikke passede på noget i dens working directory, og gik på jagt efter et projekt hvor de gjorde. Den fandt et, uden for sin egen mappe, åbnede det, lavede ændringerne og påpegede derefter høfligt, at jeg havde snakket med den forkerte Claude.

Jeg ville gerne kunne sige, at det var en engangsforeteelse. Det var det ikke. Antallet af shells på mit skrivebord var vokset. Jeg kunne nogenlunde sige, hvad hver enkelt lavede, men ikke altid på et øjeblik. Mere end én gang havde jeg vandret mellem vinduer og bedt én agent om noget, en anden burde have hørt.

Jeg havde bygget mig selv et nyt problem. Og det var ikke et problem, man løser med mere opmærksomhed.

At køre flere agenter er ikke gratis

Når folk taler om produktivitetsgevinsten ved AI-kodeagenter, stopper de som regel ved “én udvikler laver arbejdet for flere.” Det er sandt, men det overser anden-ordens-effekten. Når flaskehalsen ikke længere er selve kodeskriveriet, er det oplagte næste træk at køre flere agenter parallelt — på forskellige opgaver, forskellige branches, helt forskellige projekter.

Det er dér produktivitetskurven bøjer endnu en gang. Og det er dér meta-arbejdet begynder: arbejdet med at vide hvilken agent der laver hvad, hvor den er, og om den venter på én.

Hver ekstra shell er en kontekst, man kan miste.

Hvad jeg egentlig havde brug for

Jeg startede med de sædvanlige tricks. Farvekodede prompts. Navngivningskonventioner i Windows Terminal-faner. En post-it eller to, hvilket føltes som en lille kapitulation.

Intet af det skalerede ud over fire-fem agenter. Ved otte-ni åbnede jeg det forkerte vindue flere gange om dagen. Ved tolv ledte jeg i proceslinjen som en, der leder efter en bortkommen kuglepen.

Det jeg egentlig havde brug for var pinligt indlysende, da jeg først fik skrevet det ned:

• Ét vindue med det hele i, i et layout der passer til skærmen.
• Shells der automatisk bliver navngivet efter det projekt, de kører i, med en farve jeg ikke selv skulle vælge.
• Et signal når en agent ventede på mig, så jeg ikke tabte fem minutter her, tyve der.
• En måde at søge på tværs af alt hvad agenterne havde sagt i løbet af dagen, for jeg havde allerede mistet for mange nyttige afsnit til scrollback.
• Og det hele skulle komme tilbage som jeg forlod det, når jeg åbnede laptoppen igen.

Det er ikke en terminal. Det er noget der minder mere om mission control for agenter.

Så byggede jeg det

I løbet af en aften og et par timer dagen efter byggede jeg CodeShellManager, en desktop-app til Windows der samler vilkårligt mange command-line-værktøjer — Claude Code, PowerShell, SSH-sessioner, hvad man nu har lyst til — i ét organiseret vindue. 26 timer fra idé til lanceret open source-produkt, bygget for en stor del af agenterne selv, hvilket føltes passende.

Den rummer op til atten shells på én gang fordelt på ni grid-layouts og navngiver og farvekoder hver session automatisk efter den projektmappe den kører i, så “hvilken er det her”-problemet stort set holder op med at opstå.

Et fuldtekstsøgeindeks dækker hver eneste linje af terminal-output, så jeg kan finde noget en agent sagde for tre timer siden i en hvilken som helst session. En lille notifikation dukker op når Claude Code holder pause og venter på input eller godkendelse — grøn, orange, pink, alt efter hvad den vil have — så jeg ikke lader agenter stå stille, mens jeg er optaget af en anden.

Sessioner overlever genstart, og hver enkelt viser sin git-branch og dirty-state på et øjeblik.

Ingen af de features er specielt smarte hver for sig. Værdien ligger i at have dem samlet på ét sted.

Når man orkestrerer fem Claudes, er det ikke modellen der er det vigtige værktøj. Det er det, der sørger for, at man ikke kommer til at snakke med den forkerte.

Jeg ved godt hvad indvendingen er

Hvorfor ikke bare bruge [produkt X]? Ærligt talt — det kunne jeg måske have gjort. Windows Terminal, tmux, WezTerm — der er masser af værktøjer i nærheden, og nogle af dem ville have taget mig 80% af vejen.

Men med farten af agentisk udvikling er det nogle gange billigere at bygge et skræddersyet værktøj, der passer præcist, end at acceptere begrænsningerne i noget der næsten gør. Den regning har flyttet sig ganske meget det sidste år. At bygge sit eget værktøj plejede at være ekstravagant. Nu er det ofte en lang weekend.

CodeShellManager er open source og gratis. Brug den som den er, fork den, udvid den, eller — sandsynligvis mest brugbart — tag idéen og byg en version der passer bedre til ens eget workflow.

Pointen er færdigheden, ikke appen

Hvis der skal tages én ting med herfra, så lad det ikke være værktøjet. Lad det være observationen.

At køre agenter parallelt er den oplagte næste produktivitetsmultiplikator, men friktionen flytter sig fra “kan agenten skrive koden” til “kan man holde styr på, hvad atten af dem laver på samme tid.” Det er en færdighed. Kald det shell hygiejne, kald det agent ops, kald det hvad man vil — de fleste af os kommer til at udvikle den, uanset om vi lægger mærke til det eller ej.

Jeg foretrækker at lægge mærke til det.