Codex och multi-agent arbetsflöde: arbeta med agenter utan att tappa kontrollen

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

1 
2Första gången en kodningsagent faktiskt fixar en bugg åt dig är reaktionen nästan alltid densamma: en blandning av entusiasm och misstänksamhet. Fint, visst. Men så tittar du på diffen och frågar dig själv: "Ok, men exakt vad rörde han? Kan jag lita på honom? Kommer han att göra det igen på samma sätt imorgon?".
3 
4Det är där jag tror att den intressanta delen börjar. Inte när agenten skriver en funktion, utan när den blir kapabel nog att ta på sig hela arbeten: läs förvaret, skapa en patch, kör tester, öppna en PR, kom tillbaka efter en recensionskommentar. Codex rör sig exakt i den riktningen: bakgrundsarbete, separata arbetsträd, integrerad webbläsare, automatiseringar, plugins, minne och mer explicita behörighetskontroller.
5 
6Poängen är inte att föreställa sig en framtid där ingen läser kod längre. Det skulle vara en fruktansvärd framtid, liksom ganska naiv. Poängen är att ta reda på hur man arbetar med agenter som kan göra mycket utan att låta dem göra allt.
7 
8## Förändringen av vana
9 
10Med den traditionella autokompletteringen satt du alltid vid ratten. AI:n föreslog en linje, du bestämde dig. Med en agent förändras dock förhållandet: du ger honom ett mål och han går igenom flera steg på egen hand.
11 
12Detta är kraftfullt, men det flyttar problemet. Frågan är inte längre bara "kan modellen programmera?". Frågan blir:
13 
14- Gav jag honom tillräckligt lite omfattning?
15- vet du hur man kollar resultatet?
16- Arbetar jag i en isolerad miljö?
17- Är den slutliga granskningen fortfarande human och försiktig?
18 
19Ett hälsosamt arbetsflöde ser mer ut så här än en trollstav:
20 
21```mermaid
22flowchart LR
23    Idea[Mänsklig uppgift] --> Scope[Litet, verifierbart syfte]
24    Scope --> Agent[Agent i isolerat arbetsträd]
25    Agent --> Checks[Testa, lint, bygg, webbläsare]
26    Checks --> Review[Mänsklig recension]
27    Review --> Merge[Sammanfoga eller ny iteration]
28    Review --> Iterate[Exakta kommentarer om diff]
29    Iterate --> Agent
30```
31 
32Det låter mindre romantiskt än att "agenten bygger allt", men det fungerar mycket bättre. Och det är också hur team som är bra med människor fungerar: tydliga uppgifter, snabb feedback, tydlig ansvarsskyldighet.
33 
34## Den goda uppmaningen är nästan en bra biljett
35 
36Den farligaste uppmaningen är den vaga men självsäkra: "fixa fakturasidan", "förbättra arkitekturen", "städa upp i autentiseringsmodulen". Det här är förfrågningar som låter produktiva och genererar enorma skillnader. Men sedan kommer du på dig själv med arkeologi.
37 
38En hjälpsam uppmaning är tråkigare. Till exempel: implementera CSV-export för fakturasidan, med vetskap om att tabellen är i `app/(dashboard)/invoices/page.tsx`, frågorna är i `src/server/invoices.ts` och att det redan finns ett liknande mönster i `app/(dashboard)/reports`.
39 
40Lägg sedan till tydliga begränsningar: ändra inte databasschemat, lägg inte till beroenden om ett litet verktyg räcker, behåll den befintliga UI-stilen. Och avsluta med verifieringen: `npm test -- invoices` och `npm run build`.
41 
42Denna typ av brief är inte att "förklara bättre för AI". Det tjänar framför allt till att göra det tydligare för dig vad du delegerar. Om du inte kan skriva ner det konkret kanske uppgiften inte är redo för en agent än.
43 
44## Tre jobb som jag gärna delegerar
45 
46Den första är repetitivt men verifierbart arbete: lägga till tester, migrera anrop till ett nytt internt API, uppdatera importer, ersätta föråldrade komponenter, fixa TypeScript-fel. Här kan agenten spara timmar och risken är kontrollerbar.
47 
48Det andra är utforskande arbete: "hitta var denna summa beräknas", "förklara för mig varför det här testet är ömtåligt", "reproducera buggen och berätta för mig vilka filer som verkar påverkas". Även när den inte producerar en lapp direkt, kan den göra användbar spaning.
49 
50Det tredje är återkommande underhållsarbete: små beroendeuppdateringar, rensning av gamla funktionsflaggor, sammanfattning av blockerade PR, kontroll av glömda TODOs. Det är inte glamoröst, men det är precis den sortens arbete som tenderar att hopa sig.
51 
52## Tre jobb som jag behåller mänskliga
53 
54Produktbeslut förblir mänskliga. Om en ändring ändrar hur en användare betalar, raderar data, ser priser eller förstår ett tillstånd, vill jag ha en ansvarig person.
55 
56Säkerhetsgränser förtjänar också mänsklig uppmärksamhet: auth, roller, tokens, känslig dataloggning, databasmigreringar. En agent kan hjälpa till att implementera, men behöver inte vara den enda beslutsfattaren.
57 
58Till sist behåller jag allt som kräver arkitektonisk smak mänskligt. En agent kan föreslå en refactor, men att förstå om en abstraktion verkligen är nödvändig eller om vi bara polerar ett obefintligt problem förblir ett jobb.
59 
60## Granskningen är inte frivillig
61 
62Frestelsen, när en agent är bra, är att lita på CI:s gröna. Det är förståeligt. Det är också då problemen börjar.
63 
64Jag tittar alltid på minst fem saker:
65 
661. Löser patchen bara den begärda uppgiften?
672. Rörde han filer som inte hade något med det att göra?
683. Täcker testerna nytt beteende eller bara lycklig chans?
694. Följer koden lokala mönster?
705. Hanteras fel som i resten av projektet?
71 
72När något är fel måste feedbacken vara specifik. "Fix it" är lat. Bättre: det här verktyget duplicerar `parseMoney` till `src/lib/money.ts`; återanvänd den funktionen, lägg till ett test för EUR-fallet och ändra inte det offentliga API:et för faktureringsmodulen.
73 
74Agenter svarar mycket bättre på små, verifierbara kommentarer. Märkligt nog, det gör folket också.
75 
76## Skyddsräcken värt ansträngningen
77 
78Om en agent kan läsa filer, skriva kod och utföra kommandon, bör det behandlas som en kraftfull process. Det finns inget behov av paranoia, du behöver hygien.
79 
80Använd separata arbetsträd eller grenar. Så du kan jämföra skillnaden, slänga misslyckade experiment och inte blanda agentens arbete med det du höll på med.
81 
82Begränsa behörigheter. Kommandon som `rg`, `git diff`, `npm test` och `npm run build` kan vara ganska gratis. Driftsättningar, databasmigreringar, åtkomst till hemligheter och destruktiva kommandon måste förbli tydliga.
83 
84Minska nätverksåtkomsten när du inte behöver det. För många uppgifter räcker det med officiell dokumentation, paketregister och specifika interna tjänster. Mindre yta, färre överraskningar.
85 
86Spåra åtgärder. När en patch kommer till granskning bör du kunna rekonstruera uppmaningar, körda kommandon, godkända tester och filer modifierade. Inte för att skapa byråkrati, utan för att kunna förstå vad som hände om något går fel.
87 
88## Ett enkelt sätt att komma igång som ett team
89 
90Om jag skulle introducera agenter i ett litet team skulle jag börja utan större revolutioner.
91 
92Jag skulle skapa en `agent-ready`-etikett för problem med tydlig räckvidd. Jag skulle lägga till en mall med sammanhang, begränsningar och verifieringskommandon. Jag skulle be om liten PR, helst under några hundra rader. Jag skulle kräva testning eller skärmdumpar för synliga ändringar. Och framför allt skulle jag hålla en person ansvarig för sammanslagningen.
93 
94Efter två veckor skulle jag titta på data: vilka uppgifter som verkligen snabbades upp, vilka recensioner var tunga, vilka uppmaningar som var förvirrande, vilka delar av kodbasen som är för ömtåliga för att delegera.
95 
96Det är ett mindre spektakulärt tillvägagångssätt än "från och med idag ska vi göra allt med agenterna", men det är den som gör att du kan ta dig till den tredje veckan utan ånger.
97 
98## Den mest mänskliga delen
99 
100Det roliga är att ju mer autonoma agenter blir, desto viktigare blir de klassiska färdigheterna igen: skriva en bra biljett, göra små klipp, skapa tester, läsa avvikelser, kommunicera avvägningar. Agenten accelererar de som redan vet hur man arbetar bra. Det förstärker också kaoset för dem som delegerar dåligt.
101 
102Så nej, jag ser inte arbetsflöden med flera agenter som en genväg för att sluta göra ingenjörsarbete. Jag ser dem som ett sätt att flytta mer energi till de delar som betyder något: att bestämma vad som ska byggas, se till att det fungerar, hålla systemet begripligt.
103 
104Agenter kan bli fantastiska asynkrona kollegor. Men en asynkron kollega, för att vara användbar, behöver sammanhang, gränser och granskning. Precis som alla andra.
105 
106## Användbara källor
107 
108- [Codex för (nästan) allt - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Kör Codex säkert på OpenAI](https://openai.com/index/running-codex-safely/)
110- [Vi presenterar Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [Vad är nytt med GitHub Copilot-kodningsagent](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112

:Codex och multi-agent arbetsflöde: arbeta med agenter utan att tappa kontrollenlines 1-112 (END) — press q to close

2Första gången en kodningsagent faktiskt fixar en bugg åt dig är reaktionen nästan alltid densamma: en blandning av entusiasm och misstänksamhet. Fint, visst. Men så tittar du på diffen och frågar dig själv: "Ok, men exakt vad rörde han? Kan jag lita på honom? Kommer han att göra det igen på samma sätt imorgon?".

4Det är där jag tror att den intressanta delen börjar. Inte när agenten skriver en funktion, utan när den blir kapabel nog att ta på sig hela arbeten: läs förvaret, skapa en patch, kör tester, öppna en PR, kom tillbaka efter en recensionskommentar. Codex rör sig exakt i den riktningen: bakgrundsarbete, separata arbetsträd, integrerad webbläsare, automatiseringar, plugins, minne och mer explicita behörighetskontroller.

6Poängen är inte att föreställa sig en framtid där ingen läser kod längre. Det skulle vara en fruktansvärd framtid, liksom ganska naiv. Poängen är att ta reda på hur man arbetar med agenter som kan göra mycket utan att låta dem göra allt.

8## Förändringen av vana

10Med den traditionella autokompletteringen satt du alltid vid ratten. AI:n föreslog en linje, du bestämde dig. Med en agent förändras dock förhållandet: du ger honom ett mål och han går igenom flera steg på egen hand.

12Detta är kraftfullt, men det flyttar problemet. Frågan är inte längre bara "kan modellen programmera?". Frågan blir:

14- Gav jag honom tillräckligt lite omfattning?

15- vet du hur man kollar resultatet?

16- Arbetar jag i en isolerad miljö?

17- Är den slutliga granskningen fortfarande human och försiktig?

19Ett hälsosamt arbetsflöde ser mer ut så här än en trollstav:

21```mermaid

22flowchart LR

23 Idea[Mänsklig uppgift] --> Scope[Litet, verifierbart syfte]

24 Scope --> Agent[Agent i isolerat arbetsträd]

25 Agent --> Checks[Testa, lint, bygg, webbläsare]

26 Checks --> Review[Mänsklig recension]

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

28 Review --> Iterate[Exakta kommentarer om diff]

29 Iterate --> Agent

30```

32Det låter mindre romantiskt än att "agenten bygger allt", men det fungerar mycket bättre. Och det är också hur team som är bra med människor fungerar: tydliga uppgifter, snabb feedback, tydlig ansvarsskyldighet.

34## Den goda uppmaningen är nästan en bra biljett

36Den farligaste uppmaningen är den vaga men självsäkra: "fixa fakturasidan", "förbättra arkitekturen", "städa upp i autentiseringsmodulen". Det här är förfrågningar som låter produktiva och genererar enorma skillnader. Men sedan kommer du på dig själv med arkeologi.

38En hjälpsam uppmaning är tråkigare. Till exempel: implementera CSV-export för fakturasidan, med vetskap om att tabellen är i `app/(dashboard)/invoices/page.tsx`, frågorna är i `src/server/invoices.ts` och att det redan finns ett liknande mönster i `app/(dashboard)/reports`.

40Lägg sedan till tydliga begränsningar: ändra inte databasschemat, lägg inte till beroenden om ett litet verktyg räcker, behåll den befintliga UI-stilen. Och avsluta med verifieringen: `npm test -- invoices` och `npm run build`.

42Denna typ av brief är inte att "förklara bättre för AI". Det tjänar framför allt till att göra det tydligare för dig vad du delegerar. Om du inte kan skriva ner det konkret kanske uppgiften inte är redo för en agent än.

44## Tre jobb som jag gärna delegerar

46Den första är repetitivt men verifierbart arbete: lägga till tester, migrera anrop till ett nytt internt API, uppdatera importer, ersätta föråldrade komponenter, fixa TypeScript-fel. Här kan agenten spara timmar och risken är kontrollerbar.

48Det andra är utforskande arbete: "hitta var denna summa beräknas", "förklara för mig varför det här testet är ömtåligt", "reproducera buggen och berätta för mig vilka filer som verkar påverkas". Även när den inte producerar en lapp direkt, kan den göra användbar spaning.

50Det tredje är återkommande underhållsarbete: små beroendeuppdateringar, rensning av gamla funktionsflaggor, sammanfattning av blockerade PR, kontroll av glömda TODOs. Det är inte glamoröst, men det är precis den sortens arbete som tenderar att hopa sig.

52## Tre jobb som jag behåller mänskliga

54Produktbeslut förblir mänskliga. Om en ändring ändrar hur en användare betalar, raderar data, ser priser eller förstår ett tillstånd, vill jag ha en ansvarig person.

56Säkerhetsgränser förtjänar också mänsklig uppmärksamhet: auth, roller, tokens, känslig dataloggning, databasmigreringar. En agent kan hjälpa till att implementera, men behöver inte vara den enda beslutsfattaren.

58Till sist behåller jag allt som kräver arkitektonisk smak mänskligt. En agent kan föreslå en refactor, men att förstå om en abstraktion verkligen är nödvändig eller om vi bara polerar ett obefintligt problem förblir ett jobb.

60## Granskningen är inte frivillig

62Frestelsen, när en agent är bra, är att lita på CI:s gröna. Det är förståeligt. Det är också då problemen börjar.

64Jag tittar alltid på minst fem saker:

661. Löser patchen bara den begärda uppgiften?

672. Rörde han filer som inte hade något med det att göra?

683. Täcker testerna nytt beteende eller bara lycklig chans?

694. Följer koden lokala mönster?

705. Hanteras fel som i resten av projektet?

72När något är fel måste feedbacken vara specifik. "Fix it" är lat. Bättre: det här verktyget duplicerar `parseMoney` till `src/lib/money.ts`; återanvänd den funktionen, lägg till ett test för EUR-fallet och ändra inte det offentliga API:et för faktureringsmodulen.

74Agenter svarar mycket bättre på små, verifierbara kommentarer. Märkligt nog, det gör folket också.

76## Skyddsräcken värt ansträngningen

78Om en agent kan läsa filer, skriva kod och utföra kommandon, bör det behandlas som en kraftfull process. Det finns inget behov av paranoia, du behöver hygien.

80Använd separata arbetsträd eller grenar. Så du kan jämföra skillnaden, slänga misslyckade experiment och inte blanda agentens arbete med det du höll på med.

82Begränsa behörigheter. Kommandon som `rg`, `git diff`, `npm test` och `npm run build` kan vara ganska gratis. Driftsättningar, databasmigreringar, åtkomst till hemligheter och destruktiva kommandon måste förbli tydliga.

84Minska nätverksåtkomsten när du inte behöver det. För många uppgifter räcker det med officiell dokumentation, paketregister och specifika interna tjänster. Mindre yta, färre överraskningar.

86Spåra åtgärder. När en patch kommer till granskning bör du kunna rekonstruera uppmaningar, körda kommandon, godkända tester och filer modifierade. Inte för att skapa byråkrati, utan för att kunna förstå vad som hände om något går fel.

88## Ett enkelt sätt att komma igång som ett team

90Om jag skulle introducera agenter i ett litet team skulle jag börja utan större revolutioner.

92Jag skulle skapa en `agent-ready`-etikett för problem med tydlig räckvidd. Jag skulle lägga till en mall med sammanhang, begränsningar och verifieringskommandon. Jag skulle be om liten PR, helst under några hundra rader. Jag skulle kräva testning eller skärmdumpar för synliga ändringar. Och framför allt skulle jag hålla en person ansvarig för sammanslagningen.

94Efter två veckor skulle jag titta på data: vilka uppgifter som verkligen snabbades upp, vilka recensioner var tunga, vilka uppmaningar som var förvirrande, vilka delar av kodbasen som är för ömtåliga för att delegera.

96Det är ett mindre spektakulärt tillvägagångssätt än "från och med idag ska vi göra allt med agenterna", men det är den som gör att du kan ta dig till den tredje veckan utan ånger.

98## Den mest mänskliga delen

100Det roliga är att ju mer autonoma agenter blir, desto viktigare blir de klassiska färdigheterna igen: skriva en bra biljett, göra små klipp, skapa tester, läsa avvikelser, kommunicera avvägningar. Agenten accelererar de som redan vet hur man arbetar bra. Det förstärker också kaoset för dem som delegerar dåligt.

101

102Så nej, jag ser inte arbetsflöden med flera agenter som en genväg för att sluta göra ingenjörsarbete. Jag ser dem som ett sätt att flytta mer energi till de delar som betyder något: att bestämma vad som ska byggas, se till att det fungerar, hålla systemet begripligt.

103

104Agenter kan bli fantastiska asynkrona kollegor. Men en asynkron kollega, för att vara användbar, behöver sammanhang, gränser och granskning. Precis som alla andra.

105

106## Användbara källor

107

108- [Codex för (nästan) allt - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Kör Codex säkert på OpenAI](https://openai.com/index/running-codex-safely/)

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

111- [Vad är nytt med GitHub Copilot-kodningsagent](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112