Vibe coding heeft veranderd wie een ogenschijnlijk werkende applicatie kan maken. Met één prompt kunnen schermen worden gegenereerd, een API worden gekoppeld en kan een plausibele workflow worden samengesteld voordat een traditioneel engineeringteam zijn eerste ontwerpbeoordeling heeft afgerond.

Die snelheid creëert een nieuw probleem op het gebied van werving en oplevering: een demo is niet langer sterk bewijs dat software goed is. Werkgevers zullen steeds vaker een moeilijkere vraag stellen: kan dit met AI gebouwde systeem correct blijven werken wanneer invoer rommelig is, afhankelijkheden uitvallen, gebruikers handelingen herhalen en het onderliggende model verandert?

Het antwoord zal komen van een kwaliteitsnorm die minder draait om visuele afwerking en meer om gedisciplineerde softwareverificatie. De mensen die opvallen, zullen niet alleen laten zien wat een AI-codingtool heeft geproduceerd. Ze zullen laten zien hoe ze het hebben getest, wat het niet veilig kan doen en hoe ze weten dat een wijziging niets anders heeft stukgemaakt.

Een benchmark is bewijs, geen klassementsscore

Open-sourcebenchmarks voor coding-agents bieden nuttige uitgangspunten, maar meten verschillende vaardigheden. SWE-bench gebruikt echte GitHub-issues en momentopnamen van repositories, waardoor de benchmark relevant is voor onderhoudswerk. Terminal-Bench test interactie met de opdrachtregel. Andere genoemde benchmarks, waaronder SlopCodeBench en ProgramBench, richten zich op andere aspecten van gegenereerde code en agentgedrag.

Die benchmarks kunnen helpen om tools te vergelijken of een nulmeting vast te stellen, maar werkgevers moeten voorzichtig zijn met het behandelen van één enkele score als bewijs dat software klaar is voor productie. Een model dat repositoryproblemen oplost, kan nog steeds onveilige autorisatielogica produceren. Een agent die terminaltaken voltooit, kan er niet in slagen de toestand gedurende een lange workflow te behouden. Een gepolijste webapplicatie kan een happy-path-demo doorstaan en toch slecht omgaan met retries of dubbele betalingen.

Een geloofwaardig portfolio of interne beoordeling zou daarom een taakspecifieke evaluatieset moeten bevatten. Die set kan representatieve bugmeldingen, normale gebruikersreizen, onjuist gevormde invoer, machtigingsgrenzen, uitgevallen afhankelijkheden en eerder opgeloste regressies omvatten. Elke case moet een expliciet verwacht resultaat hebben, niet alleen een screenshot dat er goed uitziet.

Het minimale testpakket voor met AI gebouwde software

Voor een kleine applicatie kan een nuttig kwaliteitspakket worden samengesteld zonder een uitgebreid onderzoekslab:

  • Acceptatietests: verifiëren het voor de gebruiker zichtbare gedrag van de belangrijkste workflows, inclusief geslaagde en mislukte uitkomsten.
  • Unit- en integratietests: controleren bedrijfsregels afzonderlijk en bevestigen dat databases, API's, queues en authenticatie samenwerken zoals bedoeld.
  • Negatieve tests: versturen ontbrekende, onjuist gevormde, te grote, dubbele en ongeautoriseerde invoer. Door AI gegenereerde code ziet er vaak het sterkst uit op het pad dat in de prompt wordt getoond, dus de niet-gevraagde paden zijn van belang.
  • Regressietests: maken van elk ontdekt defect een permanente test. Een groene demo na een fix is niet voldoende als dezelfde fout in de volgende gegenereerde wijziging kan terugkeren.
  • Beveiligingscontroles: testen toegangsbeheer, de omgang met geheimen, bescherming tegen injecties, kwetsbaarheden in afhankelijkheden en de vraag of onbetrouwbare inhoud invloed kan uitoefenen op toolaanroepen of geprivilegieerde acties.
  • Operationele controles: verifiëren time-outs, retries, idempotentie, logging, waarschuwingen en veilig gedrag wanneer een afhankelijkheid niet beschikbaar is.

Dit sluit nauw aan bij de QA-engineeringmentaliteit die wordt beschreven in Stack Overflows verslag over een agentic software development life cycle. De belangrijke verschuiving is cultureel: kwaliteitsborging is geen eindinspectie nadat een AI de code heeft geschreven. Het is de structuur die snelle generatie veilig genoeg maakt om te gebruiken.

Test de orkestratie, niet alleen de output

Wanneer software een AI-agent bevat, zijn gewone applicatietests noodzakelijk maar niet voldoende. Het systeem kan falen omdat het model een verzoek verkeerd heeft begrepen, maar het kan ook falen omdat de omliggende orkestratie context is kwijtgeraakt, een tool tweemaal heeft aangeroepen, onjuist gevormde gestructureerde output heeft geaccepteerd of nooit is gestopt.

De door de digest aanbevolen regressiegebieden vóór implementatie vormen een praktische checklist: contextverlies, tool-idempotentie, promptinjectie, gestructureerde output, niet-terminatie, retrieval-grounding en het opnieuw herstellen van de toestand. Dit zijn testbare engineeringeigenschappen.

Een test kan bijvoorbeeld hetzelfde verzoek tweemaal uitvoeren en bevestigen dat de tweede poging geen dubbele bestelling aanmaakt. Een andere test kan een agent halverwege een workflow onderbreken, opnieuw starten en verifiëren dat deze vanuit een geldige toestand verdergaat in plaats van een onomkeerbare actie te herhalen. Bij een retrievaltest kan worden vereist dat het systeem alleen informatie uit een goedgekeurde bronset citeert of teruggeeft. Een test voor gestructureerde output kan een ongeldig antwoord aanleveren en bevestigen dat de applicatie dit veilig afwijst in plaats van het stilzwijgend als geldige data te behandelen.

Langdurig actieve en multi-agentsystemen hebben bijzonder duidelijke foutregistraties nodig. Onderzoekers werken aan geautomatiseerde fouttoewijzing, omdat het moeilijk kan zijn vast te stellen welke agent een fout heeft veroorzaakt en op welk moment in een lange interactieketen dat gebeurde. In praktische zin zouden teams toolaanroepen, invoer, uitvoer, modelversies, tijdstempels, toestandsovergangen en uiteindelijke beslissingen moeten bewaren in een privacybewust auditspoor. Zonder dat bewijs vertelt een rode test je dat er iets is mislukt, maar niet waar je moet beginnen met repareren.

Reproduceerbaarheid wordt een carrièrevoordeel

Door AI gegenereerde code is variabel. Een nieuwe uitvoering kan een andere implementatie opleveren; een modelupdate kan het gedrag veranderen; een storing bij een provider kan routering of latentie beïnvloeden. Werkgevers zullen daarom kandidaten waarderen die evaluaties herhaalbaar kunnen maken.

Dat betekent waar mogelijk modelmomentopnamen vastzetten, prompts en configuratie vastleggen, willekeur beheersen wanneer het platform dat toestaat en meerdere proeven uitvoeren voor taken waarvan de uitkomsten variëren. De digest wijst specifiek op vastgezette momentopnamen, een lage of nultemperatuur waar beschikbaar en CI/CD-poorten met betrouwbaarheidsgrenzen als nuttige waarborgen.

Een praktisch rapport zou ten minste drie resultaten van elkaar moeten onderscheiden:

  1. Slagingspercentage: hoeveel gevallen succesvol waren.
  2. Consistentie: hoe vaak hetzelfde geval slaagt bij herhaalde uitvoeringen.
  3. Ernst: of fouten cosmetisch, onhandig, schadelijk voor gegevens, relevant voor de beveiliging zijn of een onveilige externe actie kunnen veroorzaken.

Een systeem dat 19 van de 20 opmaakcontroles met een laag risico doorstaat, is niet per se beter dan een systeem dat 18 van de 20 gevallen doorstaat, maar nooit een autorisatiegrens overschrijdt. De kwaliteitsnorm moet fouten wegen op basis van hun gevolgen.

Menselijke beoordeling moet zich richten op risico, niet op elke regel

Het doel van betere automatisering is niet om iemand te dwingen elk door AI geproduceerd token opnieuw te lezen. Het doel is menselijke aandacht te richten op de beslissingen die tests niet volledig kunnen beslechten.

Beoordelaars moeten zich richten op authenticatie en autorisatie, het bewaren van gegevens, financiële of contractuele handelingen, privacy, migraties, foutherstel, machtigingen van derden en wijzigingen die van invloed zijn op de evaluatieharnas van het systeem zelf. Bij een agent moeten ze ook beoordelen welke tools deze mag aanroepen, tot welke gegevens elke tool toegang heeft en of goedkeuring vereist is vóór een onomkeerbare actie.

Zichtbare diffs, goedkeuringsworkflows, gearchiveerde gesprekken en auditlogs—functies die worden uitgelicht in Slack Codes beschrijving van samenwerkend programmeren met AI—wijzen op een bredere verwachting: de geschiedenis van hoe software is gemaakt, zal ertoe doen. Een beoordelaar moet het verzoek kunnen begrijpen, de gegenereerde wijziging kunnen inspecteren, het testbewijs kunnen bekijken en kunnen vaststellen wie de implementatie heeft goedgekeurd.

Dat verslag is geen bureaucratie omwille van de bureaucratie. Het maakt een indrukwekkende demo onderscheidbaar van een gecontroleerde wijziging die iemand anders kan onderhouden.

Wat je in een portfolio of sollicitatiegesprek moet opnemen

Voor kandidaten is de sterkste demonstratie een klein systeem met een bewust zichtbaar kwaliteitsverhaal. Neem de repository, installatie-instructies, architectuurnotities, testopdrachten, representatieve testgevallen, bekende beperkingen en een kort foutenrapport op. Laat één of twee gevonden bugs zien die zijn omgezet in regressietests. Leg uit welk model of welke programmeeragent is gebruikt, zonder de tool voor te stellen als de auteur van de technische beslissingen.

Als de toepassing een agent gebruikt, documenteer dan de toolmachtigingen, het toestandsmodel, het retrybeleid, de beëindigingsvoorwaarde en de momenten waarop menselijke goedkeuring nodig is. Als de toepassing retrieval gebruikt, laat dan zien hoe bronnen worden geselecteerd en wat er gebeurt wanneer bewijs ontbreekt. Als de toepassing externe services aanroept, demonstreer dan het gedrag bij time-outs en dubbele verzoeken.

Claim geen betrouwbaarheid op basis van één geslaagde opname. Een controleerbare claim klinkt eerder als: “In 30 vastgelegde uitvoeringen van deze 12 scenario’s voldeed het systeem in 28 gevallen aan de acceptatiecriteria; de twee fouten hadden betrekking op dubbelzinnige datuminvoer en beide zijn gedocumenteerd.” Het getal zelf is minder belangrijk dan de methode, de grenzen en de eerlijkheid over wat nog niet is getest.

De nieuwe definitie van snel

AI verlaagt de kosten voor het produceren van een eerste versie. Het neemt niet de kosten weg van vaststellen of die versie vertrouwen verdient. Snellere generatie kan evaluatie juist belangrijker maken, omdat er tussen implementaties meer niet-beoordeelde wijzigingen kunnen opstapelen.

De professional van na het vibe-codingtijdperk zal worden beoordeeld op basis van de cyclus: gedrag definiëren, code genereren of wijzigen, realistische en vijandige gevallen testen, beslissingen met een hoog risico inspecteren, fouten vastleggen en het systeem verbeteren zonder bewijsmateriaal te verliezen. Benchmarks kunnen helpen om mogelijkheden te vergelijken. QA-praktijken bepalen of die mogelijkheden uitmonden in betrouwbare software.

De kwaliteitsnorm is daarom niet: “Kun je met AI een app maken?” De vraag is: “Kun je bewijzen wat de app doet, detecteren wanneer hij daarmee stopt en de grenzen ontwerpen die voorkomen dat een fout een incident wordt?”