Wij meten softwareontwikkelprojecten door voor onze klanten. Ze huren ons in om de technische kwaliteit van hun softwaresystemen te beoordelen. We zien dus veel projecten in veel verschillende omgevingen. En natuurlijk wordt overal lustig geëxperimenteerd met AI, en vaak ook agentic AI.
Hier zijn drie waarnemingen die mij de laatste tijd opvallen.
1: De rol van de software engineer verandert stevig.
Op het moment dat een software engineer agentic AI toepast, verandert zijn/haar taak enorm. In plaats van zélf te analyseren hoe de bestaande code in elkaar zit, en te bedenken waar en hoe aanpassingen in de code gemaakt moeten worden, wordt dat aan de AI-agent overgelaten. Elke agent functioneert feitelijk als een op afroep beschikbare (braaf wachtende) virtuele medewerker. Afhankelijk van het beschikbare tokenbudget kan dat zelfs een klein legertje virtuele medewerkers worden.
De rol van de engineer verandert daarmee van analist/bouwer naar teambaas. En als je dus een team van bijvoorbeeld 5 software engineers hebt, heb je in de AI-era 5 teambazen die zelf geen software meer bouwen, maar allemaal software laten bouwen door hun virtuele teams.
Dat roept vragen op. Hoe merge ik al die code in mijn bestaande productiecode? Hoe ga ik al die code testen? Verleren mijn software engineers het programmeren niet? Hoe harmoniseren we codeerstijlen? Hoe garanderen we een begrijpelijke softwarearchitectuur?
2: Architectuurissues
Als meer virtuele medewerkers (AI-agents) in korte tijd meer code maken, dan is de kans op architecturale wildgroei groot. Dat zit zo. De AI-agents schrijven over het algemeen weliswaar heel mooie en goede code, maar trekken zich niet zo veel aan van waar die code dan gaat "landen". Dus de kans op wildgroei is groot.
Wat voorbeelden: er is meer duplicatie van code in AI-gegenereerde systemen. We zien geregeld mooie stukken code die nooit in productie zijn gegaan, omdat ze niet te mergen waren met de bestaande codebase. Soms wordt AI-gegenereerde code zelfs buiten de bestaande architectuur geplaatst.
En dat leidt dan weer tot moeilijk te analyseren systemen. AI-agents zijn krachtig, maar kunnen dus ook versneld technische schuld opleveren.
Zo leidt kortetermijnproductiviteitswinst mogelijk tot een onderhoudbaarheidsprobleem op de lange termijn.
3: AI-agents luisteren niet altijd naar de baas
Dat AI kan hallucineren weten we inmiddels allemaal wel, maar wij zien ook steeds vaker dat AI-modellen zich niet aan de instructies houden.
Dat kan onschuldig zijn, bijvoorbeeld als een model de instructie negeert: "maak niet te lange codestatements" of "gebruik niet te veel parameters", want dat schaadt enkel de onderhoudbaarheid.
Maar wat als je AI-agent ongewenst technologie van derden naar binnen sleept? IP- en securityrisico's liggen dan op de loer.
Dat is geen denkbeeldig risico. Het gebeurt in de praktijk.
Wat leren we hiervan?
Onze visie is eenvoudig. AI in software development is supernuttig. Je kunt je niet veroorloven er níet mee te experimenteren.
Maar experimenteren betekent niet klakkeloos in productie zetten. Ons advies:
- Blijf experimenteren.
- Intensiveer het analyseren van wat er gebeurt op code- en architectuurniveau (door daadwerkelijk de code te analyseren).
- Bepaal wat navolging verdient, wat misschien een minder goed idee is en waar risico's optreden.
- Richt de organisatie daarop in (onder andere door guardrails vast te stellen).
Wat zijn úw praktijklessen bij de uitrol van agentic AI in software development?
