Toen ik Rewiring software delivery for the agentic era van McKinsey las, zag ik geen verre toekomstvisie. Ik herkende onze eigen manier van werken aan het 3R Platform.
McKinsey opent met een product owner die 's morgens bekijkt wat AI-agenten tijdens de nacht hebben uitgevoerd. Vereisten zijn verfijnd, architectuurkeuzes gecontroleerd, code is geschreven en getest, en de open beslissingen liggen klaar voor menselijke beoordeling. Niemand werkte laat. De agenten deden het uitvoerende werk.
De paper noemt drie tot vijf keer meer productiviteit en een daling van de gemiddelde teamgrootte met circa zestig procent in vroege toepassingen. Wij hebben geen gecontroleerde nulmeting waarmee we zulke cijfers voor 3R kunnen claimen. Toch herkennen we het onderliggende mechanisme volledig. Onze ontwikkelsnelheid komt niet voort uit één betere codeassistent. Ze komt voort uit een ontwikkelmodel dat rond samenwerking tussen mensen en agenten is gebouwd.
Agentic software development is voor ons geen experiment naast de bouw van het platform. Het is hoe we het platform bouwen.
Een ticket wordt een uitvoerbaar werkpakket
Onze ontwikkelcyclus begint niet met een losse prompt om een functie te bouwen. Een vraag wordt eerst een afgebakend GitHub-ticket met het gewenste resultaat, acceptatiecriteria, verwachte impact en bewijs waarmee we achteraf kunnen vaststellen of het probleem werkelijk is opgelost.
Dat verschil lijkt klein, maar het bepaalt bijna alles wat volgt. Een agent kan alleen autonoom werken wanneer de invoer voldoende helder en gestructureerd is. Een vaag idee levert sneller code op, maar niet noodzakelijk de juiste code. Een goed werkpakket geeft de agent een probleem om op te lossen, grenzen waarbinnen hij mag handelen en een toetsbaar eindpunt.
Van daaruit neemt een orkestratielaag het werk over. Afhankelijk van de taak gaat die naar Codex Cloud, een tijdelijke ontwikkelwerker in AWS of een agent op een lokale machine. Meerdere taken kunnen in aparte werkdraden tegelijk lopen. De werkers lezen dezelfde repository-instructies, zoeken de relevante code en bouwen elk op een eigen branch. Ze voeren de passende controles uit, leggen hun wijzigingen vast en openen een draft pull request.
Voor ons is dat het concrete equivalent van McKinseys agentic factory. De mens hoeft niet meer elke regel code zelf te schrijven of iedere technische overdracht handmatig te coördineren. Het systeem zet een heldere productvraag om in een eerste, controleerbare oplossing.
De keten stopt niet wanneer de code geschreven is
Een codeagent die een pull request opent, is nog geen agentic ontwikkelmodel. Zonder de rest van de keten krijg je hoogstens sneller geproduceerde onzekerheid.
Bij 3R is de implementatie daarom maar één stap. De agent voert eerst snelle technische controles uit. Daarna neemt GitHub Actions de zwaardere verificatie over. Afhankelijk van de wijziging doorloopt de oplossing gerichte of volledige tests, inclusief browsertests over de verschillende platformrollen en controles op databasebeveiliging en klantafscherming.
Bij zichtbare aanpassingen wordt ook een vertraagde schermopname gemaakt. Daardoor kunnen we een nieuwe flow bekijken terwijl andere tests nog lopen. We hoeven dus niet te wachten tot het einde van de technische cyclus om te zien of de oplossing in de praktijk begrijpelijk aanvoelt.
Tegelijk beoordeelt een onafhankelijke agent de code. Die controleert niet alleen of de wijziging technisch geldig lijkt, maar ook of ze neveneffecten, veiligheidsrisico's of onvolledig afgedekte scenario's introduceert. Bevindingen gaan terug naar dezelfde ontwikkelwerker. Pas na de correcties wordt de volledige relevante testset opnieuw uitgevoerd op de definitieve versie.
Dit is een belangrijk verschil met klassiek AI-ondersteund programmeren. Wij gebruiken geen agent die code schrijft en het resultaat zelf goedkeurt. Implementatie, tests, onafhankelijke controle en menselijke beoordeling zijn afzonderlijke verantwoordelijkheden in één doorlopende keten.
De mens verdwijnt niet, zijn werk verschuift
McKinsey beschrijft hoe menselijke rollen verschuiven van artefacten produceren naar het ontwerpen en verbeteren van het systeem dat die artefacten produceert. Dat is precies wat we tijdens de bouw van 3R ervaren.
De schaarste zit steeds minder in het kunnen schrijven van een component, een databasefunctie of een test. De echte vragen liggen ervoor en erna. We moeten scherp krijgen welk probleem we oplossen, of de oplossing bij de productrichting past, welke uitzonderingen belangrijk zijn en welke risico's aanvaardbaar blijven. Wat technisch correct is, moet ook werkelijk goed genoeg zijn om in het product op te nemen.
Die beslissingen blijven bij ons. Agenten mogen een ticket analyseren, code bouwen, tests schrijven, een eerste selectie van regressietests voorstellen en bevindingen verwerken. Ze mogen niet zelf beslissen dat hun werk goed genoeg is om samen te voegen. Elke pull request blijft een draft tot Johan of Vincent de actuele versie expliciet heeft goedgekeurd. Zodra een agent daarna nog iets wijzigt, vervalt die goedkeuring en begint de laatste controle opnieuw.
Dat is geen rem op autonomie. Het maakt autonomie bruikbaar. De agenten krijgen veel vrijheid binnen het werkpakket, terwijl productrichting, architecturale keuzes met grote impact en de uiteindelijke aanvaarding menselijk blijven.
Snelheid vraagt meer discipline, niet minder
De verleiding bij AI-ontwikkeling is om vooral naar de hoeveelheid geproduceerde code te kijken. Dat is de minst interessante maatstaf. Agenten kunnen ook bijzonder snel de verkeerde oplossing bouwen.
Hoe hoger de uitvoeringssnelheid, hoe belangrijker de kwaliteit van het systeem eromheen wordt. Daarom bevat onze repository niet alleen applicatiecode. Ze bevat ook instructies voor ontwikkelagenten, taakspecifieke werkwijzen, testcontracten, veiligheidsregels, besliscriteria en herstelprocedures. Die kennis wordt samen met het product onderhouden.
Wanneer iets fout loopt, proberen we niet alleen die ene fout te herstellen. We bekijken ook waarom het ontwikkelsysteem ze toeliet. De oorzaak kan ontbrekende context zijn, een dubbelzinnig acceptatiecriterium, een onveilige aanname, een ontbrekende test of een onduidelijke overdracht tussen implementatie en controle. De correctie hoort dan niet alleen in de code, maar ook in de instructies, testset of werkwijze die de volgende agent gebruikt.
Dat sluit aan bij McKinseys pleidooi voor een kennisinfrastructuur. In onze praktijk is de repository niet enkel de plaats waar broncode staat. Ze is ook het gedeelde geheugen van het ontwikkelteam, menselijk én digitaal. Nieuwe agenten hoeven niet telkens vanaf nul te leren hoe 3R gebouwd wordt. Ze krijgen de actuele regels, patronen en lessen mee op het moment dat ze aan een taak beginnen.
Ook de overdrachten zelf zijn software geworden
Traditionele softwareontwikkeling bevat veel menselijke overdrachten. Iemand schrijft een analyse, een ontwikkelaar interpreteert ze, een tester reconstrueert de bedoeling en een product owner probeert achteraf te bepalen of het resultaat klopt. In elke overgang kan betekenis verloren gaan.
In onze agentic ontwikkelketen zijn die overdrachten expliciet ontworpen. Het ticket bevat het probleem en de aanvaardingscriteria. De ontwikkelwerker levert code, testresultaten en een draft pull request. De testomgeving koppelt haar bewijs aan de precieze versie van de code. De onafhankelijke controleagent formuleert concrete bevindingen. De schermopname toont wat de gebruiker werkelijk zal zien. De mens krijgt uiteindelijk geen map vol losse technische artefacten, maar één controleerbaar beslispakket.
Zelfs de orkestratie is een afzonderlijke rol geworden. Een agent houdt bij welke taak bij welk ticket hoort, welke codeversie getest is, of de onafhankelijke controle afgerond is en of de menselijke goedkeuring nog geldig is. Hij kan werk opvolgen en correcties opnieuw naar dezelfde context sturen, maar hij schrijft niet stilletjes zelf de ontbrekende code en keurt niets namens ons goed.
Dit is wellicht de grootste verschuiving. We automatiseren niet alleen programmeerwerk. We ontwerpen ook de samenwerking, de bewijslast en de beslismomenten als onderdelen van het ontwikkelsysteem.
Wat we nog aan het leren zijn
Onze aanpak is geen afgewerkte fabriek. Ze is zelf een product in ontwikkeling.
We leren hoe taken het best worden opgesplitst zonder de samenhang te verliezen. We zoeken uit welke controles lokaal, in de cloud of in GitHub Actions thuishoren. We hebben de testinfrastructuur aangepast zodat meerdere agenten veilig parallel kunnen werken zonder elkaars omgeving te verstoren. We verfijnen wanneer een agent zelfstandig mag doorgaan en wanneer een architecturale of datagerelateerde keuze eerst menselijke afstemming vraagt.
Ook de kosten van autonomie worden zichtbaarder. Meer agenten inzetten betekent niet automatisch meer vooruitgang. Slechte orkestratie veroorzaakt dubbel werk, concurrerende wijzigingen en onnodige testcycli. Een snelle implementatie die de verkeerde productaanname volgt, kost nog altijd tijd. Agentic software development verwijdert de nood aan productdiscipline dus niet. Het straft het gebrek eraan alleen sneller af.
Net daarom vind ik de McKinsey-paper zo herkenbaar. De auteurs schrijven niet dat organisaties simpelweg meer agenten moeten inzetten. Ze stellen dat de volledige ontwikkelstructuur moet worden hertekend. Vereisten, kennis, architectuur, testen, controle en menselijke rollen moeten als één systeem werken.
De echte voorsprong zit in het ontwikkelmodel
Het 3R Platform wordt gebouwd door een klein kernteam met een groeiend digitaal ontwikkelteam eromheen. Daardoor kunnen we tegelijk aan productfunctionaliteit, databescherming, tests, documentatie en operationele tooling werken zonder voor elke specialisatie eerst een klassieke teamstructuur uit te bouwen.
De waarde daarvan zit niet alleen in snelheid. We bouwen een institutioneel geheugen op waarin elke correctie het systeem beter kan maken. We kunnen wijzigingen vroeg tonen, breed testen en gericht laten beoordelen. En de menselijke aandacht kan verschuiven naar de plekken waar ze het meeste waarde toevoegt: productrichting, gebruikersbegrip, architectuur en finale verantwoordelijkheid.
Dat maakt onze eigen bouw van 3R voor mij minstens even interessant als de functies in het platform. We adviseren organisaties om werk opnieuw te ontwerpen rond mensen en digitale collega's. Tijdens de ontwikkeling van ons eigen product ervaren we dagelijks wat dat werkelijk vraagt.
Agentic software development is dus niet alleen een technologie waarmee we 3R sneller proberen te bouwen. Het is een nieuw operationeel model dat we zelf aan het uitvinden, begrenzen en verbeteren zijn. De code is daarvan het zichtbare resultaat. De echte innovatie zit in het systeem dat die code voortbrengt.