AI in software-ontwikkeling: kans, risico, en waarom we de controle houden
Ron Aarnink
AI is geen vervanger van de ontwikkelaar, vandaag in elk geval nog niet. het is een gereedschap.
Dat is het korte antwoord op de vraag die we steeds vaker krijgen: gebruiken jullie AI bij het ontwikkelen van software? Ja, volop. Maar niet zonder erover na te denken en dat verschil is het hele verhaal van deze blog.
Want AI heeft de manier waarop wij software bouwen veranderd. Werk dat vroeger uren kostte gaat nu in minuten. We omarmen die ontwikkeling, en zien hem elke maand verder gaan. Tegelijk leveren we sinds 2001 software op die niet morgen, maar over vijf of tien jaar nog moet werken. Software waar bedrijven hun bestelproces, hun productieplanning of hun klantadministratie aan toevertrouwen. En precies daar zien we dat de AI van vandaag nog niet zelfstandig kan leveren wat dat soort projecten vraagt.
Daarom houden wij als ontwikkelaars de regie. Hieronder leggen we uit hoe.
Wat AI goed kan
AI helpt ons sneller schrijven van standaardcode, sneller patronen herkennen in bestaande systemen, en sneller documentatie en testdata genereren. Werk dat tijd kostte zonder bijzonder denkwerk te vragen. Daar is AI uitstekend in, en daar zetten we hem volop in. Voor klanten betekent dat: scherper offreren, sneller leveren, meer tijd voor het denkwerk dat er werkelijk toe doet.
Waar het ingewikkelder wordt
Tussen wat AI oplevert en wat productieklaar is, zit nog een stap. Bij eenvoudige code een kleine, bij complexere systemen een grote. Wat we regelmatig zien:
Code die werkt op klein, maar niet op groot.
AI-tools zijn getraind op gemiddelde voorbeelden uit hun trainingsdata. Werkt prima voor een prototype met tien records. Maar zodra een systeem voor miljoenen records moet draaien, blijken aannames niet te kloppen. Een query die voor demo-data soepel werkt, kan in productie het hele systeem ophouden. Dat verschil zien we pas als je weet waar je op moet letten.
Code die werkt op klein, maar niet op groot.
AI-tools zijn getraind op gemiddelde voorbeelden uit hun trainingsdata. Werkt prima voor een prototype met tien records. Maar zodra een systeem voor miljoenen records moet draaien, blijken aannames niet te kloppen. Een query die voor demo-data soepel werkt, kan in productie het hele systeem ophouden. Dat verschil zien we pas als je weet waar je op moet letten.
Beveiliging die net te naïef is.
AI-code is vaak technisch correct, maar mist de context van wat veilig is. Klantgegevens die niet goed worden afgeschermd, error-meldingen die meer informatie naar buiten geven dan zou mogen, validatie die ontbreekt waar het nodig is. Niet altijd grote fouten, maar precies de subtiliteiten die later in een audit naar voren komen.
Code die nu werkt, maar later niet meer te onderhouden is.
Software is geen eindproduct. Hij wordt aangepast, uitgebreid, doorgegeven aan nieuwe collega’s. Code die door AI is geschreven kan technisch functioneren, maar zo zijn opgebouwd dat een ander team er over twee jaar moeilijk wijzigingen in krijgt. Combinaties van patronen die voor de AI logisch waren, maar voor een mens lastig te volgen.
Oplossingen voor de gevraagde, niet de bedoelde vraag.
AI bouwt wat hem wordt gevraagd. Wat hij niet doet, is meedenken over of dat wel het juiste is. Klanten omschrijven hun probleem in technische termen, terwijl het eigenlijke probleem ergens anders zit. Een mens die het bedrijf en het proces begrijpt, vraagt door. AI bouwt door.
In de blogs hieronder werken we deze onderwerpen verder uit, met concrete voorbeelden en wat we ertegen doen.
Wat dit van ons vraagt
Als je AI inzet en je wilt productieklaar werk, moet je het kunnen beoordelen. Beveiliging, externe pakketten, schaalbaarheid, onderhoudbaarheid, of de oplossing past bij wat de klant echt nodig heeft, dat zijn vragen die ervaring vragen om goed te beantwoorden.
Niet ervaring met AI. Ervaring met software bouwen. Met productie-systemen die op het scherpst van de snede draaien. Met code die we drie jaar later moesten aanpassen omdat het bedrijf was veranderd. Met klanten die belden omdat een library security-issues had. Met het zien van wat in de praktijk misgaat en dat hebben we sinds 2001 in alle hoeken van de softwarewereld gezien.
Dat is de laag die wij toevoegen. Niet als anti-AI-houding, maar als de erkenning dat productieklare software meer is dan code die werkt.
Hoe wij AI gebruiken
We zetten AI in waar hij sterk is. Snelheid, patronen, repetitief werk en houden de oordeelvorming bij onszelf. Iedere oplevering wordt door een ontwikkelaar bekeken. We controleren wat AI heeft geschreven, of we het zelf zo hadden geschreven, en of het past bij wat het project op de lange termijn nodig heeft.
Daarnaast houden we de regie over welke frameworks en technieken we gebruiken. Niet wat AI op dat moment toevallig voorstelt, maar wat past bij het project en wat wij, ook zonder AI, kunnen onderhouden en bijsturen. Dat klinkt vanzelfsprekend, maar het is precies waar het bij snelle AI-gedreven ontwikkeling soms misloopt: code die werkt, in een framework dat niemand in het team echt doorgrondt.
Bij ons zit AI naast de ontwikkelaar, niet in zijn plaats.
Inhoudsopgave
Dit is de introblog van een serie over AI in softwareontwikkeling. In de komende weken werken we de losse onderwerpen verder uit, over schaalbaarheid, externe pakketten, beveiliging en onderhoudbaarheid op de lange termijn. Houd deze blog in de gaten of volg ons op LinkedIn.
Benieuwd wat wij voor jou kunnen betekenen?
Een gesprek is zo gemaakt. We kijken samen naar waar je nu staat, waar het knelpunt zit, en of wij de juiste partij zijn. Ook als dat betekent dat we doorverwijzen. Neem gerust contact met ons op.