Codex- en multi-agentworkflow: werk met agenten zonder de controle te verliezen
· 7 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
De 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?".
Dat 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.
Het 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.
De verandering van gewoonte
Met 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.
Dit is krachtig, maar het verschuift het probleem. De vraag is niet langer alleen maar "kan het model programmeren?". De vraag wordt:
- Heb ik hem voldoende ruimte gegeven?
- Weet jij hoe je het resultaat kunt controleren?
- Werk ik in een geïsoleerde omgeving?
- Is de eindbeoordeling nog wel humaan en zorgvuldig?
Een gezonde workflow ziet er meer zo uit dan een toverstaf:
Het 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.
De goede prompt is bijna een goed ticket
De 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.
Een 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.
Voeg 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.
Dit 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.
Drie taken die ik graag delegeer
De 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.
De 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.
De 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.
Drie banen die ik menselijk houd
Productbeslissingen blijven menselijk. Als een wijziging verandert hoe een gebruiker betaalt, gegevens verwijdert, prijzen ziet of een toestemming begrijpt, wil ik een verantwoordelijke persoon.
Beveiligingsgrenzen 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.
Ten 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.
De beoordeling is niet optioneel
Als 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.
Ik kijk altijd naar minimaal vijf dingen:
- Lost de patch alleen de gevraagde taak op?
- Heeft hij bestanden aangeraakt die er niets mee te maken hadden?
- Hebben de tests betrekking op nieuw gedrag of gewoon op een gelukkig toeval?
- Volgt de code lokale patronen?
- Worden fouten afgehandeld zoals in de rest van het project?
Als 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.
Agenten reageren veel beter op kleine, verifieerbare opmerkingen. Vreemd genoeg vinden de mensen dat ook.
Vangrails die de moeite waard zijn
Als 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.
Gebruik 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.
Beperk 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.
Verminder netwerktoegang wanneer u deze niet nodig heeft. Voor veel taken zijn officiële documentatie, pakketregistratie en specifieke interne diensten voldoende. Minder oppervlakte, minder verrassingen.
Volg 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.
Een gemakkelijke manier om als team aan de slag te gaan
Als ik agenten in een klein team zou introduceren, zou ik beginnen zonder grote revoluties.
Ik 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.
Na 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.
Het 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.
Het meest menselijke deel
Het 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.
Dus 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.
Agenten kunnen geweldige asynchrone collega's zijn. Maar een asynchrone collega heeft, om nuttig te zijn, context, grenzen en overzicht nodig. Net als iedereen.