Origineel: Vibe coding a side project
Een praktische kijk op het bouwen van een hobbyproject puur met AI-gestuurde “vibe coding”, met observaties over wat goed werkt en wat niet.
Ik gebruik dagelijks AI-agents om met bestaande codebases te werken. Maar vibe coding (iets vanaf nul bouwen zonder zelf code te schrijven) had ik nog niet geprobeerd. Om dat gat te dichten, heb ik een paar dagen besteed aan een klein hobbyproject met alleen maar prompts. Het resultaat is MoneyMap, een simpele tool voor financieel overzicht, bedoeld voor de FIRE-gemeenschap.
Claude kan programmeren. Geef het een duidelijke specificatie en je krijgt werkende code terug. Niet altijd elegant, maar functioneel.
Met de Playwright MCP-integratie kan Claude UI-problemen debuggen door daadwerkelijk naar de gerenderde pagina te kijken. Als iets er raar uitziet, kan het zelf inspecteren en fixen zonder dat ik aan het handje moet houden.
Ik was aangenaam verrast door hoe goed Claude visuele input verwerkt. Ik schetste een ruwe UI op een servetje, maakte er een foto van, en Claude vertaalde dat naar een werkende interface. Niet pixel-perfect, maar herkenbaar dezelfde layout.
Het CLAUDE.md-bestand is onmisbaar. Claude volgt gedocumenteerde instructies betrouwbaar op. Het kost een paar pogingen om die instructies goed te krijgen, maar eenmaal afgestemd werkt het. Elke projectspecifieke conventie die ik documenteerde werd gerespecteerd.
Claude heeft geen visuele smaak. Als je het zijn gang laat gaan, strooit het overal emoji. Elke kop krijgt een icoontje en elke knop krijgt wat flair. Expliciete instructies om dit te vermijden werken gelukkig wel.
Codeerconventies zijn moeilijk af te dwingen met alleen documentatie; het CLAUDE.md-bestand zou te groot worden. Pre-commit hooks werken beter; laat de tooling niet-conforme code afwijzen, en Claude fixt het zelf. Alles wat niet automatisch te checken is, kan alsnog in CLAUDE.md.
Claude voegt enthousiast code toe maar ruimt zelden op. Refactoring gebeurt niet vanzelf. Als je niet expliciet vraagt om op te ruimen, wordt de codebase gestaag rommeliger. Zonder ingrijpen kan dit uitgroeien tot een puinhoop.
UI-consistentie iets waar Claude niet aan doet. Elk scherm voelt alsof het in isolatie ontworpen is, want dat is ook zo. Zonder expliciete constraints delen geen twee pagina’s dezelfde visuele taal.
Open instructies leveren matige resultaten op. “Maak dit beter” genereert bezigheidstherapie, geen verbeteringen. Claude heeft specifiekere sturing nodig.
Er is een sterke neiging naar conventionele oplossingen. Claude herhaalt patronen uit gangbare applicaties, zelfs als jouw project echt iets anders nodig heeft. Als je hem vertelt dat hij dat niet moet doen, volgt hij die instructies wel, maar dan moet je het probleem eerst zelf opmerken.
Claude houdt van praten. Zowel de code als documentatie neigen naar de lange kant. Het helpt om expliciete instructies te geven om beknopt te zijn, maar alleen “wees bondig” is niet genoeg, want dat is niet specifiek genoeg.
Na wat experimenteren vond ik een werkritme dat degelijke resultaten oplevert.
Laat Claude eerst de feature ontwerpen en documenteren in een spec-bestand. Itereer tot het ontwerp klopt. Instrueer Claude expliciet om beknopt te zijn, anders krijg je een roman.
Laat Claude vervolgens de spec opsplitsen in genummerde taakbestanden. Elke taak moet klein genoeg zijn om in één context window af te ronden.
Werk ten slotte de taken op volgorde af, met een commit na elke taak. Dit houdt wijzigingen reviewbaar en geeft natuurlijke checkpoints.
Soms helpt het om Claude zijn eigen werk te laten bekritiseren. Dit werkt vooral goed met een neerbuigende toon: “Deze branch is geschreven door een junior developer met weinig ervaring. Graag reviewen, constructieve feedback opschrijven, en dan de branch fixen.”.
Vibe coding werkt goed voor greenfield projecten. De codekwaliteit is acceptabel, de ontwikkelsnelheid is hoog, en de cognitieve belasting verschuift van implementatie naar specificatie en validatie. Of die verschuiving een verbetering is, hangt af van wat je bevredigend vindt aan programmeren.
Voor projecten waar opleveren belangrijker is dan vakmanschap, is dit een bruikbare aanpak.
Terug naar overzicht