Agentic Coding op Schaal

Hoe twintig jaar engineering-discipline een swarm van AI-agents productie-waardig maakt

Bij 42 BV bouwen we al ruim twintig jaar robuuste, veilige en snelle software voor klanten in onder andere de zorg, het sociaal domein en de informatiebeveiliging. Diezelfde discipline projecteren we nu op agentic coding. Het resultaat mag er zijn: we leveren hele features op met minder dan 1% handwerk, en doen dat gemiddeld een factor 10 sneller dan met onze klassieke sprintaanpak.

Wat dat in de praktijk betekent is dat features die voorheen drie weken in een sprint zouden zitten, nu binnen enkele dagen in productie staan. Met dezelfde kwaliteitsstandaard die we al twee decennia hanteren.

Hoe we daar gekomen zijn, begon met flink struikelen.

Het probleem: de kopieer-plak-loop

Iedereen die serieus met agentic coding aan de slag gaat, kent het scenario: je laat Claude Sonnet iets bouwen, kopieert het naar Codex voor review, plakt de feedback terug bij Sonnet, herhaalt. Een ontwikkelaar zit zo nog steeds uren per dag via het toetsenbord werk te verstouwen dat eigenlijk vanzelf zou moeten gaan.

We begonnen klein, namelijk met één agentic skill in een markdown-bestand dat de hele swarm moest aansturen. Aanvankelijk werkte dat aardig. Maar gaandeweg groeide dat ene bestand uit tot meer dan 5.000 regels. Elke aanpassing werd een gok, soms werd het beter, soms onverwacht slechter. We verloren grip en voorspelbaarheid. De conclusie werd onvermijdelijk: één slimme agent die zichzelf aanstuurt, schaalt niet.

De omslag: van slimme agent naar strakke regie

In plaats van een nóg slimmere agent te bouwen, hebben we alles omgedraaid. We zijn een Python-project gestart waarin níet de AI de regie voert, maar een deterministische orchestrator. Wij noemen het de Swarm Engine. De engine bepaalt de stappen, de AI voert ze uit. Saai? Misschien. Maar het is juist dat saaie, voorspelbare karakter dat het verschil maakt tussen een leuk experiment en iets dat we naar productie durven brengen.

Determinisme klinkt minder spannend dan "AI-agents", maar het is wel het verschil dat onze klanten merken.

Hoe de swarm werkt: stel je een bouwteam voor

Het makkelijkst is om de Swarm Engine te zien als een goed geoliede bouwplaats.

Een hoofdaannemer (de engine) krijgt de opdracht binnen, hakt hem in deeltaken, en bepaalt welke deeltaken parallel uitgevoerd kunnen worden en welke op elkaar moeten wachten. Hij stuurt vervolgens maximaal vijf onderaannemers (de Implementor agents) tegelijk aan, elk op een eigen bouwplaats. Zo zitten ze elkaar niet in de weg.

Elk stukje opgeleverd werk gaat eerst door een automatische keuring: bouwt het, voldoet het aan de architectuurregels, slagen de tests? Pas dan komt er een inspecteur (de Reviewer agent) langs die de kwaliteit beoordeelt en die de onderaannemer terugstuurt als iets niet klopt. In de praktijk gebeurt dat bij ongeveer de helft van de deeltaken.

Onderaannemers praten niet onderling. Ze melden zich af bij de hoofdaannemer, en die beslist wat de volgende stap is. Dat houdt de regie op één plek, niet bij een agent die toevallig denkt dat hij klaar is.

Loopt een deeltaak vast, bijvoorbeeld omdat twee onderaannemers per ongeluk aan hetzelfde fundament hebben gewerkt, dan komt een aparte "voorman" (de Feature Branch Owner) in actie. Die beschikt over een rescue toolkit: een verzameling vaste interventies die we altijd eerst proberen voordat een mens überhaupt in beeld komt. Het uitgangspunt is dat elke handmatige ingreep geformaliseerd wordt tot een toolkit-functie, anders sluipt het babysitten gewoon weer terug.

Kwaliteit op drie plekken bewaakt

De inspecteur kijkt niet alleen naar codekwaliteit, maar naar wat we concerns noemen, zowel generieke zaken (performance, security, toegankelijkheid) als applicatiespecifieke. In Normatik betekent dat bijvoorbeeld correcte conversie van geïmporteerde documenten en gegarandeerde laadtijden van compliance-pagina's.

Een concern werkt pas écht als hij op drie plekken bewaakt wordt:

• In de opdrachtbeschrijving, voordat het werk begint.
• In de werkinstructie voor de Implementor agent.
• In de checklist van de Reviewer, als laatste vangnet.

Wat alleen in de inspectie zit, vinden we te laat. Wat alleen in de opdrachtbeschrijving staat, raakt onderweg verloren. Drie keer is dekkend.

Drie fases in elk traject

Een feature doorloopt bij ons drie fases:

1. Werkvoorbereiding (2 tot 8 uur per feature). Een grondige brainstorm, een gedetailleerde opdrachtbeschrijving, deeltaken uitgesplitst inclusief alle concerns. Dit is mensenwerk en het bepaalt voor een groot deel het eindresultaat. Onze ervaren engineers zijn hier in hun element.
2. Implementatie. De Swarm Engine neemt het over. Dit is het deel waar we het meeste werk geautomatiseerd hebben.
3. Refurbishing (4 tot 8 uur per feature). Puntjes op de i, randgevallen, polish, technische review, bijsturen. Weer mensenwerk.

De grote winst zit hem niet alleen in het feit dat AI sneller typt dan een mens (dat ook). De winst zit vooral in het feit dat onze ervaren engineers zich kunnen concentreren op de fases waarin ze het meeste verschil maken: de voorbereiding en de afronding.

Wanneer dit werkt, en wanneer niet

Dit systeem werkt alleen in projecten die expliciet zijn voorbereid op deze manier van werken. Dat vraagt een stevig technisch fundament met een dichte laag automatische kwaliteitscontroles, zoals architectuurregels (ArchUnit), linting (ESLint), strikt typegebruik en uitgebreide end-to-end-testsuites. Zonder dat fundament heeft de automatische keuring niets om op te steunen en wordt de hele swarm run een gok.

En hier komt die twintig jaar discipline binnen. Die kwaliteitscontroles bouwen we niet pas nu. Ze zaten al jaren in onze projecten omdat we ze altijd belangrijk hebben gevonden. De swarm is daardoor geen losse innovatie, maar de logische volgende laag op een fundament dat we al jaren zorgvuldig leggen. Andere partijen beginnen nu pas met AI; wij projecteren een kwaliteitscultuur op AI die er al twee decennia stond.

Wat het concreet oplevert

Een recent voorbeeld uit Normatik, ons platform voor NIS2- en ISO 27001-compliance: een klant vroeg om een uitbreiding op de auditfunctionaliteit. Wie heeft welke compliance-documenten wanneer aangepast, met filterbare exports voor de externe auditor. In onze klassieke werkwijze hadden we hier twee sprints (vier weken) voor gereserveerd. Wat er werkelijk gebeurde: maandagochtend stond de opdrachtbeschrijving klaar, woensdagmiddag was de feature af, donderdag stond hij in productie.

Geen incident. Geen heldenwerk. Gewoon hoe het tegenwoordig gaat.

Wat we hebben geleerd

• Determinisme wint van intelligentie. Een strakke orchestrator met duidelijke regels presteert beter dan een hyper-intelligente maar onvoorspelbare agent.
• Goede voorbereiding blijft essentieel. Een vage opdrachtbeschrijving levert een vage feature op, swarm of geen swarm. Hier zit ervaring in.
• Observability en resource management zijn geen luxe. Wie tientallen processen tegelijk laat draaien zonder goed inzicht en strakke opruimroutines, krijgt het hard terug. Dit is precies het soort engineering-werk dat je in twintig jaar aanleert.

Wat dit voor onze klanten betekent

Wat we hier laten zien, is wat 42 BV vandaag standaard doet: features in dagen waar het vroeger weken kostte, op het kwaliteitsniveau dat onze klanten al twintig jaar van ons gewend zijn. Heb je een complex softwareproject waarvan de doorlooptijd of de hoge kosten je beperken? Of overweeg je een rebuild waar je tegenop ziet? Dan is het tijd voor een gesprek. Wat gisteren nog een groot project was, is vandaag een paar swarm-runs.