In februari maakte ik mijn eerste vibe-coded applicatie. En dan bedoel ik de definitie van vibe-coding zoals beschreven in het originele epistel van Andrej Karpathy: een applicatie waarbij je echt doet alsof de code niet bestaat en dit volledig overlaat aan de LLM. In dit artikel schrijf ik over hoe dit is verlopen, en of het betekent dat ik nu ook verlopen ben als developer.
Het doel
Trouwe lezers van dit blog zijn inmiddels wel bekend met onze afbeeldingen. Bijvoorbeeld:
Een normale dag op kantoor
Ik merkte dat het genereren van deze afbeeldingen best een hoop tijd begon te kosten. Ik had daar namelijk een uitgeschreven standaardprompt voor, die daarna per afbeelding aangepast moest worden. De gebruikte karakters moesten ook stuk voor stuk worden ge-drag-en-dropt. Wanneer ik verschillende variaties wilde hebben, of tussen verschillende image-generators wisselde, moest ik iedere keer deze stappen herhalen.
Ik stoorde me hier al een tijdje aan, en merkte dat ik deze taak begon uit te stellen, omdat ik wist hoeveel werk het zou worden.
Dit is een taak waarvan grote delen eenvoudig geautomatiseerd kunnen worden (daar zijn we bij Webenable immers erg goed in), maar het zat eigenlijk precies op de grens van wel of niet de moeite waard om dit te gaan bouwen. Er is immers altijd dringender werk, en zo'n proces als dit is bovendien vrij veranderlijk; je wilt het dus niet te vroeg gaan 'vastleggen', omdat je anders het verkeerde bouwt.
Het was nu tijd om dat tóch te gaan doen. Bovendien was ik ook benieuwd hoe ver ik zou komen, puur met vibe-coding. Want de scope van dit project was hier klein genoeg voor, en daarom goed geschikt.
Als je dit ervaart, is het tijd om te gaan automatiseren.
Vibe coding
Ik besloot dat ik een Electron-app hiervoor wou hebben. Ik heb menig desktop-app gebouwd, in veel verschillende technologieën, maar nog nooit een Electron-app. Dat komt goed uit, want dan ben ik minder snel geneigd om er zelf in te duiken. Maar het is ook riskant, want soms kun je niet anders. Toch?
Het proces verliep redelijk soepel. Ik had al een aardig beeld van wat ik wilde hebben, en maakte op basis daarvan de specificaties, waarbij ik het implementatieproces opdeelde per scherm. Deze specificaties verfijnde ik daarna door Codex (via de CLI, gpt-5.3-codex) vragen erover te laten stellen, totdat deze helemaal uitgewerkt waren. Het resultaat was een plan, dat Codex daarna uit kon gaan voeren.
Dit proces herhaalden we een aantal keer, en voor ik het wist was er een mooie en werkende Electron-applicatie opgetuigd!
Nog steeds een normale dag op kantoor
Pijnpunten
Het bouwen verliep bijna vlekkeloos. Toch waren er twee knelpunten waarop ik mijn eigen ervaring moest inzetten.
Drag and drop
Het drag-en-droppen van referentieafbeeldingen werkte maar niet. Ik liet Codex tot vijf keer toe zelf een
poging doen (waarbij hij iedere keer direct weer, vol zelfvertrouwen, de verkeerde conclusie trok,
net als Claude dat vaak doet).
Toen ik hier wat gerichtere instructies gaf, over hoe we dit moesten debuggen, kregen we het probleem uiteindelijk wel opgelost.
Bouwen voor Windows
Ik werk graag op Linux, maar ontkom niet altijd aan Windows. En mijn collega's natuurlijk ook niet.
Mede hierom dus ook mijn keuze voor Electron: hiermee ondersteun je vrij eenvoudig meerdere
besturingssystemen. Toch was het bouwen voor Windows lastig. Er gingen meerdere dingen fout, waarbij
Codex dan met een lijst van oplossingen kwam, die vaak niet de juiste waren (vergelijkbaar met
Claude die vertelde dat ik OpenJDK moest installeren).
Ik ben het daarna zelf gaan uitzoeken en kwam met een andere, betere mogelijkheid (die Codex daarna wel succesvol kon uitvoeren). Met puur vibe-coding was dit toch niet helemaal gelukt. Mijn technische kennis en aanpak bleken dus toch nog wel nodig.
De applicatie
Ik heb de applicatie nu al enkele weken in gebruik en heb er al veel profijt van. Het proces rondom het maken van afbeeldingen is veel sneller geworden en de kwaliteit is verbeterd. Het is dus heel herkenbaar en vergelijkbaar met de projecten die wij voor onze klanten uitvoeren, maar dan in het klein.
In het configuratiescherm is het mogelijk om je karakters te selecteren, en ook nog per karakter in te voeren wat-ie moet zeggen. Eén van mijn irritaties was dat het lastig was om snel meerdere afbeeldingen te genereren, maar deze applicatie is zo ontworpen dat je zelf kunt opgeven hoeveel afbeeldingen gemaakt mogen worden (en met welk model). Als een afbeelding niet bevalt, kun je deze opnieuw laten produceren. Alles is nu zoveel sneller en gestroomlijnder.
Tijdens het bouwen kom je uiteraard op veel nieuwe ideeën. Zo wilde ik graag zien welke kosten er kwamen kijken bij het genereren van deze afbeeldingen. Bij de vorige aanpak was het genereren van afbeeldingen 'gratis' omdat het in onze abonnementen zat. Maar nu we dit met de API doen, gaat het meer geld kosten. Toch is dat het meer dan waard, dankzij de tijdwinst die het oplevert.
Het is nu heel eenvoudig om meerdere opties te vergelijken
Conclusie
Mijn vibe-coding experiment was een succes. Maar zou ik vanaf nu op deze manier software durven maken, waarbij ik niet meer naar de code kijk, en het resultaat aan onze klanten verkopen?
Absoluut niet.
Professionele software is vrijwel altijd vele malen complexer dan dit. Bovendien moet deze een stuk gebruiksvriendelijker en fouttoleranter worden gemaakt (want software is over het algemeen meer uitzondering dan regel). Maar zelfs bij een project van deze schaal, zou ik het alsnog niet aandurven om dit te vibe-coden.
Waarom niet? Omdat ik de code van dit project niet bekeken heb. Ik durf dus niet met zekerheid te zeggen dat hier geen kwetsbaarheid in zit. Dit is de laatste tijd, zeker met alle NPM malware, relevanter dan ooit. Om deze applicatie te gebruiken moet je je API-keys bij de settings invoeren. Wie zegt dat er dan er niet (per ongeluk, of wellicht zelfs opzettelijk) door de LLM wat code is geschreven die deze API-keys doorstuurt naar kwaadwillende partijen? En wie garandeert dat deze applicatie niet lekker gaat zitten cryptominen?
Wij houden daar natuurlijk intern wel rekening mee. De API-keys die we gebruiken hebben strikte limieten op de tegoeden, en de applicatie draait bijvoorbeeld niet als rootgebruiker. Maar, ik zou dit project niet eens durven te open-sourcen: want wie zegt er dat de LLM, tijdens het bouwen hiervan, niet wat gevoelige data in de code heeft gezet? We leven in een wereld waarin security alleen maar belangrijker wordt, en dat nemen we heel serieus.
Toch heeft vibe-coding wel zijn plaats, zeker wanneer je dus rekening houdt met bovenstaande.
Maar, wat als het stuk gaat? Je hebt de code niet zelf geschreven, het is wellicht zelfs in een taal geprogrammeerd die je niet beheerst, of misschien ben je niet eens een developer. Is vibe-coding dan wel zo'n goed idee? Hierover ga ik wat schrijven in het volgende artikel.
