Det är så här jag känner för vibekodning. Alla projekt jag försöker mig på som har någon form av komplikation har en omedelbar explosion av framsteg. Saker är fantastiska och det känns som en superkraft. Då... när jag lägger till mer komplexitet kraschar saker och ting. De enda projekt som jag tror att jag kan skapa är de som faller inom den här "vibe-zonen". Prototyper, användargränssnitt, produkter – allt som är enkelt och har låg komplexitet passar in i den zonen. Proof of concepts, interaktioner, sånt. Verktygen kan göra saker som passar i det facket. Men. Allt faller i bitar när komplexitetskurvan ökar. Och problemet är att alla bra produktdesignprocesser blir allt mer komplexa. En grundläggande prototyp förvandlas till en bra prototyp så snart den har lager av interaktioner, övergångar, bra priser, svävande tillstånd, 1000 små små detaljer som gör att något känns korrekt och verkligt. Fördelen med vibe-kodning är tänkt att vara att du rör dig snabbt och att du kan piska ut saker och ting – och låta AI göra allt arbete åt dig. Problemet är att den tappar fart så snart den nödvändiga komplexiteten läggs till. Den fortsätter att göra om sig själv, skriva om kod, påverka saker som inte är relaterade och sedan orsaka andra problem. Men om du lägger till den komplexiteten förvandlas varje vibe-kodningssession snabbt till en whack-a-mole-bug-bashing-session. Jag är inte säker på lösningen på detta. Med traditionell prototyping är lösningen att duplicera, lägga till mer komplexitet, skapa fler ramar/scener, tweaka, forka, etc. Men med vibekodning kan en liten uppmaning förstöra bokstavligen allt. Det finns ett stadium där jag slutar gå på snabba äggskal - försöker att inte ge det för mycket eller för lite sammanhang så att det inte blir oseriöst och förstör allt. Det finns bara några få undantag från detta. @cursor och @framer. Jag kan göra stora framsteg med markören, ge den ett smalt sammanhang och jag måste godkänna de redigeringar som den gör. Detta känns som ett korrekt arbetsflöde. Problemet är att jag inte kan se det som det gör eftersom det är en IDE, inte en visuell miljö. Ja, jag kan skapa lokala byggen och uppdatera min webbläsare och allt sånt. Men den visuella aspekten går helt förlorad från kodningsupplevelsen. Det är ett utvecklarverktyg. Framer gör detta rätt eftersom det bara tillåter smala uppdateringar inom en enda komponent på sidan. Ja, det är begränsande eftersom det bara kan göra en enda sak på en gång, men det försöker åtminstone inte skapa hela sidan från grunden och hantera allt via ett snabbt gränssnitt. Detta verkar vara rätt tillvägagångssätt. @Cursor: Tillåt AI att redigera vad som helst, men låt användaren godkänna dessa redigeringar och se dem i sitt sammanhang. @Framer: Tillåt AI att endast redigera en enskild fil eller komponent med knapp marginal för att hålla komplexiteten nere till ett minimum och minska katastrofala redigeringar. Jag är optimistisk om att verktyg som @Figma, @Lovable, @Bolt och @V0 kan göra coola prototyper, men jag fortsätter bara att springa in i väggar när det gäller att göra något mer än bara en grundläggande interaktionsprototyp. De behöver göra mindre IMO. Hoppas att dessa verktyg lägger till fler kontroller som är i samma rad som Cursor och Framer. Jag ska också tillägga att detta liknar hur vi gör det med @Basedash diagramgenerering också. Men vi är inte ett vibe-verktyg i vanlig bemärkelse så parallellerna är lite svårare att dra.