Is software gemaakt met AI-agents betrouwbaar?

Software gemaakt met AI-agents is betrouwbaar wanneer het proces eromheen streng is: duidelijke architectuurkaders, strikte typing, automatische tests, statische analyse en een mens die elke wijziging beoordeelt voordat er iets live gaat. De agent schrijft code, de ontwikkelaar bepaalt de architectuur en de kwaliteitslat. Zonder die lagen is agent-code onvoorspelbaar; met die lagen wordt de kwaliteit meetbaar.

Je wilt software laten bouwen, je hoort dat het met AI sneller kan, en tegelijk lees je over hallucinaties, verzonnen packages en code die niemand meer begrijpt. Terechte zorg. De oplossing is niet kiezen tussen "met AI" of "zonder AI", maar doorvragen op het proces: wie bepaalt de architectuur, wat controleert elke regel code, en wie tekent af. Ik bouw sinds 2024 AI-native vanuit de Rotterdam Science Tower, voor klanten via Webser en steeds meer aan eigen producten. Agents schrijven een groot deel van de code; ik bepaal het product, de architectuur en de lat. Hieronder staat hoe dat er in de praktijk uitziet, waar agents structureel de fout in gaan, en hoe je een AI-native bouwer doorvraagt.

Hoeveel van de code schrijven AI-agents echt, en wie bepaalt de rest?

Agents schrijven een groot deel van de regels code, maar vrijwel geen van de beslissingen. Dat onderscheid is de kern van betrouwbaarheid.

Waar de snelheidswinst zit:

• boilerplate en projectopzet
• CRUD-endpoints en formulieren
• databasemigraties
• tests uitschrijven op basis van beschreven gedrag
• grote maar mechanische refactors en renames
• documentatie en typedefinities

Wat mensenwerk blijft:

• domeinmodel en architectuur
• keuze van stack en dataschema
• autorisatieregels en beveiligingsgrenzen
• edge cases en foutafhandeling
• productbeslissingen en prioritering

De stack waarin dit gebeurt is bewust mainstream en strak: TypeScript, Next.js en React voor web, React Native met Expo voor mobiel, NestJS met PostgreSQL of Supabase in de backend, Payload of Drupal als CMS. Populaire, goed gedocumenteerde frameworks betekenen dat agents veel correcte voorbeelden hebben gezien. In mijn ervaring wordt agent-output merkbaar zwakker zodra je exotische of nauwelijks gedocumenteerde keuzes maakt.

Welke controlestappen horen er over door agents geschreven code heen?

Betrouwbare AI-native ontwikkeling stapelt controlelagen, zodat fouten vroeg en automatisch boven water komen in plaats van bij je gebruiker. Dit zijn de lagen die in een serieus proces thuishoren:

Strikte typing is de goedkoopste vangnetlaag die er is. Een agent die een niet-bestaande methode verzint of een veld verkeerd noemt, loopt vast bij het compileren. Daarnaast horen dependency-scanning en controle op secrets in de pipeline, omdat onveilige afhankelijkheden en gelekte sleutels een reëel risico zijn bij snel gegenereerde code.

De belangrijkste laag blijft de mens. Human-in-the-loop is geen formaliteit maar het moment waarop iemand met volledige context over het product beoordeelt of deze code bij het systeem past. Laat agents niet zelfstandig naar productie publiceren; dat is de breed gedeelde vuistregel en de reden dat ik zelf de kwaliteitslat bepaal.

Waar gaan AI-agents structureel de fout in?

Agents maken voorspelbare fouten, en juist die voorspelbaarheid maakt ze beheersbaar. Dit zijn de patronen die in de praktijk steeds terugkomen:

1. Verzonnen of verouderde API's en packages. Een agent noemt overtuigend een functie die twee majorversies geleden is verwijderd, of een package dat niet bestaat.
2. Duplicatie in plaats van hergebruik. Liever een nieuwe helper schrijven dan de bestaande vinden. Zonder review groeit je codebase met drie varianten van dezelfde functie.
3. Te brede permissies en zwakke autorisatie. Werkende code is niet hetzelfde als veilige code. Rechtencontroles worden vergeten of te ruim ingesteld.
4. Ontbrekende edge cases en foutafhandeling. Het gelukkige pad werkt. Leeg resultaat, netwerkfout, dubbele submit en verlopen sessie niet.
5. Tests die de eigen implementatie bevestigen in plaats van het gedrag. Groene tests die niets bewijzen zijn gevaarlijker dan geen tests.
6. Architectuurdrift over meerdere sessies. Elke sessie start met minder context. Naamgeving en patronen lopen uiteen als niemand ze vastlegt.

Daar komt foutenstapeling bij: een kleine misvatting vroeg in een keten werkt door in alles wat erna komt. De tegenmaatregel is simpel en effectief: kleine, afgebakende taken met expliciete acceptatiecriteria, en architectuurkaders die in de repository staan in plaats van in een chatgeschiedenis. Zodra een applicatie zelf met taalmodellen werkt, hoort prompt injection op de risicolijst: behandel modelinvoer als gebruikersinvoer.

Hoe blijven toegankelijkheid en performance overeind in AI-native code?

Toegankelijkheid wordt nooit automatisch goed. Agents produceren graag een div met een klikhandler waar een button hoort, en dat haalt geen enkele WCAG-toets.

Wat daarom expliciet gecontroleerd moet worden:

• semantische HTML en een correcte koppenstructuur
• toetsenbordnavigatie en focusbeheer, ook in modals en menu's
• contrastverhoudingen volgens WCAG
• ARIA alleen waar semantiek niet volstaat
• formulierlabels en foutmeldingen die een screenreader voorleest

Geautomatiseerde tools zoals axe en Lighthouse vangen een deel af. De rest vraagt handmatig testen met toetsenbord en screenreader, want tools zien geen onlogische focusvolgorde. Voor performance gelden dezelfde harde grenzen: Core Web Vitals, bundle size en querytijden meet je, die neem je niet aan. Kwaliteit, toegankelijkheid en snelheid zijn precies de drie dingen waar ik geen concessies aan doe, ongeacht wie of wat de code intypt.

Hoe controleer je als opdrachtgever of een AI-native bouwer betrouwbaar werkt?

Stel deze acht vragen. De antwoorden zeggen meer over betrouwbaarheid dan welk verhaal over AI dan ook.

1. Wie reviewt elke wijziging, en kan die persoon de architectuur uitleggen?
2. Welke checks draaien automatisch bij elke wijziging: typecheck, linting, unit-, integratie- en end-to-end tests?
3. Hoe wordt toegankelijkheid getest, automatisch én handmatig, en tegen welk WCAG-niveau?
4. Hoe wordt security gescand: dependencies, secrets, autorisatie?
5. Waar is de architectuur vastgelegd, zodat kennis niet in een chatsessie blijft hangen?
6. Wie is na oplevering eigenaar van de code en de repository? Leg dat schriftelijk vast.
7. Kan ik een draaiende preview-omgeving en de testrapportage zien voordat we live gaan?
8. Wat is de procedure bij een bug in productie, en hoe snel kan er teruggerold worden?

Een bouwer die op alle acht concreet antwoordt, werkt beheerst. Een bouwer die vooral over snelheid praat, verkoopt je risico. Wil je dit naast je eigen project leggen? Bekijk de werkwijze en stack van Senna Oudshoorn en vergelijk het met de antwoorden die je elders krijgt.

Is AI-native gebouwde software net zo onderhoudbaar op lange termijn?

Ja, mits een mens de architectuur begrijpt en kan uitleggen. Onderhoudbaarheid hangt niet af van de herkomst van de code, maar van consistentie, tests en documentatie.

Code die niemand kan uitleggen is het echte risico. Dat gold al voor overhaaste projecten zonder AI en het weegt nu zwaarder, omdat agents in uren kunnen produceren wat vroeger weken kostte. Daarom blijven architectuurkaders, naamgevingsconventies en een testsuite leidend. Het resultaat dat je wilt overnemen is een normale, leesbare TypeScript-codebase met tests, geen zwarte doos.

De conclusie: software gemaakt met AI-agents is betrouwbaar wanneer het proces streng is en een mens eindverantwoordelijk blijft. De agent versnelt, hij beslist niet. Zo ga je van idee naar productie in weken in plaats van maanden, zonder in te leveren op kwaliteit, toegankelijkheid of snelheid.

Volgende stap: loop de acht checklistvragen hierboven langs bij je huidige of toekomstige bouwer. Wil je weten hoe dat concreet uitpakt voor jouw applicatie, dan kun je AI-native software laten bouwen in Rotterdam en eerst het proces en de architectuur doorspreken voordat er één regel code wordt geschreven.