Codex- en multi-agentworkflow: werk met agenten zonder de controle te verliezen

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

1~
2De eerste keer dat een codeeragent daadwerkelijk een bug voor je oplost, is de reactie bijna altijd hetzelfde: een mengeling van enthousiasme en achterdocht. Leuk, zeker. Maar dan kijk je naar het verschil en vraag je jezelf af: "Oké, maar wat heeft hij precies aangeraakt? Kan ik hem vertrouwen? Zal hij het morgen opnieuw op dezelfde manier doen?".
3~
4Dat is waar volgens mij het interessante deel begint. Niet wanneer de agent een functie schrijft, maar wanneer hij capabel genoeg wordt om hele stukken werk op zich te nemen: de repository lezen, een patch maken, tests uitvoeren, een PR openen, terugkomen na een recensiecommentaar. Codex beweegt zich precies in die richting: achtergrondwerk, aparte werkbomen, geïntegreerde browser, automatiseringen, plug-ins, geheugen en meer expliciete toestemmingscontroles.
5~
6Het gaat er niet om je een toekomst voor te stellen waarin niemand meer code leest. Het zou een vreselijke toekomst zijn, maar ook behoorlijk naïef. Het punt is om erachter te komen hoe je kunt samenwerken met agenten die veel kunnen doen zonder ze alles te laten doen.
7~
8## De verandering van gewoonte
9~
10Met de traditionele autocomplete zat je altijd aan het stuur. De AI stelde een regel voor, besloot jij. Bij een agent verandert de relatie echter: je geeft hem een doel en hij doorloopt zelfstandig meerdere stappen.
11~
12Dit is krachtig, maar het verschuift het probleem. De vraag is niet langer alleen maar "kan het model programmeren?". De vraag wordt:
13~
14- Heb ik hem voldoende ruimte gegeven?
15- Weet jij hoe je het resultaat kunt controleren?
16- Werk ik in een geïsoleerde omgeving?
17- Is de eindbeoordeling nog wel humaan en zorgvuldig?
18~
19Een gezonde workflow ziet er meer zo uit dan een toverstaf:
20~
21```mermaid
22flowchart LR
23    Idea[Menselijke taak] --> Scope[Klein, verifieerbaar doel]
24    Scope --> Agent[Agent in werkboom geïsoleerd]
25    Agent --> Checks[Testen, lint, bouwen, browser]
26    Checks --> Review[Menselijke beoordeling]
27    Review --> Merge[Samenvoegen of nieuwe iteratie]
28    Review --> Iterate[Precieze opmerkingen over het verschil]
29    Iterate --> Agent
30```
31~
32Het klinkt minder romantisch dan “de agent bouwt alles”, maar het werkt veel beter. En het is ook hoe teams die goed zijn met mensen werken: duidelijke taken, snelle feedback, expliciete verantwoording.
33~
34## De goede prompt is bijna een goed ticket
35~
36De gevaarlijkste prompt is de vage maar zelfverzekerde prompt: "repareer de facturenpagina", "verbeter de architectuur", "schoon de auth-module op". Dit zijn verzoeken die productief klinken en enorme verschillen genereren. Maar dan merk je dat je archeologie doet.
37~
38Een behulpzame prompt is saaier. Bijvoorbeeld: implementeer CSV-export voor de facturenpagina, wetende dat de tabel zich in `app/(dashboard)/invoices/page.tsx` bevindt, de zoekopdrachten zich in `src/server/invoices.ts` bevinden en dat er al een soortgelijk patroon is in `app/(dashboard)/reports`.
39~
40Voeg vervolgens duidelijke beperkingen toe: verander het databaseschema niet, voeg geen afhankelijkheden toe als een klein hulpprogramma voldoende is, behoud de bestaande UI-stijl. En sluit af met de verificatie: `npm test -- invoices` en `npm run build`.
41~
42Dit type opdracht is niet bedoeld om "beter uit te leggen aan de AI". Het dient vooral om u duidelijker te maken wat u delegeert. Als je het niet concreet kunt opschrijven, is de taak misschien nog niet klaar voor een agent.
43~
44## Drie taken die ik graag delegeer
45~
46De eerste is repetitief maar verifieerbaar werk: tests toevoegen, oproepen naar een nieuwe interne API migreren, importbestanden bijwerken, verouderde componenten vervangen, TypeScript-fouten herstellen. Hier kan de agent uren besparen en is het risico beheersbaar.
47~
48De tweede is verkennend werk: "vind waar dit totaal wordt berekend", "leg mij uit waarom deze test kwetsbaar is", "reproduceer de bug en vertel mij welke bestanden lijken te zijn getroffen". Zelfs als het niet meteen een patch produceert, kan het nuttige verkenningen uitvoeren.
49~
50De derde is terugkerend onderhoudswerk: kleine afhankelijkheidsupdates, opschonen van oude feature-vlaggen, samenvatting van geblokkeerde PR's, controle van vergeten TODO's. Het is niet glamoureus, maar het is precies het soort werk dat zich vaak opstapelt.
51~
52## Drie banen die ik menselijk houd
53~
54Productbeslissingen blijven menselijk. Als een wijziging verandert hoe een gebruiker betaalt, gegevens verwijdert, prijzen ziet of een toestemming begrijpt, wil ik een verantwoordelijke persoon.
55~
56Beveiligingsgrenzen verdienen ook menselijke aandacht: authenticatie, rollen, tokens, gevoelige datalogging, databasemigraties. Een agent kan helpen bij de implementatie, maar hoeft niet de enige beslisser te zijn.
57~
58Ten slotte houd ik alles wat architectonische smaak vereist menselijk. Een agent kan een refactor voorstellen, maar begrijpen of een abstractie echt nodig is of dat we alleen maar een niet-bestaand probleem oppoetsen, blijft een klus.
59~
60## De beoordeling is niet optioneel
61~
62Als een agent goed is, is de verleiding groot om op het groen van de CI te vertrouwen. Het is begrijpelijk. Het is ook het moment waarop de problemen beginnen.
63~
64Ik kijk altijd naar minimaal vijf dingen:
65~
661. Lost de patch alleen de gevraagde taak op?
672. Heeft hij bestanden aangeraakt die er niets mee te maken hadden?
683. Hebben de tests betrekking op nieuw gedrag of gewoon op een gelukkig toeval?
694. Volgt de code lokale patronen?
705. Worden fouten afgehandeld zoals in de rest van het project?
71~
72Als er iets mis is, moet de feedback specifiek zijn. ‘Repareer het’ is lui. Beter: dit hulpprogramma dupliceert `parseMoney` naar `src/lib/money.ts`; hergebruik die functie, voeg een test toe voor de EUR-case en verander de publieke API van de facturatiemodule niet.
73~
74Agenten reageren veel beter op kleine, verifieerbare opmerkingen. Vreemd genoeg vinden de mensen dat ook.
75~
76## Vangrails die de moeite waard zijn
77~
78Als een agent bestanden kan lezen, code kan schrijven en opdrachten kan uitvoeren, moet dit als een krachtig proces worden beschouwd. Er is geen paranoia nodig, je hebt hygiëne nodig.
79~
80Gebruik aparte werkbomen of takken. U kunt dus de verschillen vergelijken, mislukte experimenten weggooien en het werk van de agent niet vermengen met wat u aan het doen was.
81~
82Beperk rechten. Commando's zoals `rg`, `git diff`, `npm test` en `npm run build` kunnen vrij gratis zijn. Implementaties, databasemigraties, toegang tot geheimen en destructieve commando's moeten expliciet blijven.
83~
84Verminder netwerktoegang wanneer u deze niet nodig heeft. Voor veel taken zijn officiële documentatie, pakketregistratie en specifieke interne diensten voldoende. Minder oppervlakte, minder verrassingen.
85~
86Volg acties. Wanneer een patch ter beoordeling arriveert, zou u aanwijzingen, uitgevoerde opdrachten, geslaagde tests en gewijzigde bestanden moeten kunnen reconstrueren. Niet om bureaucratie te creëren, maar om te kunnen begrijpen wat er gebeurt als er iets misgaat.
87~
88## Een gemakkelijke manier om als team aan de slag te gaan
89~
90Als ik agenten in een klein team zou introduceren, zou ik beginnen zonder grote revoluties.
91~
92Ik zou een `agent-ready`-label maken voor problemen met een duidelijke reikwijdte. Ik zou een sjabloon toevoegen met context, beperkingen en verificatieopdrachten. Ik zou om kleine PR vragen, idealiter onder een paar honderd regels. Ik heb tests of schermafbeeldingen nodig voor zichtbare wijzigingen. En bovenal zou ik een persoon verantwoordelijk houden voor de fusie.
93~
94Na twee weken keek ik naar de gegevens: welke taken waren echt versneld, welke beoordelingen waren zwaar, welke aanwijzingen waren verwarrend, welke delen van de codebase te kwetsbaar zijn om te delegeren.
95~
96Het is een minder spectaculaire aanpak dan "vanaf vandaag doen we alles met de agenten", maar het is wel degene waarmee je zonder spijt de derde week kunt bereiken.
97~
98## Het meest menselijke deel
99~
100Het grappige is dat hoe autonomer agenten worden, hoe belangrijker de klassieke vaardigheden weer worden: een goed ticket schrijven, kleine bezuinigingen doorvoeren, tests maken, verschillen lezen, compromissen communiceren. De agent versnelt degenen die al weten hoe ze goed moeten werken. Het vergroot ook de chaos van degenen die slecht delegeren.
101~
102Dus nee, ik zie workflows met meerdere agenten niet als een kortere weg om te stoppen met engineering. Ik zie ze als een manier om meer energie te verschuiven naar de onderdelen die er toe doen: beslissen wat je gaat bouwen, ervoor zorgen dat het werkt en het systeem begrijpelijk houden.
103~
104Agenten kunnen geweldige asynchrone collega's zijn. Maar een asynchrone collega heeft, om nuttig te zijn, context, grenzen en overzicht nodig. Net als iedereen.
105~
106## Nuttige bronnen
107~
108- [Codex voor (bijna) alles - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Voer Codex veilig uit bij OpenAI](https://openai.com/index/running-codex-safely/)
110- [Maak kennis met Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [Wat is er nieuw met de codeeragent GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

2De eerste keer dat een codeeragent daadwerkelijk een bug voor je oplost, is de reactie bijna altijd hetzelfde: een mengeling van enthousiasme en achterdocht. Leuk, zeker. Maar dan kijk je naar het verschil en vraag je jezelf af: "Oké, maar wat heeft hij precies aangeraakt? Kan ik hem vertrouwen? Zal hij het morgen opnieuw op dezelfde manier doen?".

4Dat is waar volgens mij het interessante deel begint. Niet wanneer de agent een functie schrijft, maar wanneer hij capabel genoeg wordt om hele stukken werk op zich te nemen: de repository lezen, een patch maken, tests uitvoeren, een PR openen, terugkomen na een recensiecommentaar. Codex beweegt zich precies in die richting: achtergrondwerk, aparte werkbomen, geïntegreerde browser, automatiseringen, plug-ins, geheugen en meer expliciete toestemmingscontroles.

6Het gaat er niet om je een toekomst voor te stellen waarin niemand meer code leest. Het zou een vreselijke toekomst zijn, maar ook behoorlijk naïef. Het punt is om erachter te komen hoe je kunt samenwerken met agenten die veel kunnen doen zonder ze alles te laten doen.

8## De verandering van gewoonte

10Met de traditionele autocomplete zat je altijd aan het stuur. De AI stelde een regel voor, besloot jij. Bij een agent verandert de relatie echter: je geeft hem een doel en hij doorloopt zelfstandig meerdere stappen.

11~

12Dit is krachtig, maar het verschuift het probleem. De vraag is niet langer alleen maar "kan het model programmeren?". De vraag wordt:

13~

14- Heb ik hem voldoende ruimte gegeven?

15- Weet jij hoe je het resultaat kunt controleren?

16- Werk ik in een geïsoleerde omgeving?

17- Is de eindbeoordeling nog wel humaan en zorgvuldig?

18~

19Een gezonde workflow ziet er meer zo uit dan een toverstaf:

20~

21```mermaid

22flowchart LR

23 Idea[Menselijke taak] --> Scope[Klein, verifieerbaar doel]

24 Scope --> Agent[Agent in werkboom geïsoleerd]

25 Agent --> Checks[Testen, lint, bouwen, browser]

26 Checks --> Review[Menselijke beoordeling]

27 Review --> Merge[Samenvoegen of nieuwe iteratie]

28 Review --> Iterate[Precieze opmerkingen over het verschil]

29 Iterate --> Agent

30```

31~

32Het klinkt minder romantisch dan “de agent bouwt alles”, maar het werkt veel beter. En het is ook hoe teams die goed zijn met mensen werken: duidelijke taken, snelle feedback, expliciete verantwoording.

33~

34## De goede prompt is bijna een goed ticket

35~

36De gevaarlijkste prompt is de vage maar zelfverzekerde prompt: "repareer de facturenpagina", "verbeter de architectuur", "schoon de auth-module op". Dit zijn verzoeken die productief klinken en enorme verschillen genereren. Maar dan merk je dat je archeologie doet.

37~

38Een behulpzame prompt is saaier. Bijvoorbeeld: implementeer CSV-export voor de facturenpagina, wetende dat de tabel zich in `app/(dashboard)/invoices/page.tsx` bevindt, de zoekopdrachten zich in `src/server/invoices.ts` bevinden en dat er al een soortgelijk patroon is in `app/(dashboard)/reports`.

39~

40Voeg vervolgens duidelijke beperkingen toe: verander het databaseschema niet, voeg geen afhankelijkheden toe als een klein hulpprogramma voldoende is, behoud de bestaande UI-stijl. En sluit af met de verificatie: `npm test -- invoices` en `npm run build`.

41~

42Dit type opdracht is niet bedoeld om "beter uit te leggen aan de AI". Het dient vooral om u duidelijker te maken wat u delegeert. Als je het niet concreet kunt opschrijven, is de taak misschien nog niet klaar voor een agent.

43~

44## Drie taken die ik graag delegeer

45~

46De eerste is repetitief maar verifieerbaar werk: tests toevoegen, oproepen naar een nieuwe interne API migreren, importbestanden bijwerken, verouderde componenten vervangen, TypeScript-fouten herstellen. Hier kan de agent uren besparen en is het risico beheersbaar.

47~

48De tweede is verkennend werk: "vind waar dit totaal wordt berekend", "leg mij uit waarom deze test kwetsbaar is", "reproduceer de bug en vertel mij welke bestanden lijken te zijn getroffen". Zelfs als het niet meteen een patch produceert, kan het nuttige verkenningen uitvoeren.

49~

50De derde is terugkerend onderhoudswerk: kleine afhankelijkheidsupdates, opschonen van oude feature-vlaggen, samenvatting van geblokkeerde PR's, controle van vergeten TODO's. Het is niet glamoureus, maar het is precies het soort werk dat zich vaak opstapelt.

51~

52## Drie banen die ik menselijk houd

53~

54Productbeslissingen blijven menselijk. Als een wijziging verandert hoe een gebruiker betaalt, gegevens verwijdert, prijzen ziet of een toestemming begrijpt, wil ik een verantwoordelijke persoon.

55~

56Beveiligingsgrenzen verdienen ook menselijke aandacht: authenticatie, rollen, tokens, gevoelige datalogging, databasemigraties. Een agent kan helpen bij de implementatie, maar hoeft niet de enige beslisser te zijn.

57~

58Ten slotte houd ik alles wat architectonische smaak vereist menselijk. Een agent kan een refactor voorstellen, maar begrijpen of een abstractie echt nodig is of dat we alleen maar een niet-bestaand probleem oppoetsen, blijft een klus.

59~

60## De beoordeling is niet optioneel

61~

62Als een agent goed is, is de verleiding groot om op het groen van de CI te vertrouwen. Het is begrijpelijk. Het is ook het moment waarop de problemen beginnen.

63~

64Ik kijk altijd naar minimaal vijf dingen:

65~

661. Lost de patch alleen de gevraagde taak op?

672. Heeft hij bestanden aangeraakt die er niets mee te maken hadden?

683. Hebben de tests betrekking op nieuw gedrag of gewoon op een gelukkig toeval?

694. Volgt de code lokale patronen?

705. Worden fouten afgehandeld zoals in de rest van het project?

71~

72Als er iets mis is, moet de feedback specifiek zijn. ‘Repareer het’ is lui. Beter: dit hulpprogramma dupliceert `parseMoney` naar `src/lib/money.ts`; hergebruik die functie, voeg een test toe voor de EUR-case en verander de publieke API van de facturatiemodule niet.

73~

74Agenten reageren veel beter op kleine, verifieerbare opmerkingen. Vreemd genoeg vinden de mensen dat ook.

75~

76## Vangrails die de moeite waard zijn

77~

78Als een agent bestanden kan lezen, code kan schrijven en opdrachten kan uitvoeren, moet dit als een krachtig proces worden beschouwd. Er is geen paranoia nodig, je hebt hygiëne nodig.

79~

80Gebruik aparte werkbomen of takken. U kunt dus de verschillen vergelijken, mislukte experimenten weggooien en het werk van de agent niet vermengen met wat u aan het doen was.

81~

82Beperk rechten. Commando's zoals `rg`, `git diff`, `npm test` en `npm run build` kunnen vrij gratis zijn. Implementaties, databasemigraties, toegang tot geheimen en destructieve commando's moeten expliciet blijven.

83~

84Verminder netwerktoegang wanneer u deze niet nodig heeft. Voor veel taken zijn officiële documentatie, pakketregistratie en specifieke interne diensten voldoende. Minder oppervlakte, minder verrassingen.

85~

86Volg acties. Wanneer een patch ter beoordeling arriveert, zou u aanwijzingen, uitgevoerde opdrachten, geslaagde tests en gewijzigde bestanden moeten kunnen reconstrueren. Niet om bureaucratie te creëren, maar om te kunnen begrijpen wat er gebeurt als er iets misgaat.

87~

88## Een gemakkelijke manier om als team aan de slag te gaan

89~

90Als ik agenten in een klein team zou introduceren, zou ik beginnen zonder grote revoluties.

91~

92Ik zou een `agent-ready`-label maken voor problemen met een duidelijke reikwijdte. Ik zou een sjabloon toevoegen met context, beperkingen en verificatieopdrachten. Ik zou om kleine PR vragen, idealiter onder een paar honderd regels. Ik heb tests of schermafbeeldingen nodig voor zichtbare wijzigingen. En bovenal zou ik een persoon verantwoordelijk houden voor de fusie.

93~

94Na twee weken keek ik naar de gegevens: welke taken waren echt versneld, welke beoordelingen waren zwaar, welke aanwijzingen waren verwarrend, welke delen van de codebase te kwetsbaar zijn om te delegeren.

95~

96Het is een minder spectaculaire aanpak dan "vanaf vandaag doen we alles met de agenten", maar het is wel degene waarmee je zonder spijt de derde week kunt bereiken.

97~

98## Het meest menselijke deel

99~

100Het grappige is dat hoe autonomer agenten worden, hoe belangrijker de klassieke vaardigheden weer worden: een goed ticket schrijven, kleine bezuinigingen doorvoeren, tests maken, verschillen lezen, compromissen communiceren. De agent versnelt degenen die al weten hoe ze goed moeten werken. Het vergroot ook de chaos van degenen die slecht delegeren.

101~

102Dus nee, ik zie workflows met meerdere agenten niet als een kortere weg om te stoppen met engineering. Ik zie ze als een manier om meer energie te verschuiven naar de onderdelen die er toe doen: beslissen wat je gaat bouwen, ervoor zorgen dat het werkt en het systeem begrijpelijk houden.

103~

104Agenten kunnen geweldige asynchrone collega's zijn. Maar een asynchrone collega heeft, om nuttig te zijn, context, grenzen en overzicht nodig. Net als iedereen.

105~

106## Nuttige bronnen

107~

108- [Codex voor (bijna) alles - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Voer Codex veilig uit bij OpenAI](https://openai.com/index/running-codex-safely/)

110- [Maak kennis met Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [Wat is er nieuw met de codeeragent GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~