Vibe coding werkt. Dat is juist het interessante

Een tijdje geleden was ik op zoek naar een todo-app. Niet omdat er een tekort aan todo-apps is. Integendeel. Alleen sloten de apps die ik probeerde niet helemaal aan bij hoe ik zelf wilde werken. Er waren SaaS-apps die behoorlijk dicht in de buurt kwamen, maar daar liep ik al snel tegen de grenzen van het gratis abonnement aan.

Toen kwam een gedachte bij me op die een paar jaar geleden nogal onzinnig zou zijn geweest: voor het bedrag van zo'n abonnement kan ik die applicatie misschien net zo goed door een coding agent laten bouwen.

Dat werd Priora (naam bedacht door AI)

Ik koos bewust voor een todo-app. Het is zo ongeveer het standaardproject waarmee beginnende programmeurs leren programmeren. De regels zijn overzichtelijk, het domein is begrijpelijk en als gebruiker kun je vrij gemakkelijk vaststellen of iets werkt. Tegelijk wilde ik toch al een todo-app die beter aansloot op mijn eigen manier van werken.

Het leek me daarmee een mooi project om iets uit te proberen wat ik professioneel juist niet doe: volledig vibe coden.

De afspraak die ik met mezelf maakte was eenvoudig. Ik zou sturen op wat de applicatie moest doen, testen of dat werkte en mijn bevindingen teruggeven aan de agent.

Maar ik zou de code niet bekijken.

Een experiment dat gewoon slaagde

Ik heb Priora gebouwd met Cursor en een high-end model. Mijn manier van prompting leek daarbij eigenlijk op hoe ik een opdracht aan een junior developer zou geven. Ik beschreef wat ik wilde bereiken en gaf voldoende context om ermee aan de slag te kunnen, zonder vooraf de technische oplossing voor te schrijven.

Helemaal los van mijn technische achtergrond lukt dat natuurlijk niet. Als je lang genoeg software ontwikkelt, beschrijf je sommige problemen automatisch anders. Bij een fout heb ik soms al een vermoeden waar het probleem ongeveer kan zitten. Bij een bepaalde functionaliteit weet ik dat er waarschijnlijk ergens een relatie of koppeltabel nodig zal zijn. Maar ik ging niet kijken of die er daadwerkelijk was.

De cyclus bleef steeds ongeveer hetzelfde: een feature beschrijven, de agent laten implementeren, Priora gebruiken, functioneel testen en de resultaten teruggeven aan de agent.

Dat heeft waarschijnlijk twaalf uur of meer gekost. Vibe coding betekent dus zeker niet dat je een paar zinnen intypt, koffie haalt en bij terugkomst een compleet product hebt. Ook wanneer een agent vrijwel alle code schrijft, blijft het bouwen van software werk.

Alleen was het resultaat in dit geval wel degelijk een bruikbare applicatie.

Priora heeft inmiddels een inbox, projecten, labels en prioriteiten. Er zijn een dagweergave en een upcoming-view. Achterstallige taken kan ik opnieuw inplannen. Taken kunnen verschillende statussen hebben, zoals OnHold en InProgress. Ik kan notities toevoegen en beschrijvingen zijn Markdown-first, inclusief highlighting en preview.

Er is ook een activities-view die als audit trail laat zien wat er met een taak is gebeurd. Zelfs een verwijderde taak kan ik daar weer terughalen. En uiteraard zit er authenticatie in.

Het belangrijkste is alleen niet de lengte van die lijst. Ik gebruik Priora dagelijks. Voor het doel waarvoor ik hem gebouwd heb, werkt de applicatie.

Geen idee hoe hij gebouwd is

Daar zit meteen het vreemde aan dit experiment.

Ik ben softwareontwikkelaar, ik gebruik dagelijks een applicatie die ik zelf heb laten bouwen, maar ik weet niet hoe die applicatie intern in elkaar zit.

Ik weet niet hoe de database-mappings zijn ingericht. Ik weet niet of de applicatie volgens vertical slices is opgebouwd, DDD probeert te volgen, vooral uit services bestaat of uiteindelijk gewoon een verzameling classes in één project is geworden. Ik weet niet hoe verantwoordelijkheden verdeeld zijn en welke technische schuld tijdens die twaalf uur is ontstaan.

Ik ben daar wel nieuwsgierig naar geweest. Vooral omdat dit precies de dingen zijn waar ik normaal gesproken automatisch naar kijk. Maar dat niet doen was onderdeel van het experiment. Als ik bij iedere interessante keuze alsnog de solution zou openen om te controleren wat de agent had gedaan, was ik iets anders aan het testen.

Dus deed ik dat niet.

Ook als er iets fout ging, bleef ik aan de buitenkant. Ik opende geen logs en ging niet door de code om de oorzaak te vinden. Ik beschreef het probleem dat ik zag en gaf dat terug aan de agent.

Mijn ervaring als developer verdween daardoor niet. Die beïnvloedde mijn opdrachten en hielp me om problemen te herkennen en nauwkeuriger te beschrijven. Maar ik gebruikte die ervaring niet om de implementatie te controleren.

Ik valideerde het product. Niet de softwarearchitectuur erachter.

CalDAV zonder CalDAV te bouwen

Een van de interessantere features van Priora is de CalDAV-integratie.

Ik wilde graag gebruikmaken van functies die al op mijn telefoon aanwezig zijn, zoals betrouwbare on-device notificaties, en offline editing zonder daarvoor ook nog een eigen native app te moeten bouwen. CalDAV is een standaard, waardoor ik priora aan bestaand apps kan koppelen en die later relatief eenvoudig kan wisselen.

Mijn opdracht aan de agent was ongeveer: voeg CalDAV-support toe. Voor ieder project wilde ik in ieder geval een lijst, met ondersteuning voor labels, titels, omschrijvingen en de todo/done-status. Daarnaast wilde ik onder andere prioriteiten en terugkerende taken behouden.

De agent bouwde het.

Ik koppelde Priora vervolgens aan iOS Herinneringen en testte of het werkte.

Het werkte.

En daarmee is CalDAV voor mij op dit moment ongeveer een black box.

Ik weet niet welke libraries ervoor gebruikt worden. Ik weet niet hoe de synchronisatiestatus wordt bijgehouden of hoe de implementatie precies omgaat met conflicten. Ik heb de interne mappings niet bekeken. Ik weet niet wat er gebeurt als een synchronisatie halverwege mislukt.

Voor mijn huidige gebruik heb ik die kennis ook niet nodig gehad.

Dat is misschien wel het sterkste argument vóór vibe coding: je kunt tegenwoordig software bouwen en gebruiken zonder dat je hoeft te begrijpen hoe ieder onderdeel technisch gerealiseerd is.

Tegelijk is dat precies waar voor mij de grens met professionele software ligt.

Geef ik deze applicatie morgen aan honderd klanten?

Nee.

Niet in de huidige vorm.

Dat antwoord heeft opvallend weinig te maken met de vraag of Priora goed werkt. Ik gebruik hem dagelijks. Daardoor heb ik inmiddels behoorlijk wat vertrouwen in het functionele gedrag voor mijn eigen use-case en voor één gebruiker.

Maar stel dat morgen honderd mensen Priora gaan gebruiken en mij betalen om hun taken erin op te slaan.

Dan is functioneel testen alleen volstrekt onvoldoende.

Ik wil dan weten hoe data wordt opgeslagen en gewijzigd. Ik wil weten wat er gebeurt als een operatie halverwege faalt. Ik wil begrijpen hoe de relaties in het datamodel zijn opgebouwd en wat een wijziging daarin betekent voor bestaande data. Ik wil weten of filtering door de database gebeurt of dat ergens complete datasets in memory worden geladen. Ik wil weten wat er onder load gebeurt en welke onderdelen als eerste problemen gaan geven.

En vooral: als het misgaat, wil ik niet voor het eerst kennismaken met mijn eigen implementatie terwijl ik een incident probeer op te lossen.

Bij een todo-app is dat niet eens een theoretisch risico. Mensen zetten taken in zo'n systeem zodat ze die zelf niet meer hoeven te onthouden. Als de applicatie een taak kwijtraakt, is het helemaal niet vanzelfsprekend dat de gebruiker weet wat er verdwenen is. Het feit dat de informatie extern is opgeslagen, is juist de reden dat die informatie niet meer in iemands hoofd hoeft te zitten.

Dat verandert de verantwoordelijkheid.

Voor mijn eigen installatie accepteer ik een heel ander risicoprofiel. Priora draait lokaal. Ik heb backups die ik kan terugzetten. Mocht ik ooit weg willen bij de huidige implementatie, dan kan ik de agent desnoods vragen alle gegevens naar Markdown te exporteren zodat ik ze ergens anders weer kan importeren. Als dat mislukt, heb ik vooral zelf een probleem. Met gegevens van klanten vind ik dat geen acceptabele manier van werken.

Voor professionele software is dit onaanvaardbaar

Daarom zou ik de manier waarop ik Priora heb gebouwd nooit één op één toepassen op professionele software waarvoor ik verantwoordelijk ben.

Niet omdat een coding agent de code heeft geschreven.

Dat onderscheid vind ik belangrijk. Ik heb er weinig principiële moeite mee als een agent uiteindelijk negentig of zelfs honderd procent van de regels code genereert. Zelf de toetsen op het toetsenbord indrukken geeft geen garantie op goede software, net zoals gegenereerde code niet automatisch slechte software is.

Het probleem met mijn Priora-experiment is dat ik bewust geen technisch begrip van de uiteindelijke implementatie heb opgebouwd.

Ik kan vertellen wat de applicatie doet. Ik kan demonstreren dat CalDAV synchroniseert. Ik kan een taak verwijderen en via de activities-view weer terughalen. Ik kan dagelijks met de applicatie werken en daarmee een behoorlijke hoeveelheid functionele validatie verzamelen.

Maar als je me vraagt waarom de implementatie betrouwbaar is, waar de belangrijkste technische risico's zitten of wat er gebeurt wanneer het systeem onder andere omstandigheden draait, moet ik op dit moment het antwoord schuldig blijven.

Voor een persoonlijk experiment vind ik dat prima.

Voor professionele software vind ik dat onaanvaardbaar.

Als ik verantwoordelijkheid neem voor een systeem, moet ik voldoende van dat systeem begrijpen om technische keuzes te kunnen beoordelen, risico's te herkennen, wijzigingen verantwoord door te voeren en problemen op te lossen wanneer ze zich voordoen. Zeker wanneer andere mensen afhankelijk zijn van de beschikbaarheid en integriteit van hun gegevens.

Priora heeft me daardoor niet geleerd dat vibe coding niet werkt.

Eerder het tegenovergestelde.

De applicatie werkt verrassend goed. Ik gebruik hem daadwerkelijk en ik heb functionaliteit gekregen waar ik anders waarschijnlijk aanzienlijk meer tijd aan kwijt was geweest. Juist daardoor werd voor mij duidelijker waar het verschil zit tussen vibe coding en professioneel ontwikkelen met agents.

Het verschil is niet wie de code heeft getypt. Het verschil is hoeveel verantwoordelijkheid je kunt nemen voor wat er uiteindelijk staat.

Als een agent straks vrijwel alle implementatie voor zijn rekening kan nemen, hoe zorg je er als developer dan voor dat je de software nog steeds goed genoeg begrijpt om er professioneel verantwoordelijkheid voor te dragen?