AI schrijft code, maar kan uw infrastructuur het bijhouden?

We leven door een van de vreemdste omkeringen in de geschiedenis van software-engineering. Decennialang was het doel determinisme; het bouwen van systemen die altijd hetzelfde gedrag vertonen. Nu leggen we probabilistische AI-agents bovenop die basis, waardoor code op een alarmerende schaal en snelheid gegenereerd wordt. En eerlijk gezegd? De meeste van onze infrastructuur was niet gebouwd voor dit.

Ik heb jaren gewerkt aan DevOps-tooling, onderzoek gecoördineerd en geholpen bij het bereiken van de hoogste prestaties van engineeringteams. Wat ik nu zie met AI-gedreven ontwikkeling is meer dan alleen een evolutie. Het legt elke scheur in onze bestaande workflows bloot.

Het probleem is al hier

Een 2025 GitClear-studie vond dat bijna 7% van de commits nu code bevatten die gegenereerd is door AI. Hun eerder onderzoek van 153 miljoen regels gewijzigde code onthulde de kosten: “code-churn” – code die binnen twee weken herschreven of verwijderd werd – verdubbelde in 2024 in vergelijking met pre-AI-baselines.

De beveiligingsimplicaties zijn eveneens schokkend. Recent onderzoek van 80 gecureerde coderingstaken over meer dan 100 grote taalmodellen toonde aan dat AI-gegenereerde code beveiligingskwetsbaarheden introduceert in 45% van de gevallen. De invloed in de praktijk? Een op de vijf CISO’s meldt nu grote incidenten die rechtstreeks worden veroorzaakt door AI-gegenereerde code.

De snelheidswinsten zijn echt, maar zo zijn ook de stabiliteitskosten.

Het versterkende effect

Een ding dat ik heb geleerd, is dat AI alles versterkt. Als je goede praktijken hebt, maakt AI ze beter en sneller. Als je processen rommelig zijn, verergert AI die rommel ook. Dit weerspiegelt een patroon dat jaar na jaar verschijnt in DORA‘s jaarlijkse DevOps-rapporten: minder variabelen leiden tot betere resultaten. Succesvolle teams standaardiseren op minder besturingssystemen, minder programmeertalen, minder manieren van doen.

AI-agents volgen hetzelfde patroon. Geef ze een consistente omgeving waarin Python dezelfde versie betekent op elke machine van elke ontwikkelaar, waar afhankelijkheden zijn vergrendeld en bijgehouden, en ze excelleren. Forceer ze om 17 verschillende configuraties te navigeren, elk met subtiele verschillen, en je verbrandt tokens om omgevingsvreemde eigenschappen te doorgronden in plaats van echte problemen op te lossen.

Het determinisme-paradox

Dit creëert een fascinerende spanning. Jarenlang zocht de informatica naar determinisme als het uiteindelijke doel. Nu draaien we probabilistische workloads, AI-modellen die letterlijk niet kunnen garanderen dat ze tweemaal hetzelfde resultaat opleveren, op systemen die zijn ontworpen voor voorspelbaarheid.

Mijn antwoord? Houd zo veel mogelijk van de stack deterministisch. Als je 80% van je infrastructuur op een deterministisch niveau kunt houden, hebben je AI-agents minder variabelen om te beheren. Ze spenderen geen contextvensters aan “Waarom werkte deze afhankelijkheid niet?” of “Laat me deze build-opdracht nog een keer proberen.” Ze zijn gefocust op het echte werk dat je hen vraagt te doen.

Denk erover na: wanneer een agent probeert iets te compileren en native bindings falen omdat ImageMagick niet is geïnstalleerd, is dat een token-dure omweg. Als je omgeving al alles bevat wat nodig is (compilers, bibliotheken, de volledige afhankelijkheidsboom tot libc), werkt de agent gewoon. Geen debugging, geen trial en error, gewoon vooruitgang.

Specificatie en validatie zijn sleutel

Wat duidelijk wordt, is dat AI-gedreven ontwikkeling ons dwingt om harder na te denken over twee historisch onderschatte vaardigheden: specificatie en validatie. Je moet articuleren wat je eigenlijk aan het bouwen bent, en je moet robuuste manieren hebben om te verifiëren of je het hebt.

Ik heb iets interessants opgemerkt: mensen met een productmanagement- of productengineeringsachtergrond zijn vaak succesvoller met AI-agents op dit moment. Ze zijn al getraind om te denken in termen van vereisten, succescriteria en compromissen. Ze zijn comfortabel met het stellen van “Waarom maakte je die keuze?” en aanpassen op basis van de redenering.

Validatie, weten of het ding eigenlijk correct is, is altijd het moeilijkste probleem van software-engineering geweest. QA is decennialang schandelijk onderschat, maar het is het moeilijkste deel: bepalen of software de echte gebruikersbehoefte oplost. AI lost dit niet op. Als het al iets doet, maakt het het nog kritieker, omdat je nu probabilistische outputs valideert tegen deterministische vereisten.

Vertrouw, maar verifieer (en controleer)

Er is een gevoel dat ik begin te omarmen: we zouden moeten aannemen dat code die gegenereerd is door AI vijandig is totdat het het tegendeel bewijst. Niet omdat AI kwaadaardig is, maar omdat we het gewoon niet weten. We kunnen niet elke regel auditen als agents duizenden regels per dag gegenereerd worden.

Dit betekent dat we de controlepunten moeten verschuiven. Als we niet alles kunnen afsluiten bij de ontwikkeling, hebben we sterkere controles nodig bij de uitvoering. Operators, SRE’s, platformteams, wie dan ook verantwoordelijk is voor productie, moeten betere zichtbaarheid hebben in wat er draait, complete afhankelijkheidstracking en duidelijke herkomst voor elk artifact.

Dit is waar reproduceerbaarheid essentieel wordt. Wanneer je wiskundig kunt bewijzen dat het artifact dat je lokaal getest hebt identiek is aan wat er in productie draait – dezelfde invoer, dezelfde uitvoer, dezelfde afhankelijkheidsslot – kun je beginnen met het nemen van intelligente beslissingen. Misschien hoef je geen eenheidstests opnieuw uit te voeren in CI als je ze al lokaal hebt uitgevoerd en er niets is veranderd. Misschien kun je testdekking koppelen aan codeveranderingen en irrelevante test suites overslaan.

Wat komt er nu

We zijn op een keerpunt. Teams die al goede praktijken hadden, zien enorme productiviteitswinsten met AI. Teams die al worstelden, worstelen nu sneller.

De infrastructuur die AI-gedreven ontwikkeling aandrijft, moet vanaf de grond af aan zijn gebouwd voor reproduceerbaarheid. Niet naderhand met scannen en audits, maar ingebakken in de manier waarop ontwikkelaars vanaf de eerste dag werken. Wanneer je ontwikkelomgeving identiek is op Mac en Linux, wanneer elke afhankelijkheid wordt bijgehouden en vergrendeld, wanneer je complete herkomst hebt voor elk artifact, worden AI-agents krachtwagens in plaats van chaosgeneratoren.

Hier is mijn grootste advies voor teams die proberen te slagen in de tijd van AI:

• Standaardiseer meedogenloos. Minder variabelen correleren met hogere prestaties. Vergrendel je technische stack, dwing consistente omgevingen af op alle platforms en elimineer configuratiedrift voordat AI het versterkt. Als Python-versiematches nu problemen veroorzaken, zullen ze 10 keer meer problemen veroorzaken wanneer AI code op grote schaal genereert.

• Bouw validatie in je workflow, niet aan het einde. Met AI die code sneller genereert dan mensen kunnen beoordelen, kun je niet alleen vertrouwen op handmatige codebeoordeling. Implementeer geautomatiseerde tests die niet alleen valideren of de code werkt, maar of het de echte vereiste oplost. Maak je CI/CD-pijplijn je veiligheidsnet, met sterke poorten bij de uitvoering voor productie-implementaties.

• Investeer in reproduceerbaarheid als infrastructuur. Behandel omgevingsconsistentie als een eerste klas infrastructuurprobleem. Wanneer je wiskundig kunt bewijzen dat je lokale omgeving, CI-omgeving en productieomgeving identiek zijn, elimineer je een hele klasse van “werkt op mijn machine”-problemen. Deze deterministische basis is wat het mogelijk maakt om probabilistische AI-workloads veilig te layeren.

De vraag is niet of AI de meeste van onze code zal schrijven. Het doet dat al voor veel teams. De vraag is of onze infrastructuur het kan bijhouden.