Dit is hoe ik me voel over vibe coding. Elk project dat ik probeer en dat enige complicatie heeft, heeft deze onmiddellijke uitbarsting van vooruitgang. Dingen zijn geweldig en het voelt als een superkracht. Dan... als ik meer complexiteit toevoeg, komt alles tot stilstand. De enige projecten waarvan ik denk dat ik ze kan creëren, zijn diegene die in deze "vibe zone" vallen. Prototypes, UI's, producten—alles wat eenvoudig is en een lage complexiteit heeft, past precies in die zone. Bewijzen van concepten, interacties, dat soort dingen. De tools kunnen dingen maken die in die ruimte passen. Maar. Alles valt uit elkaar naarmate die complexiteitscurve toeneemt. En het probleem is dat elk goed productontwerpproces toenemende complexiteit heeft. Een basisprototype verandert in een goed prototype zodra het gelaagde interacties, overgangen, goede affordances, hover-staten, 1000 kleine details heeft die iets goed en echt laten aanvoelen. Het voordeel van vibe coding zou moeten zijn dat je snel beweegt en dingen kunt maken—AI het werk voor je laat doen. Het probleem is dat het aan kracht verliest zodra de noodzakelijke complexiteit wordt toegevoegd. Het blijft zichzelf opnieuw doen, herschrijft code, beïnvloedt dingen die niet gerelateerd zijn en veroorzaakt dan andere problemen. Maar als je die complexiteit toevoegt, verandert elke vibe coding-sessie snel in een whack-a-mole bug-bashing sessie. Ik weet niet zeker wat de oplossing hiervoor is. Bij traditioneel prototyping is de oplossing om te dupliceren, meer complexiteit toe te voegen, meer frames/scènes te creëren, te tweaken, te fork'en, enz. Echter, met vibe coding kan één kleine prompt letterlijk alles vernietigen. Er is een fase waarin ik eindig met het lopen op prompt-eierschalen—proberend niet te veel of te weinig context te geven zodat het niet op hol slaat en alles breekt. Er zijn maar een paar uitzonderingen op dit. @cursor en @framer. Ik kan geweldige vooruitgang boeken met Cursor, het een smalle context geven, en ik moet de bewerkingen die het maakt goedkeuren. Dit voelt als een correcte workflow. Het probleem is, ik kan het ding dat het maakt niet zien omdat het een IDE is, geen visuele omgeving. Ja, ik kan lokale builds maken en mijn browser verversen en al dat soort dingen. Maar het visuele aspect is totaal verloren gegaan in de coding ervaring. Het is een ontwikkelaarstool. Framer doet dit goed omdat het alleen smalle updates binnen een enkele component op de pagina toestaat. Ja, het is beperkend omdat het maar één ding tegelijk kan doen, maar tenminste probeert het niet de hele pagina vanaf nul te creëren en alles te beheren via een promptinterface. Dit lijkt de juiste aanpak. @Cursor: Laat de AI alles bewerken, maar laat de gebruiker die bewerkingen goedkeuren en ze in context zien. @Framer: Laat de AI alleen smal een enkel bestand of component bewerken om de complexiteit tot een minimum te beperken en catastrofale bewerkingen te verminderen. Ik ben optimistisch dat tools zoals @Figma, @Lovable, @Bolt, en @V0 coole prototypes kunnen maken, maar ik blijf tegen muren aanlopen als het gaat om het doen van iets meer dan alleen een basisinteractieprototype. Ze moeten minder doen, naar mijn mening. Hoopvol dat die tools meer controles toevoegen die in dezelfde lijn liggen als Cursor en Framer. Ik voeg ook toe dat dit vergelijkbaar is met hoe we het doen met @Basedash grafiekgeneratie. Maar we zijn geen vibe-tool in de normale zin, dus de parallellen zijn iets moeilijker te trekken.