Uw leverancier bouwt met AI

Analyses van AI-gegenereerde code laten al een jaar hetzelfde beeld zien. Er zitten ruwweg anderhalf tot twee keer zoveel grote problemen in als in met de hand geschreven code, en aanzienlijk meer beveiligingsfouten. Metingen op applicaties die grotendeels met AI zijn gebouwd, komen uit op meer dan de helft die met een kritieke kwetsbaarheid live gaat.

Nog veelzeggender dan die cijfers is een verandering in de verhouding tussen geplakte en herschreven code. Sinds AI-gereedschap gewoon werd, groeit het geplakte deel harder. Dat betekent dat dezelfde logica op meerdere plekken terechtkomt, met kleine verschillen ertussen.

Dat is precies wat u verwacht van gereedschap dat optimaliseert voor werkende code in plaats van voor onderhoudbare code. Elke losse oplossing klopt; het geheel heeft geen vorm.

Het zou onzuiver zijn om alleen de nadelen te noemen. De doorlooptijd tot iets werkends is met AI-gereedschap merkbaar korter geworden, en dat is geen marketingclaim maar iets wat opdrachtgevers in hun eigen projecten terugzien.

Voor u betekent dat vooral: eerder kunnen bijsturen. Een eerste werkende versie die er in weken is in plaats van maanden, geeft u de kans om te ontdekken dat u iets anders wilde, op een moment dat veranderen nog goedkoop is.

Het is dus geen ruil tussen snelheid en kwaliteit, maar tussen snelheid en de hoeveelheid controle die u erop zet. Wie de snelheid neemt en de controle overslaat, betaalt dat terug in onderhoud. Wie allebei doet, houdt het voordeel.

In de oplevering merkt u hier niets van. De software doet wat er is afgesproken, de demonstratie gaat goed, de acceptatietest slaagt. Het verschil zit in wat er daarna gebeurt.

U merkt het aan de tijd die een wijziging kost. Een aanpassing die klein lijkt, blijkt drie plekken te raken. U merkt het aan fouten die terugkomen: opgelost op de plek waar ze opdoken, en drie weken later weer, ergens anders.

En u merkt het op het moment dat er iemand anders naar moet kijken. Bij een leverancierswissel, bij het vertrek van de ontwikkelaar die het bouwde, of bij een audit. Dat is meestal het duurste moment om erachter te komen.

• Dat de leverancier meldt dat en waar hij AI gebruikt bij het bouwen — niet om het te verbieden, maar om te weten wat u koopt.
• Dat er geautomatiseerde tests worden opgeleverd bij de code, en welke dekking daarbij hoort.
• Dat er statische analyse en een beveiligingscontrole over de code gaat vóór oplevering, met de uitkomst als bijlage.
• Dat de code voldoet aan een vastgelegde stijl, zodat een ander hem kan lezen.
• Dat er documentatie meekomt over de opzet, niet alleen over het gebruik.

Vraag om de uitkomst van de kwaliteits- en beveiligingscontrole, niet om de belofte dat die is gedaan. Een rapport met openstaande punten en een plan is een beter teken dan een rapport zonder bevindingen.

Vraag of iemand die niet aan het project heeft gewerkt de code heeft gelezen. Dat is een lage drempel die veel afvangt: wat een tweede persoon niet begrijpt, gaat u over twee jaar geld kosten.

En vraag naar de tests. Niet hoeveel het er zijn, maar welk deel van het systeem ze afdekken. Vooral rond inloggen, rechten en betalingen wilt u dat er tests staan, want dat zijn de plekken waar een fout uw klanten raakt in plaats van uw planning.

Vraag om een demonstratie van wat er misgaat, niet alleen van wat er goed gaat. Wat doet het systeem bij een onvolledig ingevuld formulier, bij een gebruiker zonder rechten, bij een bestand van honderd megabyte, bij twee mensen die tegelijk hetzelfde wijzigen?

Dat zijn de gevallen waar snel gebouwde software struikelt, en het zijn precies de gevallen die in een verkoopdemonstratie niet voorkomen. Een halve dag hieraan besteden bij de oplevering levert meer op dan drie weken functioneel testen.

Noteer wat u ziet en wat er is toegezegd. Bij software die met AI is gebouwd, is de kans groot dat een van deze gevallen na de eerstvolgende wijziging weer stukgaat — en dan wilt u kunnen terugverwijzen naar wat er is afgesproken.

Reken erop dat het onderhoud van software die snel is gebouwd, in de eerste jaren hoger uitvalt dan bij software die trager tot stand kwam. Dat is niet oneerlijk; het is de rekening van de snelheid waarmee u iets werkend had.

Wat u wilt voorkomen is dat die rekening als meerwerk binnenkomt. Leg daarom vast wat er onder onderhoud valt: het oplossen van gebreken, het bijwerken van componenten met bekende kwetsbaarheden, en het opruimen dat nodig is om verder te kunnen bouwen.

Dat laatste is het punt waar de meeste discussie ontstaat. Een leverancier ziet opruimen als een aparte opdracht; u ziet het als onderdeel van goed onderhoud. Dat gesprek voert u beter bij het tekenen dan bij de eerste factuur.

De discussie die na een oplevering het vaakst terugkomt, gaat over de grens tussen onderhoud en meerwerk. Voor software die snel is gebouwd, is die grens extra belangrijk, omdat er meer werk zit in het op orde houden dan in het uitbreiden.

Wat er wat ons betreft onder onderhoud hoort: het oplossen van gebreken, het bijwerken van componenten met bekende kwetsbaarheden, aanpassingen die voortvloeien uit gewijzigde wetgeving, en het opruimen dat nodig is om verder te kunnen bouwen.

Dat laatste is het punt waar het wringt. Een leverancier ziet opruimen als een aparte opdracht; u ziet het als de prijs van goed onderhoud. Dat gesprek voert u beter bij het tekenen dan bij de eerste factuur, en het is met één zin in het contract op te lossen.

• De doorlooptijd tot iets werkends is korter, waardoor u eerder kunt bijsturen.
• Kleine aanpassingen die vroeger niet uit konden, zijn nu wel de moeite waard.
• Documentatie en tests achteraf toevoegen gaat met hetzelfde gereedschap sneller dan vroeger.
• Een tweede leverancier die de code overneemt, komt er sneller in als de stijl consistent is — en AI-code is dat vaak.

Bij alles waar geld of persoonsgegevens langsgaan. Inloggen, rechten, betalingen, koppelingen naar buiten. Daar weegt een externe controle op tegen de kosten, ook bij een kleine opdracht.

Bij software die u langer dan drie jaar wilt gebruiken. Wat u nu bespaart aan controle, betaalt u later terug in onderhoud, en dat verschil groeit met de looptijd.

En bij een leverancier met wie u voor het eerst werkt. Niet uit wantrouwen, maar omdat u geen beeld heeft van wat hij normaal aflevert. Eén onafhankelijke blik bij de eerste oplevering vertelt u meer dan drie referentiegesprekken.

• AI-gegenereerde code van uw leverancier
• Wat hoort in een SLA?
• Het onderhoudscontract

Wilt u eerst weten of het idee werkt voordat u groot investeert? Bij OneDayBuild laat u in één dag een werkend prototype bouwen.