Veel discussies over AI Assisted Engineering beginnen bij codekwaliteit. AI-gegenereerde code zou rommelig zijn, slecht onderhoudbaar en ongeschikt voor productie. En eerlijk is eerlijk: dat beeld klopt vaak.
Wie verwacht dat een AI-model in één keer perfecte applicatiecode genereert voor een complexe codebase, inclusief alle randvoorwaarden, conventies en impliciete kennis, komt vrijwel altijd bedrogen uit.
Maar daar zit een belangrijke denkfout.
Niet omdat AI Assisted Engineering “toch goed genoeg” zou zijn, maar omdat de aansturing vaak niet klopt.
De context die we AI geven is te groot, te vaag of onvoldoende afgebakend, waardoor het model noodgedwongen gaat invullen, interpreteren en aannames doet.
Dat is geen tekortkoming van AI, maar van hoe we het gebruiken.
Het echte probleem: impliciete context
Grote codebases zitten vol impliciete kennis:
- architectuurkeuzes die ooit logisch waren;
- historische compromissen;
- afspraken die nooit zijn vastgelegd.
Voor mensen die er al jaren mee werken is die context vaak “vanzelfsprekend”.
Voor een AI-model is dat niet zo.
Geef je die context niet expliciet mee, dan ontstaat er code die technisch werkt, maar inhoudelijk schuurt. En hoe krachtiger het model, hoe overtuigender die output: en hoe lastiger het wordt om afwijkingen tijdig te herkennen.
Maar uit deze observatie volgt niet dat AI Assisted Engineering ongeschikt is voor serieuze softwareontwikkeling.
Het betekent vooral dat AI het slechtst presteert op plekken waar context diffuus, historisch gegroeid en impliciet is: en juist goed presteert waar verwachtingen expliciet, afgebakend en toetsbaar zijn.
Een goed voorbeeld daarvan is testen.
Software die meer kost dan oplevert
Veel organisaties vertrouwen op software om hun business te draaien, terwijl software niet hun kernproduct is.
Wat we daar vaak zien:
- systemen werken, maar voelen fragiel;
- veranderingen zijn traag en spannend;
- teams durven minder aan te passen dan nodig is;
- elke release voelt als een risico.
Dat is zelden een toolingprobleem. Het is een software-succesprobleem.
De onderliggende oorzaak is dat software nog te vaak wordt behandeld als iets dat “af” moet, in plaats van als een kapitaalgoed dat betrouwbaar moet blijven presteren, meebewegen en waarde moet blijven opleveren.
En dat zie je scherp terug in hoe we testen.
Een oude discussie in een nieuwe context
Meer dan tien jaar geleden schreef Kabisa al eens dat het schrijven van softwaretesten vooral geld kost.
Die uitspraak was bewust scherp. Niet omdat testen geen waarde hebben, maar omdat ze in de praktijk vaak zo voelen.
Testen:
- kosten tijd;
- leveren geen zichtbare functionaliteit op;
- zijn lastig te onderhouden.
Wat die discussie blootlegde, was geen gebrek aan tools of kennis, maar een structureel probleem.
Testen waren duur, fragiel en sterk afhankelijk van specialistische ervaring. Precies dat maakt deze discussie vandaag opnieuw relevant.
Wat zijn End-to-end tests?
End-to-end (E2E) tests controleren een volledige gebruikersflow van begin tot eind. Ze simuleren hoe een echte gebruiker met de applicatie werkt: openen, inloggen, navigeren, gegevens invoeren, opslaan en het resultaat terugzien. In plaats van losse onderdelen te testen, verifiëren E2E-tests dat alle lagen van het systeem (frontend, backend en database) correct samenwerken. Ze geven daarmee vertrouwen dat het systeem als geheel werkt zoals bedoeld.
Tests als vangnet, niet als bijzaak
Goede E2E-testen zijn geen middel om perfecte code af te dwingen. Ze zijn een veiligheidsnet.
Ze maken het mogelijk om:
- sneller te veranderen;
- fouten eerder te signaleren;
- suboptimale code gecontroleerd te verbeteren.
Zelfs als AI-gegenereerde code niet in één keer optimaal is, zorgen tests ervoor dat de impact beheersbaar blijft.
Zo wordt AI Assisted Engineering geen risicovergroter, maar juist een manier om risico’s te begrenzen.
AI Assisted Engineering als hefboom voor software die blijft renderen
Op deze manier ingezet gaat AI Assisted Engineering niet over AI die “even code schrijft”.
Het gaat over AI die helpt om goede software-principes vol te houden, juist wanneer druk en complexiteit toenemen. Het bouwen van betrouwbare end-to-end testen is daar een concreet voorbeeld van.
Niet als doel op zich, maar als fundament waarop software kan blijven presteren, evolueren en waarde opleveren.
En precies daarin zit de echte waarde:
software behandelen als kapitaal en AI inzetten om dat kapitaal te beschermen.
En nu?
Als dit herkenbaar klinkt, is de eerste stap zelden het herschrijven van je codebase.
Begin bij het fundament.
- Welke gebruikersflows zijn nu impliciet?
- Welke checks gebeuren nog handmatig?
- Waar zou meer zekerheid direct rust opleveren?
Breng dat scherp. Ga het gesprek aan met je team. Vaak is dat al genoeg om beweging te krijgen en software weer vóór je te laten werken in plaats van tegen je.
