Codex og multi-agent workflow: Arbejd med agenter uden at miste kontrollen
· 6 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
Første gang en kodningsagent rent faktisk retter en fejl for dig, er reaktionen næsten altid den samme: en blanding af entusiasme og mistænksomhed. Fint, selvfølgelig. Men så kigger du på forskellen og spørger dig selv: "Ok, men hvad rørte han egentlig ved? Kan jeg stole på ham? Vil han gøre det igen på samme måde i morgen?".
Det er der, jeg synes, den interessante del begynder. Ikke når agenten skriver en funktion, men når den bliver i stand til at påtage sig hele stykker arbejde: læs arkivet, opret en patch, kør test, åbn en PR, kom tilbage efter en anmeldelseskommentar. Codex bevæger sig netop i den retning: baggrundsarbejde, separate arbejdstræer, integreret browser, automatiseringer, plugins, hukommelse og mere eksplicitte tilladelseskontroller.
Pointen er ikke at forestille sig en fremtid, hvor ingen læser kode længere. Det ville være en frygtelig fremtid, såvel som ganske naivt. Pointen er at finde ud af, hvordan man arbejder med agenter, der kan meget uden at lade dem gøre alt.
Ændringen af vane
Med den traditionelle autofuldførelse var du altid ved rattet. AI’en foreslog en linje, du besluttede. Med en agent ændrer forholdet sig imidlertid: du giver ham et mål, og han gennemgår flere trin på egen hånd.
Dette er stærkt, men det flytter problemet. Spørgsmålet er ikke længere bare "kan modellen programmere?". Spørgsmålet bliver:
- Gav jeg ham et lille nok omfang?
- ved du hvordan man tjekker resultatet?
- Arbejder jeg i et isoleret miljø?
- Er den endelige anmeldelse stadig human og forsigtig?
En sund arbejdsgang ser mere sådan ud end en tryllestav:
Det lyder mindre romantisk end "agenten bygger alt", men det fungerer meget bedre. Og det er også, hvordan teams, der er gode med mennesker, fungerer: klare opgaver, hurtig feedback, eksplicit ansvarlighed.
Den gode prompt er næsten en god billet
Den farligste prompt er den vage, men selvsikre: "Ret fakturasiden", "forbedre arkitekturen", "ryd op i godkendelsesmodulet". Det er anmodninger, der lyder produktive og genererer enorme forskelle. Men så finder du dig selv i at lave arkæologi.
En nyttig prompt er mere kedelig. For eksempel: implementer CSV-eksport for fakturasiden, vel vidende at tabellen er i app/(dashboard)/invoices/page.tsx, forespørgslerne er i src/server/invoices.ts og der allerede er et lignende mønster i app/(dashboard)/reports.
Tilføj derefter klare begrænsninger: skift ikke databaseskemaet, tilføj ikke afhængigheder, hvis et lille hjælpeprogram er nok, behold den eksisterende UI-stil. Og afslut med bekræftelsen: npm test -- invoices og npm run build.
Denne type brief er ikke at "forklare bedre til AI". Det tjener frem for alt til at gøre det tydeligere for dig, hvad du uddelegerer. Kan du ikke skrive det konkret ned, er opgaven måske ikke klar til en agent endnu.
Tre jobs, som jeg gerne uddelegerer
Den første er gentaget, men verificerbart arbejde: tilføjelse af tests, migrering af opkald til en ny intern API, opdatering af importer, udskiftning af forældede komponenter, rettelse af TypeScript-fejl. Her kan agenten spare timer, og risikoen er kontrollerbar.
Det andet er undersøgende arbejde: "find, hvor denne total er beregnet", "forklar mig, hvorfor denne test er skrøbelig", "gengiv fejlen og fortæl mig, hvilke filer der ser ud til at være påvirket". Selv når det ikke producerer en patch med det samme, kan det gøre nyttig rekognoscering.
Den tredje er tilbagevendende vedligeholdelsesarbejde: små afhængighedsopdateringer, oprydning af gamle funktionsflag, oversigt over blokerede PR'er, kontrol af glemte TODO'er. Det er ikke glamourøst, men det er præcis den slags arbejde, der har en tendens til at hobe sig op.
Tre jobs, som jeg holder menneskeligt
Produktbeslutninger forbliver menneskelige. Hvis en ændring ændrer, hvordan en bruger betaler, sletter data, ser priser eller forstår en tilladelse, ønsker jeg en ansvarlig person.
Sikkerhedsgrænser fortjener også menneskelig opmærksomhed: godkendelse, roller, tokens, logning af følsomme data, databasemigreringer. En agent kan hjælpe med at implementere, men behøver ikke at være den eneste beslutningstager.
Endelig beholder jeg alt, hvad der kræver arkitektonisk smag menneskelig. En agent kan foreslå en refactor, men at forstå, om en abstraktion virkelig er nødvendig, eller om vi bare polerer et ikke-eksisterende problem, forbliver et job.
Anmeldelsen er ikke valgfri
Fristelsen, når en agent er god, er at stole på det grønne i CI. Det er forståeligt. Det er også, når problemerne begynder.
Jeg ser altid på mindst fem ting:
- Løser patchen kun den ønskede opgave?
- Rørte han ved filer, der ikke havde noget med det at gøre?
- Dækker testene ny adfærd eller bare en lykkelig chance?
- Følger koden lokale mønstre?
- Håndteres fejl som i resten af projektet?
Når noget er galt, skal feedback være specifik. "Fix it" er doven. Bedre: dette værktøj dublerer parseMoney til src/lib/money.ts; genbrug den funktion, tilføj en test for EUR-sagen og ændr ikke den offentlige API i faktureringsmodulet.
Agenter reagerer meget bedre på små, kontrollerbare kommentarer. Mærkeligt nok gør folket det også.
Autoværn besværet værd
Hvis en agent kan læse filer, skrive kode og udføre kommandoer, skal det behandles som en kraftfuld proces. Der er ikke behov for paranoia, du har brug for hygiejne.
Brug separate arbejdstræer eller grene. Så du kan sammenligne forskellen, smide mislykkede eksperimenter væk og ikke blande agentens arbejde med det, du lavede.
Begræns tilladelser. Kommandoer som rg, git diff, npm test og npm run build kan være ganske gratis. Implementeringer, databasemigreringer, adgang til hemmeligheder og destruktive kommandoer skal forblive eksplicitte.
Reducer netværksadgang, når du ikke har brug for det. Til mange opgaver er officiel dokumentation, pakkeregistrering og specifikke interne tjenester tilstrækkelige. Mindre overfladeareal, færre overraskelser.
Spor handlinger. Når en patch ankommer til revision, bør du være i stand til at rekonstruere prompter, udførte kommandoer, beståede tests og filer ændret. Ikke for at skabe bureaukrati, men for at kunne forstå, hvad der skete, hvis noget går galt.
En nem måde at komme i gang som et team
Hvis jeg skulle introducere agenter i et lille team, ville jeg starte uden større revolutioner.
Jeg ville oprette en agent-ready-etiket til problemer med klart omfang. Jeg ville tilføje en skabelon med kontekst, begrænsninger og verifikationskommandoer. Jeg vil bede om lille PR, ideelt set under et par hundrede linjer. Jeg ville kræve test eller skærmbilleder for synlige ændringer. Og frem for alt ville jeg holde en person ansvarlig for fusionen.
Efter to uger ville jeg se på dataene: Hvilke opgaver blev virkelig fremskyndet, hvilke anmeldelser var tunge, hvilke prompter der var forvirrende, hvilke dele af kodebasen er for skrøbelige til at uddelegere.
Det er en mindre spektakulær tilgang end "fra i dag gør vi alt med agenterne", men det er den, der giver dig mulighed for at komme til den tredje uge uden fortrydelser.
Den mest menneskelige del
Det sjove er, at jo mere autonome agenter bliver, jo vigtigere bliver de klassiske færdigheder igen: at skrive en god billet, lave små klip, lave test, læse forskelle, kommunikere afvejninger. Agenten accelererer dem, der allerede ved, hvordan man arbejder godt. Det forstærker også kaosset blandt dem, der uddelegerer dårligt.
Så nej, jeg ser ikke multi-agent arbejdsgange som en genvej til at stoppe med at lave engineering. Jeg ser dem som en måde at flytte mere energi til de dele, der betyder noget: beslutte, hvad der skal bygges, sikre, at det fungerer, holde systemet forståeligt.
Agenter kan være gode asynkrone kolleger. Men en asynkron kollega, for at være nyttig, har brug for kontekst, grænser og gennemgang. Ligesom alle andre.