Codex og multi-agent workflow: Arbejd med agenter uden at miste kontrollen

spinny:~/writing $ less codex-multi-agent-workflows.md

1 
2Fø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?".
3 
4Det 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.
5 
6Pointen 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.
7 
8## Ændringen af vane
9 
10Med 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.
11 
12Dette er stærkt, men det flytter problemet. Spørgsmålet er ikke længere bare "kan modellen programmere?". Spørgsmålet bliver:
13 
14- Gav jeg ham et lille nok omfang?
15- ved du hvordan man tjekker resultatet?
16- Arbejder jeg i et isoleret miljø?
17- Er den endelige anmeldelse stadig human og forsigtig?
18 
19En sund arbejdsgang ser mere sådan ud end en tryllestav:
20 
21```mermaid
22flowchart LR
23    Idea[Menneskelig opgave] --> Scope[Lille, verificerbart formål]
24    Scope --> Agent[Agent i arbejdstræ isoleret]
25    Agent --> Checks[Test, lint, build, browser]
26    Checks --> Review[Menneskelig gennemgang]
27    Review --> Merge[Flet eller ny iteration]
28    Review --> Iterate[Præcise kommentarer til diff]
29    Iterate --> Agent
30```
31 
32Det 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.
33 
34## Den gode prompt er næsten en god billet
35 
36Den 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.
37 
38En 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`.
39 
40Tilfø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`.
41 
42Denne 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.
43 
44## Tre jobs, som jeg gerne uddelegerer
45 
46Den 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.
47 
48Det 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.
49 
50Den 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.
51 
52## Tre jobs, som jeg holder menneskeligt
53 
54Produktbeslutninger forbliver menneskelige. Hvis en ændring ændrer, hvordan en bruger betaler, sletter data, ser priser eller forstår en tilladelse, ønsker jeg en ansvarlig person.
55 
56Sikkerhedsgræ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.
57 
58Endelig 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.
59 
60## Anmeldelsen er ikke valgfri
61 
62Fristelsen, 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.
63 
64Jeg ser altid på mindst fem ting:
65 
661. Løser patchen kun den ønskede opgave?
672. Rørte han ved filer, der ikke havde noget med det at gøre?
683. Dækker testene ny adfærd eller bare en lykkelig chance?
694. Følger koden lokale mønstre?
705. Håndteres fejl som i resten af projektet?
71 
72Nå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.
73 
74Agenter reagerer meget bedre på små, kontrollerbare kommentarer. Mærkeligt nok gør folket det også.
75 
76## Autoværn besværet værd
77 
78Hvis 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.
79 
80Brug separate arbejdstræer eller grene. Så du kan sammenligne forskellen, smide mislykkede eksperimenter væk og ikke blande agentens arbejde med det, du lavede.
81 
82Begræ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.
83 
84Reducer 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.
85 
86Spor 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.
87 
88## En nem måde at komme i gang som et team
89 
90Hvis jeg skulle introducere agenter i et lille team, ville jeg starte uden større revolutioner.
91 
92Jeg 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.
93 
94Efter 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.
95 
96Det 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.
97 
98## Den mest menneskelige del
99 
100Det 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.
101 
102Så 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.
103 
104Agenter 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.
105 
106## Nyttige kilder
107 
108- [Codex for (næsten) alt - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Kører Codex sikkert på OpenAI](https://openai.com/index/running-codex-safely/)
110- [Introduktion til Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [Hvad er nyt med GitHub Copilot-kodningsagent](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112

:Codex og multi-agent workflow: Arbejd med agenter uden at miste kontrollenlines 1-112 (END) — press q to close

2Fø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?".

4Det 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.

6Pointen 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.

8## Ændringen af vane

10Med 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.

12Dette er stærkt, men det flytter problemet. Spørgsmålet er ikke længere bare "kan modellen programmere?". Spørgsmålet bliver:

14- Gav jeg ham et lille nok omfang?

15- ved du hvordan man tjekker resultatet?

16- Arbejder jeg i et isoleret miljø?

17- Er den endelige anmeldelse stadig human og forsigtig?

19En sund arbejdsgang ser mere sådan ud end en tryllestav:

21```mermaid

22flowchart LR

23 Idea[Menneskelig opgave] --> Scope[Lille, verificerbart formål]

24 Scope --> Agent[Agent i arbejdstræ isoleret]

25 Agent --> Checks[Test, lint, build, browser]

26 Checks --> Review[Menneskelig gennemgang]

27 Review --> Merge[Flet eller ny iteration]

28 Review --> Iterate[Præcise kommentarer til diff]

29 Iterate --> Agent

30```

32Det 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.

34## Den gode prompt er næsten en god billet

36Den 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.

38En 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`.

40Tilfø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`.

42Denne 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.

44## Tre jobs, som jeg gerne uddelegerer

46Den 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.

48Det 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.

50Den 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.

52## Tre jobs, som jeg holder menneskeligt

54Produktbeslutninger forbliver menneskelige. Hvis en ændring ændrer, hvordan en bruger betaler, sletter data, ser priser eller forstår en tilladelse, ønsker jeg en ansvarlig person.

56Sikkerhedsgræ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.

58Endelig 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.

60## Anmeldelsen er ikke valgfri

62Fristelsen, 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.

64Jeg ser altid på mindst fem ting:

661. Løser patchen kun den ønskede opgave?

672. Rørte han ved filer, der ikke havde noget med det at gøre?

683. Dækker testene ny adfærd eller bare en lykkelig chance?

694. Følger koden lokale mønstre?

705. Håndteres fejl som i resten af projektet?

72Nå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.

74Agenter reagerer meget bedre på små, kontrollerbare kommentarer. Mærkeligt nok gør folket det også.

76## Autoværn besværet værd

78Hvis 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.

80Brug separate arbejdstræer eller grene. Så du kan sammenligne forskellen, smide mislykkede eksperimenter væk og ikke blande agentens arbejde med det, du lavede.

82Begræ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.

84Reducer 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.

86Spor 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.

88## En nem måde at komme i gang som et team

90Hvis jeg skulle introducere agenter i et lille team, ville jeg starte uden større revolutioner.

92Jeg 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.

94Efter 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.

96Det 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.

98## Den mest menneskelige del

100Det 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.

101

102Så 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.

103

104Agenter 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.

105

106## Nyttige kilder

107

108- [Codex for (næsten) alt - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Kører Codex sikkert på OpenAI](https://openai.com/index/running-codex-safely/)

110- [Introduktion til Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [Hvad er nyt med GitHub Copilot-kodningsagent](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112