Vibe Coding 101: En praktisk workshop fra nul til én

Læs transskriptionen:

Vi prøver at transskribere vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Hannah Clark: Okay, folkens. Ansvarsfraskrivelse for dette afsnit—hvis du allerede er ekspert i Vibe Coding, er dette afsnit måske ikke noget for dig. Men hvis du har hørt om Vibe Coding og gerne vil kende fakta kontra myter, og du er nysgerrig efter, hvordan du kan bruge teknologien til at fremme dine egne mål, så kommer du til at elske dette.

Hvis du ikke har fulgt med i vores nyhedsbreve, altså dem du kan abonnere på via theproductmanager.com/subscribe, har jeg ikke kunnet holde mund om den fantastiske praktiske Vibe Coding-workshop, vi afholdt for et par uger siden, med Drew Falkman, chef hos Moves The Needle. Dette afsnit af Product Manager Podcast er faktisk en optagelse af det 30 minutter lange seminar, vi afholdt, før vi gik i gang med vores live-prototypingssession. Du får en gennemgang af, hvad vibe coding er og ikke er, inspirerende anvendelsesmuligheder for teknologien samt anbefalinger til værktøjer, så du kan begynde at lege med den og selv opdage anvendelsesmuligheder. Lad os komme i gang.

Nå ja, vi har samtaler som denne hver uge. Så hvis det lyder interessant for dig, hvorfor så ikke abonnere? Okay, lad os komme i gang.

Jeg hedder Hannah Clark. Hvis du ikke kender mig, er jeg ledende redaktør for The CPO Club og vært på The CPO Club-podcasten. Og jeg har min medvært, Katie, med.

Katie Sanders: Hej alle sammen, jeg hedder Katie Sanders. Jeg er ledende redaktør hos The CTO Club. Måske også fra The QA Lead. Der er nogle, der ikke ved, at vi har slået de sider sammen. Så jeg er begejstret. Det er min første workshop, og jeg glæder mig virkelig til at gøre det her sammen med Hannah, fordi der er et stort overlap mellem produktfolk og CTO’er. Så ja, jeg glæder mig til at lære jer alle at kende. Velkommen!

Hannah Clark: Jeg er meget begejstret for at arbejde sammen med Katie om dette. Hvis du ikke allerede følger hende på LinkedIn, så søg efter Katie Sanders—hun er virkelig fantastisk. Hun laver fremragende indhold, så jeg glæder mig virkelig til, at I lærer hinanden at kende.

Jeg vil også gerne præsentere vores taler. Vi har Drew Falkman med. Drew er produktleder, rådgiver og underviser med fokus på produktstrategi fra før såning til såning. Han har effektiviseret tidlige teams. Han har optimeret produktets markedsmatch.

Han har prøvet det hele. Han er en god ven af vores udgivelse. Han har arbejdet masser sammen med os. Og han har arbejdet meget sammen med mig, hvilket fortæller jer, at han er en meget tålmodig mand. Så I er i gode hænder i dag. Og han har også erfaring—han har masser af erfaring med web-, mobil-, blockchain- og AI-produkter. Så vi har en fantastisk ekspert med.

Drew, vil du sige hej til de flinke mennesker?

Drew Falkman: Hej alle sammen, jeg er superglad for at være her. Det bliver sjovt.

Hannah Clark: Vi starter med at aflive nogle myter, og jeg lægger ud med det første spørgsmål, hvorefter min skønne medvært Katie gennemgår nogle myter og lader Drew aflive dem for os. Så lad os begynde med at sætte scenen.

Det virker, som om alle taler om vibe coding, og det dukker op i hvert eneste LinkedIn-opslag lige nu, inklusive mange af mine egne. Og folk virker enten meget begejstrede, meget bange eller meget forvirrede. Så lad os tale om, hvorfor Vibe Coding er så populært. Hvorfor er det så vigtigt lige nu? Lad os se nærmere på myten omkring det.

Katie Sanders: Okay, første myte: Vibe Coding erstatter ingeniører. Der er naturligvis mange, der generelt siger, at AI erstatter alles job. Jeg vil sige, at det er en myte, og at det måske ændrer ingeniørens job og skaber kode, der er klar til at blive brugt i apps, men det erstatter bestemt ikke ingeniørens arbejde fuldstændigt.

Som altid med AI vil vi gerne have et menneske med i processen, så jeg vil sige, at intet bliver sendt ud uden menneskelige øjne på det. Derfor tror jeg, vi kan aflive den myte.

Hannah Clark: Drew, havde du noget at tilføje?

Drew Falkman: Ja, jeg vil sige, at det er noget, man som ingeniør skal være opmærksom på og have i baghovedet, for det er på vej.

Det kan ganske enkelt gøre din proces hurtigere. Og som designer, produktchef eller ikke-teknisk grundlægger har du nu mulighed for at skabe MVP’er, udvikle og validere prototyper og gøre ting, som du derefter kan give videre til ingeniørerne. Når du vil over i kode på produktionsniveau, generelt set efter en MVP,

skal du naturligvis lave kodegennemgange og gennemgå det hele for at sikre, at alt er strammet op, især hvis der er nogen form for complianceproblemer eller andet, du skal være opmærksom på.

Hannah Clark: Vi går videre til myte nummer to. Nogle siger, at vibe coding er en verden uden for udviklingscyklussen.

Med andre ord: Hvis du bygger noget i en vibe coding-app, er det stadig sådan, at det ikke rigtig kan bruges, og at du skal bygge det helt om fra bunden sammen med en udvikler, der skriver hele thingen manuelt. Drew, er det virkelig sådan?

Drew Falkman: Værktøjerne har udviklet sig enormt, og det er en af de ting, der bogstaveligt talt ændrer sig hver dag.

Claude udgav en ny version af deres kodegenerering inden for den seneste måneds tid, og den er milevidt bedre end før. Så det bliver hele tiden forbedret. Det fungerer ligesom alt andet generativ AI. Det kan hallucinere, det kan gøre fjollede ting, og det kan gøre ting, man ikke forventer. Som en del af cyklussen kan det indgå i cyklussen, og du kan faktisk skabe disse former for kodestykker.

Give dem videre til ingeniører, men du skal virkelig være bevidst om, at de sandsynligvis skal omarbejdes. Du kan få brug for at genbruge nogle komponenter, og jeg tror, at nogle ingeniører måske bliver overraskede over, hvor god koden faktisk er.

Hannah Clark: Okay. En anden myte, jeg ofte har hørt, er, at man ikke har brug for en PRD eller en produktstrategi for at vibe code et værktøj.

Drew, Katie, hvad tænker I om det?

Drew Falkman: Altså, man er altid nødt til at tænke sig om. Jeg tror, at der nogle gange sker det, at folk tænker: Hvis jeg vibe coder, kan jeg bare gå i gang, åbne det og have en app i morgen. Og ligesom med alt andet bliver det ikke, som du ønsker, hvis du ikke tænker dig om på forhånd. Du skal tænke over, hvem din målgruppe er, og hvem dit målmarked er.

Du skal tænke over, hvad dit værdiforslag er. Du skal tænke over, hvad appens kernefunktioner og flows skal være. Derfor er det virkelig værd at bruge tid på at udarbejde noget. Det smarte er, at du ikke behøver at lave en PRD på fem til ti sider, der definerer den teknologi, der skal bruges, og tegner alle flows og den slags.

Det behøver du ikke tænke på. Du skal bare skitsere, hvad din vision er, og hvad det er, du bygger. Faktisk har jeg udarbejdet en lille vibe-PRD, og den er på en til to sider. Den er bare til dig og alle andre, du eventuelt samarbejder med, så I er på samme side, og så du kan gå til det på en organiseret måde.

Og så bliver din kode renere på lang sigt.

Hannah Clark: Godt at vide. Vi går videre til den næste myte om stærkt regulerede brancher. Katie repræsenterer CTO Club, så vil du tage dig af den myte, Katie?

Katie Sanders: Ja, jeg tror, der er endnu en, jeg gerne vil berøre. Det er, at dette er nyt, og at man skulle tro, vi har vibe codet i årevis.

Vi kaldte det bare ikke det indtil for nylig. Men at kopiere og indsætte fra GitHub, Reddit eller Hacker News, hvor som helst—dygtige ingeniører løser problemer. De søger, genkender mønstre, tilpasser og bygger. Så jeg tror, at denne prompt blot er den næste udvikling af noget, der altid har været der. Og Hannah, hvad var den anden, du ville aflive?

Hannah Clark: Bare at man ikke kan vibe code, hvis man arbejder i en stærkt reguleret branche. At det ikke er sikkert.

Katie Sanders: Ja. Når vi for eksempel tænker på sundhed eller finans, er det stærkt regulerede brancher. Så ligesom i alle andre brancher skal man sørge for at overholde HIPAA og alle de andre krav.

Jeg ved, at LLM’er nogle gange kan trække. Ja, så overvej complianceproblemerne i branchen. Men jeg tror, der er lidt ekstra sikkerhedsrækværk, når man tænker på sundhed, finans eller noget i den stil.

Hannah Clark: Ja, jeg tror, det minder lidt om mange forskellige udviklingsprocesser, hvor vibe coding-værktøjerne stadig ikke erstatter dit personale.

De fungerer bare som et supplement, der kan fremskynde udviklingscyklussen. Men en god og grundig kodegennemgangsproces er nok vigtigere end nogensinde, nu hvor vi outsourcer noget af arbejdet. Okay, lad os tale lidt om nogle anvendelsesmuligheder. Det bliver sjovt at udforske et par forskellige måder, folk bruger vibe coding effektivt på lige nu.

Katie leder denne del af programmet og gennemgår nogle af de anvendelsesmuligheder, der var ret interessante.

Katie Sanders: Jeg hentede faktisk mange af disse eksempler fra Reddit, da Vibe Coding først begyndte at dukke op. Jeg ville se eksempler fra den virkelige verden på det. Alle talte om det, men jeg kunne ikke rigtig se noget, der havde været en succes.

Så jeg skrev en artikel om det, og en af de ting, vi talte om, var en person, der byggede—jeg tror, det var en slags fodboldspil, en nichearrangør af fodboldkampe, bare som en personlig interesse eller hobby. Han var ikke udvikler, men han forstod, hvordan fulde stack-apps fungerede, og han havde altid været nødt til at hyre udviklere for at føre sine idéer ud i livet.

Men da han begyndte at lege med Lovable, Cursor og alle de andre ting, byggede han denne nicheapp til fodboldkampe. Den hjalp ham med at organisere sine ugentlige kampe, og han endte med at udgive den med succes. Ja, han udgav en AI-genereret app på hundrede linjer, som gav overskud. Inden for få uger tror jeg, den indbragte noget i retning af—var det Michael?

Var det omkring 700 dollars om ugen eller sådan noget? Et andet eksempel, vi fandt, hed Workaid. Det var en gamificeret opgavestyring drevet af AI, altså en måde at revolutionere din to-do-liste på med apps, der får arbejdet til at føles som et spil. Det var et par succesfulde eksempler, som jeg fandt på Reddit, og vi kan linke jer til det Reddit-opslag.

Der var nogle flere eksempler, og jeg tror, at mange mennesker bare kommer til at lege med det her, men der er nogle, som kommer til at få stor succes med det, hvilket er virkelig spændende at se.

Hannah Clark: Ja, det er et virkelig godt eksempel. Jeg ville bare lige bryde ind, fordi vi har et rigtig godt spørgsmål fra Katya.

Katya siger: Jeg spekulerede på, om jeg som PM stadig skal lave wireframes og mockups til brugerfladen. Jeg kunne bare skabe den med vibe coding, og så kan udviklerne bruge min brugerflade som udgangspunkt for deres egen udvikling.

Drew Falkman: Ja, 100 %. Faktisk vil jeg sige, at det er sværere med Vibe Coding og de fleste af disse værktøjer at forsøge at implementere et eksisterende design.

Det er svært at importere skærmbilleder og gøre alt det. Det er faktisk lettere at definere det, og du kan samarbejde med den generative AI om at få udseendet og følelsen til at sidde rigtigt og den slags. Derefter kan du give det videre til udviklerne, og de kan sikre, at det overholder det designsystem eller andet, du bruger.

Hannah Clark: Tak, fordi du tog dig af det, Drew. Beklager, Katie, at jeg brød ind. Vil du gå tilbage til nogle af anvendelsesmulighederne? Jeg ved, at du har et par stykker mere i ærmet.

Katie Sanders: Michael, vil du fortælle, at vi har en anvendelsesmulighed fra en person i vores virksomhed? De skabte denne analyse af afskedigelsers konsekvenser. Michael, jeg ved ikke, om du vil dele den som et godt eksempel.

Michael Mordak: Helt sikkert. Det er et fantastisk eksempel, som en af vores kolleger brugte på sin side. Han arbejder for en HR-udgivelse og ville bygge et værktøj, som folk kunne bruge til at analysere konsekvenserne af en afskedigelse, hvis de planlagde en.

Måden, han har gjort det på, er, at han faktisk har kodet det—eller botten har kodet det—så folk, der vil bruge det, først skal udfylde en undersøgelse. På den måde indsamler han data om de personer, der bruger det, hvilket han gerne ville gøre af hensyn til sine egne formål. Når undersøgelsen er udfyldt, fører appen dig videre til denne beregner. Der er nogle eksempler, som han har bygget ind i den. Hvis du for eksempel arbejder i en produktionsvirksomhed og overvejer at afskedige 200 medarbejdere, kan du vælge dette eksempel for at se, hvordan det fungerer.

Men grundlæggende indtaster du alle disse forskellige oplysninger og svarer på spørgsmål som: Hvor meget viden har disse personer? Hvor lang tid vil det tage at oplære nogen til denne rolle? Derefter kan du beregne konsekvenserne af afskedigelsen, og den fortæller dig præcis, hvilken effekt det vil have.

Det ville være et fantastisk værktøj for folk, der arbejder med HR og planlægger en afskedigelse. Han har bare givet det gratis til folk, der vil lege med det og give feedback. Men det er et eksempel, vi har fra en person på vores team. Det andet eksempel, jeg kan dele, er afstemningsværktøjet, som vi lige brugte. Jeg kodede det selv.

Jeg har ingen erfaring med kodning eller i hvert fald meget begrænset erfaring. Derfor byggede jeg denne afstemning—eller denne afstemningsapp—så vi kunne tage imod stemmer fra livepublikummet og vise resultaterne i stedet for at betale for noget, der gjorde det. For ofte har apps den funktion, men man skal betale for den, og så betaler man for alle de andre funktioner, man ikke rigtig bruger.

Jeg interesserer mig kun for afstemningen, så jeg byggede det hele, så jeg kunne oprette mine egne afstemninger. Jeg kan give den det navn, jeg vil, tilføje så mange valgmuligheder, som jeg ønsker, og forhåndsvise den, før den går live. Derefter kan jeg enten starte dem herfra, slå dem fra, slette dem og så videre. Og det er sådan, de vises på skærmen.

I stemmer altså på den app, jeg har skabt. Jeg indsamler ikke nogen data fra jer. Bare rolig. Det hele ligger bare her. Og ja, det var sådan, vi så resultaterne. Det var noget, jeg satte sammen. Jeg arbejdede faktisk på det 30 minutter før dette opkald, men i alt tog det nok en til to timer bare at sætte det sammen og give det noget branding, som jeg syntes så pænt ud.

Men jeg er heller ikke designer, så tag ikke imod designråd fra mig.

Katie Sanders: Ja, vi har talt om fordelene her. Der er naturligvis nogle, der leger med det og tror, at de aldrig får brug for tekniske folk igen. Men der er dette eksempel med en fyr, der hedder Leo Junior.

Hans opslag gik viralt på X, men han er grundlægger af Enrich Lead, et værktøj, der indsamler IP-adresser og bruger en LLM til at generere salgsemner. Han byggede hele appen med Cursor, og han sagde meget stolt: Nul håndskrevne linjer kode, AI er byggeren. Man kan beklage sig over det, eller man kan begynde at bygge—meget selvsikkerhed og ingen ydmyghed.

Så internettet valgte naturligvis vold, og inden for 48 timer overtog hackere det hele. Hans abonnementer blev omgået, hans omkostninger steg voldsomt, og LLM’en begyndte at hallucinere kundeemnedata ud af den blå luft. Så Leo måtte skrive et SOS-opslag på Twitter og sige: Hej, jeg er under angreb. Der sker tilfældige ting.

Jeg er ikke teknisk, så det tager mig længere end normalt at finde ud af det. Så nu lærer han at kode på den hårde måde. Så igen er lektien, at man altid har brug for et menneske i processen. Det er sjovt at lege med som ikke-teknisk person, men man har altid brug for en teknisk person til at gennemgå koden.

Hannah Clark: Michael, vil du give folk en hurtig gennemgang af, hvordan læringskurven var for dig, da du først begyndte at lege med værktøjerne?

Michael Mordak: Selvfølgelig. Som jeg sagde, har jeg meget begrænset viden om kodning, og det er noget, jeg nogle gange ser, når folk siger: Jeg er en idémenneske.

Jeg har aldrig faktisk bygget noget før, og det er 100 % den lejr, jeg tilhører, fordi jeg ofte tænker på forskellige måder, jeg kan reducere interne processer på eller gøre ting uden at skulle betale for tredjepartsapps. Men faktisk at bygge det er svært.

Som svar på Grands spørgsmål om, hvordan læringskurven er i praksis: Det værktøj, vi skal bruge i dag, er Lovable, og det bliver nogenlunde det samme med de andre apps, der findes. Læringskurven er ærligt talt meget gradvis. Den var meget lav, fordi det, som I kan se, bare er tekstprompter.

Du beskriver præcis, hvad du gerne vil se, hvad dit mål med at bygge appen er, og hvilke resultater du gerne vil opnå. Derefter kommer den med nogle eksempler på, hvad den kan bygge for dig. Men du kan også give den yderligere detaljer. Hvis du har noget, du tager udgangspunkt i—for eksempel sagde jeg til denne, at jeg ville have, at den skulle ligne slido.com, som er en afstemningsapp, hvis du kender Slido.

Den kan altså bruge eksempler fra den virkelige verden som grundlag, og derefter kan du indtaste din egen branding og alle andre krav, som appen skal opfylde. Når den første version er bygget, er det heller ikke slutningen. Du kan fortsætte med at chatte med den.

Der er en chattilstand, så du kan stille den spørgsmål, før den faktisk ændrer koden eller bygger noget. Derudover fandt jeg ud af, at det også fungerede godt for mig, når tingene blev lidt for tekniske: Jeg tog nogle af de ting, Lovable fortalte mig, at jeg gjorde, kopierede dem ind i ChatGPT og sagde: Forklar det her, som om jeg er fem år.

Så gjorde den det mere forståeligt for en som mig, der ikke forstår alle de tekniske detaljer, og forklarede det virkelig grundigt. Så ja, det var en meget smidig proces, og det gjorde det virkelig nemt at prøve at bygge noget som dette.

Hannah Clark: Det er så sejt. Og jeg håber, det er opmuntrende for os, der starter helt fra bunden, inklusive mig selv.

Jeg ville gerne tage et spørgsmål op fra Tal. Vi stiller det til Drew. Tal spørger: Hvad vil du foreslå som en god arbejdsgang for eksisterende produktvirksomheder? Jeg er PM i en startup. Vi har et designsystem og et fungerende produkt med brugere. Hvorfor tror du, at jeg kan bruge Vibe Coding til specifikke funktioner eller idéer?

Og hvornår skal det tilbage til design, eller springer det designet over og går direkte til udvikling?

Drew Falkman: Jeg tror, at hele denne arbejdsgang stadig er 100 % under udvikling. Der findes endnu ingen bedste praksis. Det er stadig det vilde vesten, når det gælder om at samle alt dette. Men hvis jeg var i en virksomhed, ville jeg springe designet over, men koordinere med designeren.

Jeg ville gøre det sådan, og jeg viser jer min vibe-PRD. Jeg ville samle noget, der på en måde beskriver skærmene og elementerne. Sørg nu for at få designerens opbakning. De kan også være samarbejdspartnere på dette. Husk, at det ikke er noget, vi skal gøre isoleret. Vi kan alle se det samme projekt og arbejde på det sammen.

Derefter ville jeg skabe det. Jeg kender ikke nogen magisk måde—i hvert fald ikke med Lovable—at integrere designsystemer på. Nogle af de andre værktøjer, som Cursor, er faktisk værktøjer på et lavere niveau til dette, fordi du kan koble chats og alt muligt til, men du arbejder reelt i koden.

I et integreret udviklingsmiljø, og det kræver ofte, at man kører noget på kommandolinjen. Så det er lidt mere teknisk for helt ikke-tekniske personer, men det giver mulighed for mere kodeintegration og interaktion. Så det kan være et bedre værktøj til denne anvendelse. Hvis jeg gjorde det her, ville det faktisk synkronisere begge veje med GitHub, hvilket jeg vil prøve at vise, hvis vi har tid i dag.

Du kunne altså lave en iteration af en skærm og lægge den på GitHub. Derefter kunne dine udviklere hente den ned. De kunne anvende alle deres komponenter og designsystemer og sende den tilbage. Når du så gik ind igen, burde du kunne se alt det, og det burde forhåbentlig—ideelt set—fungere fantastisk.

Hannah Clark: Fantastisk. Dette spørgsmål er fra Donald til Drew. Hvad er din erfaring med vibe coding af noget, der er mere en kopi, i parentes via en anden opgavestyring, sammenlignet med noget, der er mere unikt, som en sonificering af Google Trends-data? Med andre ord: vibe coding af noget, der minder om en version af noget, der allerede findes i mange udgaver, kontra noget, der er en helt uhørt og aldrig før udforsket idé.

Drew Falkman: Det er et godt spørgsmål. Min generelle erfaring med prototypingsværktøjer og vibe coding-værktøjer er, at alt, der allerede findes, er forholdsvis enkelt. Det kan de tilføje, og de forstår det. Vores standardeksempel i dag er en rejseapp. Det kan de lave hele dagen, men når du kommer til noget som sonificering af Google Trends-data, bliver det mere af en kamp.

Og jeg vil tilføje, at hvis du bevæger dig ind på noget, der kræver meget specialiserede visualiseringsværktøjer ud over dine almindelige brugerfladeelementer med rullemenuer, knapper og den slags, kommer du til at kæmpe med den slags værktøjer, i hvert fald med Lovable og på det stadie, vi er på nu.

Der findes måske andre værktøjer, der gør det lettere, men lige nu er det ting, hvor du får brug for at hente eksperter ind og arbejde sammen med dem, hvis du laver noget vildt og virkelig langt fra normen.

Hannah Clark: Okay. Det bringer os til tiden. Jeg vil gerne sige en kæmpe tak til Katie for at være med og naturligvis til Drew for at være en fantastisk ressource og for at stille sin tid og ekspertise til rådighed.

Tak, fordi I lyttede med. Hvis du vil have flere gode indsigter, vejledninger og anmeldelser af værktøjer, så abonner på vores nyhedsbrev på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved at abonnere på The CPO Club, uanset hvor du får dine podcasts.