Vibe Coding 101: En praktisk workshop från noll till ett

Läs transkriberingen:

Vi provar att transkribera våra poddar med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte har rätt 100 % av gångerna.

Hannah Clark: Okej, allihop. Ansvarsfriskrivning för dagens avsnitt – om du redan är expert på Vibe Coding kanske det här avsnittet inte är för dig. Men om du har hört talas om Vibe Coding och vill veta vad som är fakta och vad som är myter, och är nyfiken på hur du kan använda tekniken för att nå dina egna mål, kommer du att älska det här.

Om du inte har följt våra nyhetsbrev, alltså de som du kan prenumerera på via theproductmanager.com/subscribe, har jag inte kunnat sluta prata om den fantastiska praktiska Vibe Coding-workshop som vi höll för några veckor sedan tillsammans med Drew Falkman, huvudansvarig på Moves The Needle. Det här avsnittet av Product Manager Podcast är faktiskt en inspelning av det 30 minuter långa seminarium vi höll innan vi gick vidare till vår livesession för prototypframtagning. Du får höra en genomgång av vad vibe coding är och inte är, inspirerande användningsområden för tekniken samt rekommendationer på verktyg för att börja experimentera och upptäcka egna användningsområden. Då kör vi.

Förresten håller vi sådana här samtal varje vecka. Om det här låter intressant för dig, varför inte prenumerera? Okej, då kör vi.

Jag heter Hannah Clark. Om du inte känner mig är jag chefredaktör för The CPO Club och programledare för The CPO Club-podden. Och jag har min medprogramledare Katie med mig.

Katie Sanders: Hej allihop, jag heter Katie Sanders. Jag är chefredaktör på The CTO Club. Kanske även på The QA Lead. Det finns personer som vi har slagit ihop de webbplatserna för. Så jag är väldigt taggad. Det här är min första workshop och jag ser verkligen fram emot att göra det här med Hannah, eftersom det finns mycket överlappning mellan produkt och CTO:er. Så ja, jag ser fram emot att lära känna alla. Välkomna!

Hannah Clark: Jag är väldigt glad över att få arbeta med Katie kring det här. Om du inte följer henne på LinkedIn än, sök efter Katie Sanders – hon är helt fantastisk. Hon skapar fantastiskt innehåll, så jag ser verkligen fram emot att ni ska lära känna varandra.

Jag vill också gärna presentera vår huvudtalare. Här har vi Drew Falkman. Drew är produktledare, rådgivare och utbildare med fokus på produktstrategi från försådd finansiering till såddfinansiering. Han har effektiviserat tidiga team och optimerat produkt–marknadspassning.

Han har gjort allt. Han är en god vän till publikationen och har arbetat massor med oss. Han har arbetat mycket med mig också, vilket säger att han är en mycket tålmodig man. Så ni är i goda händer i dag. Han har dessutom stor erfarenhet av webb-, mobil-, blockkedje- och AI-produkter. Vi har alltså en fantastisk expert här.

Drew, vill du hälsa på alla trevliga människor?

Drew Falkman: Hej allihop, jättekul att vara här. Det här kommer att bli roligt.

Hannah Clark: Vi börjar med att slå hål på några myter. Jag ställer den första frågan och sedan går min fantastiska medprogramledare Katie igenom några myter, så får Drew avliva dem åt oss. Vi börjar med att skapa lite sammanhang.

Det verkar som att alla pratar om vibe coding och att det dyker upp i varje LinkedIn-inlägg just nu, inklusive många av mina egna. Och människor verkar antingen vara väldigt entusiastiska, väldigt rädda eller väldigt förvirrade. Så låt oss prata om varför Vibe Coding är så populärt. Varför är det så viktigt just nu? Låt oss gå till botten med myten kring det.

Katie Sanders: Okej, första myten: vibe coding ersätter ingenjörer. Det finns uppenbarligen mycket av det här med att AI generellt ersätter allas jobb. Det är vad man hör. Jag skulle säga att det är en myt och att det kanske förändrar ingenjörens jobb och skapar kod som är redo för appar, men det ersätter definitivt inte helt en ingenjörs arbete.

Som alltid med AI vill vi ha en människa med i processen, så jag skulle säga att inget kommer att lanseras utan mänskliga ögon på det. Därför tycker jag att vi kan slå hål på den myten.

Hannah Clark: Drew, hade du något att tillägga?

Drew Falkman: Ja, jag skulle säga att det är något som ingenjörer behöver vara medvetna om, eftersom det är på väg.

Det kan helt enkelt göra din process snabbare. Och som designer, produktchef eller icke-teknisk grundare har ni nu möjlighet att skapa MVP:er, skapa och validera prototyper och göra saker som ni sedan kan lämna över till ingenjörerna. När man vill komma till kod på produktionsnivå behöver man generellt gå längre än en MVP.

I dag behöver man definitivt göra kodgranskningar och gå igenom allt för att se till att allt är ordentligt genomarbetat, särskilt om det finns frågor kring efterlevnad eller annat som man behöver ta hänsyn till.

Hannah Clark: Vi går vidare till myt nummer två. Vissa säger att vibe coding är en värld utanför utvecklingscykeln.

Med andra ord: om du bygger något i en vibe-coding-app är det fortfarande inte riktigt användbart och du måste bygga om det helt från grunden med en utvecklare som hårdkodar allting. Drew, stämmer det verkligen?

Drew Falkman: Verktygen har utvecklats enormt, och det är en sådan sak som bokstavligen förändras varje dag.

Claude släppte nyligen en ny version av sin kodgenerering, under den senaste månaden eller så, och den är mil bättre än tidigare. Den förbättras alltså hela tiden. Precis som all generativ AI kan den hallucinera, göra märkliga saker och göra sådant som är oväntat. Som en del av cykeln kan den ändå passa in i arbetsflödet, och man kan faktiskt skapa sådana här koddelar.

Man kan lämna över dem till ingenjörer, men man måste vara medveten om att de troligen behöver bearbetas. Du kan behöva återanvända vissa komponenter, och jag tror att en del ingenjörer kan bli förvånade över hur bra koden faktiskt är.

Hannah Clark: Okej. En annan myt som jag ofta hör är att man inte behöver en PRD eller en produktstrategi för att vibe-koda ett verktyg.

Drew, Katie, vad tänker ni om det?

Drew Falkman: Man måste alltid tänka efter. Jag tror att det som händer ibland är att människor tänker: ”Om jag vibe-kodar kan jag bara sätta igång, öppna verktyget och ha en app i morgon.” Men precis som med allt annat blir det inte vad du vill ha om du inte tänker igenom det i förväg. Du behöver fundera på vem målgruppen är och vilken din målmarknad är.

Du behöver fundera på vilket ditt värdeerbjudande är. Du behöver tänka på vilka kärnfunktioner och flöden i appen ska vara. Därför är det verkligen värt tiden att sätta ihop något. Det fina är att du inte behöver skapa en PRD på fem till tio sidor som definierar vilken teknik som ska användas och ritar upp alla flöden och sådant.

Du behöver inte tänka på allt det. Du vill bara beskriva din vision och vad det är du bygger. Jag har faktiskt tagit fram en liten vibe-PRD, och den är ungefär en till två sidor. Den är till för dig och alla andra du eventuellt samarbetar med, så att ni är överens och kan arbeta på ett organiserat sätt.

Och så blir koden renare på lång sikt.

Hannah Clark: Bra att veta. Vi går vidare till nästa myt, som handlar om starkt reglerade branscher. Katie representerar CTO Club – vill du ta den myten, Katie?

Katie Sanders: Ja, en annan sak jag ville ta upp är att det här skulle vara nytt. Vi har vibe-kodat i flera år.

Vi kallade det bara inte så förrän nyligen. Att kopiera och klistra in från GitHub, Reddit eller Hacker News, var som helst – bra ingenjörer löser problem. De söker, känner igen mönster, anpassar och bygger. Så jag tror att den här promptbaserade metoden bara är nästa utveckling av något som alltid har funnits. Och Hannah, vilken var den andra myten du ville slå hål på?

Hannah Clark: Att man inte kan vibe-koda om man arbetar i en starkt reglerad bransch. Att det inte är säkert.

Katie Sanders: Ja. När vi tänker på exempelvis sjukvård eller finans är det uppenbart att det är starkt reglerade branscher. Precis som i alla andra branscher måste man alltså se till att man följer HIPAA och alla sådana regler.

Jag vet att stora språkmodeller ibland kan göra fel. Så ta hänsyn till frågor om efterlevnad, särskilt inom branschen. Men jag tycker att det finns ett extra skyddsräcke när man tänker på sjukvård, finans eller något liknande.

Hannah Clark: Ja, jag tycker att det påminner om många olika utvecklingsprocesser där vibe-coding-verktygen fortfarande inte ersätter personalen.

De fungerar bara som ett komplement som snabbar upp utvecklingscykeln. Men en bra och noggrann kodgranskningsprocess är förmodligen viktigare än någonsin nu när vi lägger ut en del av arbetet på andra. Okej, låt oss prata lite om användningsområden. Det blir roligt att utforska några olika sätt som människor använder vibe coding effektivt på just nu.

Katie leder den här delen av programmet och går igenom några av användningsområdena som var ganska häftiga.

Katie Sanders: Jag hämtade faktiskt många av de här exemplen från Reddit när Vibe Coding först började dyka upp. Jag ville se exempel från verkligheten. Alla pratade om det, men jag kunde egentligen inte hitta något som var framgångsrikt.

Så jag skrev en artikel om det. En av sakerna vi pratade om var en person som byggde, tror jag, en fotbollsapp – en nischad matchorganisatör för fotboll, som ett personligt hobbyintresse. Han var inte utvecklare, men han förstod hur applikationer med hela teknikstacken fungerade och hade alltid behövt anlita utvecklare för att förverkliga sina idéer.

Men när han började experimentera med Lovable, Cursor och alla de andra verktygen byggde han den här nischade fotbollsappen. Den hjälpte honom att organisera sina veckomatcher, och han lyckades lansera den framgångsrikt. Han skapade en AI-genererad app med hundra rader kod som gick med vinst inom några veckor. Jag tror att den drog in ungefär, var det Michael?

Var det ungefär 700 dollar i veckan eller något sådant? Ett annat exempel vi hittade hette Work Aid. Det är ett spelifierat uppgiftshanteringsverktyg som drivs av AI – det revolutionerar att-göra-listan genom att få arbetet att kännas som ett spel. Det var några framgångsrika exempel som jag hittade på Reddit, och vi kan länka er till Reddit-inlägget.

Det fanns några fler exempel också. Jag tror att många bara kommer att experimentera med det här, men vissa kommer att lyckas riktigt bra, vilket är väldigt roligt att se.

Hannah Clark: Ja, det är ett väldigt häftigt exempel. Jag ville bara snabbt flika in eftersom vi har en väldigt bra fråga från Katya.

Katya säger: ”Jag undrar om jag som produktchef fortfarande måste skapa wireframes och mockuper för frontend. Jag skulle ju kunna skapa den med vibe coding, och sedan kan utvecklarna använda min frontend som utgångspunkt för sin egen utveckling.”

Drew Falkman: Ja, absolut. Faktum är att jag skulle säga att det med de flesta av de här verktygen skulle vara svårare att använda Vibe Coding för att implementera en befintlig design.

Det är svårt att importera skärmbilder och göra allt det där. Det är faktiskt lättare att definiera designen, och du kan samarbeta med den generativa AI:n för att få rätt utseende och känsla och allt sådant. Sedan kan du lämna över den, så kan utvecklarna se till att den följer det designsystem eller annat som ni använder.

Hannah Clark: Tack för att du tog den, Drew. Förlåt att jag avbröt, Katie. Ville du återgå till några av användningsområdena? Jag vet att du har ett par till på lager.

Katie Sanders: Michael, vill du berätta att vi har ett användningsområde från någon på vårt företag? De skapade en analysator för uppsägningspåverkan. Michael, jag vet inte om du ville dela med dig av det som ett bra exempel.

Michael Mordak: Absolut. Det här är ett fantastiskt exempel som en av våra kollegor använde på sin webbplats. Personen arbetade för en HR-publikation och ville bygga ett verktyg som människor kunde använda för att analysera effekten av en uppsägning om de planerade en sådan. Han gjorde det genom att koda, eller rättare sagt bot-koda, verktyget så att de som vill använda det först måste fylla i en enkät.

På så sätt samlar han in uppgifter om personerna som använder det, vilket var något han ville göra för sina egna syften. När enkäten är klar tar appen dig vidare till den här kalkylatorn. Det finns några exempel inbyggda. Om du arbetar på ett tillverkningsföretag och funderar på att säga upp 200 anställda kan du välja det exemplet för att se hur det fungerar.

I princip fyller du i alla olika detaljer och anger hur mycket kunskap personerna har och hur lång tid det skulle ta att utbilda någon på nytt för rollen. Sedan kan du beräkna effekten av uppsägningarna, och verktyget berättar exakt vilken påverkan de kommer att få.

Det skulle vara ett fantastiskt verktyg för personer inom HR som planerar uppsägningar. Han har gjort det tillgängligt gratis för människor som vill prova och ge feedback. Det är ett exempel från någon i vårt team. Det andra exemplet jag kan dela är omröstningsverktyget som vi nyss använde. Jag kodade det helt själv.

Jag har ingen erfarenhet av programmering, eller väldigt begränsad erfarenhet i alla fall. Jag byggde den här omröstningsappen så att vi kunde ta emot röster från livepubliken och visa resultaten, i stället för att behöva betala för ett verktyg som gjorde det. Ofta har appar den funktionen, men då måste man betala och får samtidigt betala för alla andra funktioner som man egentligen inte använder.

Jag bryr mig bara om omröstningar, så jag byggde det här för att kunna skapa egna omröstningar. Jag kan ge dem vilket namn jag vill, lägga till hur många alternativ jag vill, förhandsvisa dem innan de publiceras och sedan antingen starta dem härifrån eller stänga av dem, ta bort dem och så vidare. Det är så de visas på skärmen.

Ni röstar alltså i appen som jag skapade. Jag samlar inte in några uppgifter från er, så oroa er inte. Allt finns bara här. Det var något jag slängde ihop. Jag arbetade faktiskt med det 30 minuter före det här samtalet, men totalt tog det förmodligen en till två timmar att sätta ihop det och ge det en formgivning som jag tyckte såg bra ut.

Men jag är inte heller designer, så ta inte råd av mig.

Katie Sanders: Ja, vi har pratat om fördelarna här. Naturligtvis finns det personer som experimenterar med det här och tror att de aldrig mer kommer att behöva någon teknisk person. Men det finns ett exempel med en kille som heter Leo Junior.

Hans inlägg blev viralt på X. Han är grundare av Enrich Lead, ett verktyg som samlar in IP-adresser och använder en stor språkmodell för att generera försäljningsleads. Han byggde hela appen med Cursor och sa stolt: ”Noll handskriven kod. AI är byggaren. Du kan klaga på det eller börja bygga.” Det var mycket självsäkerhet och ingen ödmjukhet.

Internet valde förstås våld, och inom 48 timmar tog hackare över. Hans prenumerationer kringgicks, kostnaderna sköt i höjden och den stora språkmodellen började hitta på leaddata ur tomma luften. Leo var därför tvungen att lägga ut ett SOS på Twitter och säga: ”Hej, jag är under attack. Slumpmässiga saker händer.”

”Jag är inte teknisk, så det tar längre tid än vanligt för mig att förstå vad som händer.” Nu lär han sig alltså att koda den hårda vägen. Lärdomen är återigen att man alltid behöver en människa i processen. Det är roligt att experimentera som icke-teknisk person, men man behöver alltid en teknisk person som granskar koden.

Hannah Clark: Michael, ville du ge en snabb genomgång av hur inlärningskurvan såg ut för dig när du först började experimentera med verktygen?

Michael Mordak: Absolut. Som jag sa har jag väldigt begränsade kunskaper i programmering. Det här är något jag ibland ser när människor säger: ”Jag är en idémänniska.”

”Jag har aldrig faktiskt byggt något sådant förut.” Det är precis den grupp jag tillhör, eftersom jag ofta tänker på olika sätt att minska interna processer eller göra saker utan att behöva betala för tredjepartsappar, men att faktiskt bygga det är svårt.

Som svar på Grands fråga om hur inlärningskurvan ser ut i praktiken, och om verktyget Lovable som vi ska använda i dag: det kommer att vara ungefär likadant med de andra apparna som finns. Inlärningskurvan är faktiskt väldigt gradvis och ganska låg, eftersom det bara handlar om textbaserade instruktioner.

Du beskriver exakt vad du vill se, vad ditt mål med appen är och vilka resultat du vill uppnå. Sedan ger verktyget några exempel på vad det skulle kunna bygga åt dig. Du kan också ge ytterligare detaljer. Om du har något som du utgår från kan du till exempel säga: ”Jag vill att det ska se ut ungefär som slido.com.” Om du känner till Slido vet du att det är en omröstningsapp.

Verktyget kan använda verkliga exempel som grund, och sedan kan du lägga in din egen profilering och alla andra krav som appen behöver uppfylla. När den första versionen är byggd är det inte slutet. Du kan fortsätta chatta med den.

Det finns ett chattläge där du kan ställa frågor innan den faktiskt ändrar koden eller bygger något. Det som också fungerade för mig var att när saker blev lite för avancerade för mina kunskaper tog jag vissa saker som Lovable berättade att jag gjorde, kopierade dem till ChatGPT och bad: ”Förklara det här för mig som om jag vore fem år.”

Då förenklade den allt för någon som jag, som inte förstår alla tekniska detaljer, och förklarade det mycket noggrant. Så ja, processen var väldigt smidig och det blev enkelt att försöka bygga något sådant här.

Hannah Clark: Det är så häftigt. Jag hoppas att det känns uppmuntrande för oss som börjar helt från grunden, inklusive mig själv.

Jag ville ta upp en fråga från Tal. Vi riktar den till Drew. Tal frågar: ”Vilket arbetsflöde skulle du rekommendera för befintliga produktföretag? Jag är produktchef på ett nystartat företag. Vi har ett designsystem och en fungerande produkt med användare. Hur tycker du att jag kan använda Vibe Coding för specifika funktioner eller idéer?”

”Och när ska det gå tillbaka till designavdelningen, eller hoppar man över designen och går direkt till utveckling?”

Drew Falkman: Jag tror att hela det här arbetsflödet fortfarande är under utveckling. Det finns inga bästa metoder ännu. Det är fortfarande vilda västern när det gäller att sätta ihop allt det här. Men om jag arbetade på ett företag skulle jag hoppa över designsteget, men samordna med designern.

Jag skulle göra så här – och jag ska visa min vibe-PRD: jag skulle sätta ihop något som beskriver skärmarna och elementen. Se till att få med designern på tåget. Designern kan även vara med och samarbeta här. Kom ihåg att vi inte behöver göra det här isolerat. Alla kan titta på samma projekt och arbeta med det tillsammans.

Sedan skulle jag skapa det. Det finns inget magiskt sätt som jag känner till, åtminstone inte i Lovable, för att integrera designsystem. Vissa andra verktyg, som Cursor, är faktiskt verktyg på lägre nivå för det här, eftersom du kan koppla in chattarna och allt annat, men du arbetar verkligen i koden.

Det sker i en integrerad utvecklingsmiljö och kräver ofta att man kör saker via kommandoraden. Det är därför lite mer tekniskt för helt icke-tekniska personer, men det ger bättre möjligheter till kodintegration och samverkan. Det kan alltså vara ett bättre verktyg för det här användningsområdet. Om jag gjorde det här skulle verktyget faktiskt synkronisera åt båda hållen med GitHub, vilket jag ska försöka visa om vi hinner i dag.

Du skulle kunna göra en iteration av en skärm och publicera den på GitHub. Sedan kan utvecklarna hämta ner den, använda alla sina komponenter och designsystem och skicka upp den igen. När du sedan går tillbaka in i projektet borde du kunna se allt det där, och förhoppningsvis, helst, ska det fungera bra.

Hannah Clark: Grymt. Den här frågan kommer från Donald och är till Drew: ”Vilken erfarenhet har du av vibe coding för något som är mer likt något annat, till exempel en annan uppgiftshanterare, jämfört med något mer unikt, som en sonifiering av Google Trends-data?” Med andra ord: vibe coding för något som liknar en version av något som redan finns i många varianter, jämfört med en idé som är helt okänd och aldrig riktigt har gjorts tidigare.

Drew Falkman: Det är en fantastisk fråga. Min erfarenhet av prototypverktyg och vibe-coding-verktyg generellt är att sådant som redan finns är ganska enkelt. Verktygen förstår det. Vårt standardexempel i dag är en reseapp. De kan skapa reseappar hela dagen, men när du kommer till något som sonifiering av Google Trends-data blir det mer av en kamp.

Jag skulle också säga att om du ger dig på något som kräver mycket specialanpassade visualiseringsverktyg utöver vanliga gränssnittselement som rullgardinsmenyer och knappar, kommer du att få kämpa med den här typen av verktyg, åtminstone med Lovable och där vi befinner oss i dag.

Det kan finnas andra verktyg som gör det enklare, men just nu är sådant något där du behöver ta in utvecklare och arbeta tillsammans med dem om du gör något väldigt speciellt och långt från det vanliga.

Hannah Clark: Okej. Då är tiden slut. Jag vill rikta ett stort tack till Katie för att hon var med och naturligtvis till Drew för att han var en fantastisk resurs och frivilligt delade med sig av sin tid och sin expertis.

Tack för att ni lyssnade. För fler fantastiska insikter, guider och verktygsrecensioner kan ni prenumerera på vårt nyhetsbrev på theproductmanager.com/subscribe. Du kan höra fler samtal som detta genom att prenumerera på The CPO Club där du brukar lyssna på poddar.