Vibe Coding 101: Een praktische workshop van nul naar één

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot is niet altijd 100% correct.

Hannah Clark: Goed, mensen. Een disclaimer bij deze aflevering: als je al een expert bent in Vibe Coding, is deze aflevering misschien niets voor jou. Maar als je van Vibe Coding hebt gehoord en de feiten van de mythes wilt onderscheiden, en je benieuwd bent hoe je deze technologie kunt gebruiken om je eigen doelstellingen te bereiken, dan ga je dit geweldig vinden.

Als je onze nieuwsbrieven niet hebt gevolgd, zoals de nieuwsbrieven waarop je je kunt abonneren via theproductmanager.com/subscribe, dan weet je misschien niet dat ik niet kan ophouden met praten over de geweldige praktische workshop over Vibe Coding die we een paar weken geleden hebben georganiseerd met Drew Falkman, hoofdadviseur bij Moves The Needle. Deze aflevering van de Product Manager Podcast is eigenlijk een opname van het seminar van dertig minuten dat we hielden voordat we aan onze live prototypesessie begonnen. Je hoort wat vibe coding wel en niet is, inspirerende toepassingen van de technologie en aanbevelingen voor tools waarmee je zelf kunt experimenteren en toepassingen kunt ontdekken. Laten we beginnen.

O, en trouwens, we voeren elke week gesprekken zoals dit. Dus als dit je interessant lijkt, waarom zou je je dan niet abonneren? Goed, laten we beginnen.

Ik ben Hannah Clark. Als je me niet kent: ik ben de hoofdredacteur van The CPO Club en de presentator van de podcast van The CPO Club. En ik heb mijn co-host Katie bij me.

Katie Sanders: Hallo allemaal, ik ben Katie Sanders. Ik ben hoofdredacteur bij The CTO Club. Misschien ook van The QA Lead. Er zijn mensen die niet weten dat we die sites hebben samengevoegd. Ik heb er dus veel zin in. Dit is mijn eerste workshop en ik vind het geweldig om dit met Hannah te doen, want er is veel overlap tussen productteams en CTO’s. Dus ja, ik kijk ernaar uit om iedereen te leren kennen. Welkom!

Hannah Clark: Ik vind het geweldig om hier met Katie aan te werken. Als je haar nog niet volgt op LinkedIn: Katie Sanders, ze is echt geweldig. Ze maakt geweldige content, dus ik kijk er echt naar uit dat jullie elkaar leren kennen.

Ik wil onze gastspreker ook graag introduceren. Drew Falkman is hier. Drew is een productleider, adviseur en docent die zich richt op productstrategie voor bedrijven van de pre-seed- tot de seedfase. Hij stroomlijnt vroege teams. Hij optimaliseert de product-marktfit.

Hij heeft het allemaal gedaan. Hij is een goede vriend van deze publicatie. Hij heeft veel met ons samengewerkt. En hij heeft veel met mij samengewerkt, wat betekent dat hij een zeer geduldig man is. Jullie zijn vandaag dus in goede handen. Hij heeft bovendien veel ervaring met web-, mobiele, blockchain- en AI-producten. We hebben hier dus een fantastische expert.

Drew, wil je de aardige mensen even begroeten?

Drew Falkman: Hoi allemaal, ik vind het geweldig om hier te zijn. Dit wordt leuk.

Hannah Clark: We beginnen met het ontkrachten van een paar mythes. Ik trap af met de eerste vraag en daarna neemt mijn geweldige co-host Katie enkele mythes door, waarna Drew ze voor ons zal ontkrachten. We beginnen met wat context.

Het lijkt wel alsof iedereen het momenteel over vibe coding heeft en het in elke LinkedIn-post voorbij komt, ook in veel van die van mij. Mensen lijken er óf heel enthousiast óf heel bang óf heel verward door te zijn. Laten we daarom bespreken waarom Vibe Coding zo populair is. Waarom is het juist nu zo belangrijk? Laten we de mythe daarover bespreken.

Katie Sanders: Goed, de eerste mythe: vibe coding vervangt engineers. Er wordt natuurlijk veel gezegd dat AI in het algemeen ieders baan vervangt. Ik zou zeggen dat dat een mythe is en dat het de baan van engineers misschien verandert en code oplevert die klaar is voor gebruik in apps, maar het vervangt de baan van een engineer zeker niet volledig.

Zoals altijd bij AI willen we een mens in de lus houden. Ik zou dus zeggen dat er niets wordt uitgebracht zonder menselijke controle, en daarom denk ik dat we deze mythe kunnen ontkrachten.

Hannah Clark: Drew, heb je daar nog iets aan toe te voegen?

Drew Falkman: Ja, ik zou zeggen dat een engineer zich ervan bewust moet zijn dat dit eraan komt.

Het kan je proces gewoon versnellen. En als designer, productmanager of niet-technische oprichter hebben jullie nu de mogelijkheid om MVP’s te maken, prototypes te creëren en te valideren en allerlei dingen te doen, waarna je ze aan engineers kunt overdragen. Wanneer je naar code op productieniveau wilt, over het algemeen na een MVP, heb je engineers nodig.

Tegenwoordig moet je zeker codebeoordelingen uitvoeren en alles nalopen om ervoor te zorgen dat alles goed is aangescherpt, vooral als er sprake is van compliancekwesties of andere zaken waarvan je op de hoogte moet zijn.

Hannah Clark: We gaan verder met mythe nummer twee. Sommige mensen zeggen dat vibe coding buiten de ontwikkelcyclus staat.

Met andere woorden: als je iets bouwt in een vibe-codingapp, is het volgens hen niet echt bruikbaar en moet je het volledig opnieuw opbouwen vanaf de grond met een developer die alles met de hand codeert. Drew, klopt dat echt?

Drew Falkman: De tools zijn enorm geëvolueerd en het is een van die dingen die letterlijk elke dag veranderen.

Claude heeft de afgelopen maand of zo een nieuwe versie van zijn codegeneratie uitgebracht en die is mijlenver beter dan voorheen. Het wordt dus voortdurend beter. Net als alle generatieve AI kan het hallucineren, rare dingen doen en onverwachte dingen uitvoeren. Als onderdeel van de cyclus kan het in die cyclus worden opgenomen en kun je daadwerkelijk dit soort codeonderdelen creëren.

Je kunt ze aan engineers overdragen, maar je moet je er goed van bewust zijn dat ze waarschijnlijk moeten worden aangepast. Misschien moet je sommige componenten opnieuw gebruiken, en ik denk dat sommige engineers er verbaasd over kunnen zijn hoe goed de code daadwerkelijk is.

Hannah Clark: Goed. Een andere mythe die ik vaak hoor, is dat je geen PRD of productstrategie nodig hebt om een tool met vibe coding te maken.

Drew, Katie, wat vinden jullie daarvan?

Drew Falkman: Kijk, je moet altijd nadenken. Volgens mij denken mensen soms: als ik aan vibe coding doe, kan ik gewoon beginnen, het openen en morgen een app hebben. Maar net als met alles geldt: als je er niet van tevoren over nadenkt, wordt het niet wat je wilt. Je moet nadenken over wie je doelgroep is en wie je doelmarkt is.

Je wilt nadenken over je waardepropositie. Je wilt nadenken over de kernfuncties en -stromen in de app. Het is dus echt de moeite waard om iets op te stellen. Het mooie is dat je geen PRD van vijf tot tien pagina’s hoeft te maken waarin je de te gebruiken technologie definieert en alle stromen en dergelijke uittekent.

Daar hoef je niet over na te denken. Je wilt alleen schetsen wat je visie is en wat je bouwt. Ik heb zelfs een kleine vibe-PRD opgesteld. Die is één tot twee pagina’s lang en bedoeld voor jou en iedereen met wie je misschien samenwerkt, zodat jullie op één lijn zitten en het georganiseerd kunnen aanpakken.

En zodat je code op de lange termijn schoner is.

Hannah Clark: Goed om te weten. We gaan door naar de volgende mythe, over sterk gereguleerde sectoren. Katie vertegenwoordigt The CTO Club, dus wil jij deze mythe behandelen, Katie?

Katie Sanders: Ja, ik denk dat er nog één ding is dat ik wil benoemen: dat dit nieuw is. We doen al jaren aan vibe coding.

We noemden het alleen tot voor kort niet zo. Denk aan code kopiëren en plakken van GitHub, Reddit of Hacker News, waar dan ook. Goede engineers lossen problemen op. Ze zoeken, herkennen patronen, passen aan en bouwen. Ik denk dus dat deze prompt simpelweg de volgende evolutie is van iets wat er altijd al is geweest. En Hannah, welke andere mythe wilde jij ontkrachten?

Hannah Clark: Dat je niet aan vibe coding kunt doen als je in een sterk gereguleerde sector werkt. Dat het niet veilig is.

Katie Sanders: Ja. Als we aan bijvoorbeeld de gezondheidszorg of financiën denken, zijn dat sterk gereguleerde sectoren. Net als in elke andere sector moet je ervoor zorgen dat je aan de HIPAA-vereisten en al die andere regels voldoet.

Ik weet dat LLM’s soms informatie kunnen ophalen. Denk dus aan compliancekwesties, echt binnen de sector. Maar ik denk dat er een extra veiligheidslaag is wanneer je aan gezondheidszorg, financiën of iets dergelijks denkt.

Hannah Clark: Ja, ik denk dat het net als veel verschillende ontwikkelprocessen is: de tools voor vibe coding vervangen je personeel niet.

Ze zijn slechts een aanvulling om de ontwikkelcyclus te versnellen. Maar een goed, grondig proces voor codebeoordeling is waarschijnlijk belangrijker dan ooit, nu we een deel van dat werk uitbesteden. Goed, laten we het hebben over enkele toepassingen. Het is leuk om een paar verschillende manieren te verkennen waarop mensen vibe coding momenteel effectief gebruiken.

Katie neemt dit gedeelte van de show voor haar rekening en bespreekt enkele toepassingen die behoorlijk interessant waren.

Katie Sanders: Veel hiervan heb ik eigenlijk van Reddit gehaald toen Vibe Coding net opkwam. Ik wilde voorbeelden uit de echte wereld zien. Iedereen had het erover, maar ik kon niet echt iets zien dat succesvol was.

Daarom schreef ik er een artikel over. Een van de dingen die we bespraken, was iemand die volgens mij een soort voetbalapp had gebouwd: een organisator voor nichevoetbalwedstrijden, puur als persoonlijke hobby. Hij was geen developer, maar begreep hoe full-stackapps werken en had altijd developers moeten inhuren om zijn ideeën tot leven te brengen.

Toen hij begon te experimenteren met Lovable, Cursor en al die andere tools, bouwde hij deze nichevoetbalapp. Die hielp hem zijn wekelijkse wedstrijden te organiseren en uiteindelijk bracht hij die volgens mij succesvol uit. Ja, hij bracht binnen enkele weken een winstgevende, door AI gegenereerde app met honderd regels code uit. Volgens mij leverde die iets van 700 dollar per week op, of niet, Michael?

Was het ongeveer 700 dollar per week? Een ander voorbeeld dat we vonden heette Workaid. Dat was een door AI aangedreven, gegamificeerd taakbeheersysteem. Het verandert je takenlijst in een spelachtige ervaring. Dat waren dus een paar succesvolle voorbeelden die ik van Reddit heb gehaald. We kunnen jullie naar dat Reddit-bericht doorverwijzen.

Er waren nog enkele voorbeelden en ik denk dat veel mensen hier gewoon mee gaan experimenteren. Maar er zullen ook mensen zijn die hier echt succesvol mee worden, en dat is heel interessant om te zien.

Hannah Clark: Ja, dat is een heel mooi voorbeeld. Ik wilde alleen snel iets onderbreken, want we hebben een goede vraag van Katya.

Katya vraagt: ik vroeg me af of ik als PM nog steeds wireframes en mock-ups voor de frontend moet maken. Ik zou die gewoon met vibe coding kunnen maken en de developers kunnen mijn frontend als uitgangspunt voor hun eigen ontwikkeling gebruiken.

Drew Falkman: Ja, absoluut. Ik zou zelfs zeggen dat het met de meeste van deze tools moeilijker is om met Vibe Coding een bestaand ontwerp te implementeren.

Het is lastig om schermen te importeren en dat allemaal te doen. Het is eigenlijk makkelijker om het te definiëren. Je kunt met de generatieve AI samenwerken om de uitstraling en het gevoel goed te krijgen, en het daarna aan hen overdragen. Zij kunnen ervoor zorgen dat het voldoet aan elk ontwerpsysteem of andere richtlijn die je gebruikt.

Hannah Clark: Bedankt dat je die vraag hebt beantwoord, Drew. Sorry Katie, dat ik je onderbrak. Wilde je verdergaan met de toepassingen? Ik weet dat je nog een paar voorbeelden hebt.

Katie Sanders: Michael, wil jij delen dat we een toepassing hebben van iemand binnen ons bedrijf? Die persoon heeft een analysetool voor de impact van ontslagen gemaakt. Michael, wilde jij dat als geweldig voorbeeld toelichten?

Michael Mordak: Zeker. Dit is een geweldig voorbeeld dat een van onze collega’s op diens site heeft gebruikt. Die collega werkt voor een HR-publicatie en wilde een tool bouwen waarmee mensen de impact van een ontslag konden analyseren als ze van plan waren personeel te ontslaan. Hij heeft het zo gecodeerd, of beter gezegd door een bot laten coderen, dat mensen die het willen gebruiken eerst een enquête moeten invullen.

Op die manier verzamelt hij gegevens over de mensen die de tool gebruiken, iets wat hij voor zijn eigen doeleinden wilde doen. Nadat je de enquête hebt ingevuld, brengt de app je naar deze calculator. Er zijn enkele voorbeelden in gebouwd. Als je bijvoorbeeld bij een productiebedrijf werkt en 200 medewerkers wilt ontslaan, kun je dat voorbeeld selecteren om te zien hoe het werkt.

Je vult in wezen allerlei details in en beantwoordt vragen als: hoeveel kennis hebben deze mensen? Hoeveel tijd zou het kosten om iemand voor deze functie opnieuw op te leiden? Vervolgens kun je de impact van het ontslag berekenen en vertelt de tool je precies welk effect dit zal hebben.

Dit zou een geweldige tool zijn voor mensen in HR die een ontslag plannen. Hij stelt de tool gratis beschikbaar aan mensen die ermee willen spelen en feedback willen geven. Dat is dus één voorbeeld van iemand uit ons team. Het tweede voorbeeld dat ik kan delen, is de peilingstool die we net gebruikten. Die heb ik zelf gecodeerd.

Ik heb geen of in ieder geval zeer weinig ervaring met coderen. Ik heb deze peilingapp gebouwd zodat we stemmen uit het livepubliek konden verzamelen en de resultaten konden weergeven, in plaats van te moeten betalen voor iets dat dit deed. Vaak hebben apps dit als functie, maar moet je ervoor betalen en betaal je ook voor alle andere functies die je niet gebruikt.

Ik geef alleen om de peiling, dus heb ik dit gebouwd zodat ik mijn eigen peilingen kan maken. Ik kan de peiling elke gewenste naam geven en zoveel opties toevoegen als ik wil. Ik kan een voorbeeld bekijken voordat de peiling live gaat en ze vanaf hier starten of uitschakelen, verwijderen enzovoort. Zo worden ze op het scherm weergegeven.

Jullie stemmen dus op de app die ik heb gemaakt. Ik verzamel geen gegevens van jullie, maak je geen zorgen. Alles blijft hierin staan. En ja, zo zagen we daar die resultaten. Ik heb dit gewoon in elkaar gezet. Ik werkte er dertig minuten voor deze oproep aan, maar in totaal kostte het waarschijnlijk één tot twee uur om dit te bouwen en er een huisstijl aan toe te voegen die ik er mooi uit vond zien.

Maar ik ben ook geen designer, dus neem geen tips van mij aan.

Katie Sanders: Ja, we hebben de voordelen besproken. Natuurlijk zijn er mensen die hiermee experimenteren en denken dat ze nooit meer iemand met technische kennis nodig zullen hebben. Er is dit voorbeeld van een man, Leo Junior.

Zijn bericht ging viraal op X. Hij is de oprichter van Enrich Lead, een tool die IP-adressen verzamelt en een LLM gebruikt om verkoopleads te genereren. Hij bouwde de volledige app met Cursor en zei trots: nul regels handgeschreven code, AI is de bouwer. Je kunt erover klagen of je kunt beginnen met bouwen. Heel veel bravoure en weinig nederigheid.

Het internet koos natuurlijk voor de aanval. Binnen 48 uur namen hackers het over, werden zijn abonnementen omzeild en schoten zijn kosten omhoog. De LLM begon leadgegevens uit het niets te verzinnen. Leo moest daarom een SOS-bericht op Twitter plaatsen met de boodschap: hé, ik word aangevallen, er gebeuren willekeurige dingen.

Ik ben niet technisch, dus het duurt langer dan normaal om dit uit te zoeken. Nu leert hij dus op de harde manier coderen. De les is opnieuw dat je altijd een mens in de lus nodig hebt. Als niet-technisch persoon is het leuk om hiermee te experimenteren, maar je hebt altijd een technisch persoon nodig die de code beoordeelt.

Hannah Clark: Michael, wilde jij mensen misschien kort vertellen hoe de leercurve voor jou was toen je voor het eerst met deze tools begon te experimenteren?

Michael Mordak: Zeker. Zoals ik zei, heb ik zeer beperkte kennis van coderen. Ik zie soms dat mensen zeggen: ik ben een ideeënmens.

Ik heb nog nooit zoiets gebouwd en dat is precies de groep waar ik onder val. Ik denk vaak na over verschillende manieren om interne processen te verkorten of dingen te doen zonder voor apps van derden te hoeven betalen, maar het daadwerkelijk bouwen ervan is moeilijk.

Als antwoord op de vraag van Grand over hoe de leercurve er in de praktijk uitziet: de tool die we vandaag gaan gebruiken is Lovable, en dat zal vergelijkbaar zijn met de andere apps die beschikbaar zijn. De leercurve is eerlijk gezegd heel geleidelijk. Hij was erg laag, omdat het gewoon om prompts in tekstvorm gaat.

Je beschrijft precies wat je wilt zien en wat je doel is bij het bouwen van de app, inclusief de resultaten die je wilt bereiken. Vervolgens geeft de tool voorbeelden van wat hij voor je zou kunnen bouwen. Je kunt ook aanvullende details geven. Als je bijvoorbeeld iets hebt waarop je je baseert, kun je zeggen: ik wil dat dit eruitziet als slido.com. Als je Slido kent, weet je dat het een peilingapp is.

De tool kan dus voorbeelden uit de echte wereld gebruiken als basis. Daarna kun je je eigen huisstijl en andere vereisten invoeren waaraan de app moet voldoen. Wanneer de eerste versie is gebouwd, is dat niet het einde. Je kunt ermee blijven chatten.

Er is een chatmodus waarin je vragen kunt stellen voordat de tool daadwerkelijk code wijzigt of iets bouwt. Wat voor mij ook goed werkte, was dat ik, wanneer iets mijn kennis te boven ging, delen van de uitleg van Lovable meenam, die in ChatGPT plakte en vroeg: leg dit uit alsof ik vijf jaar oud ben.

Zo werd het vereenvoudigd voor iemand zoals ik, die niet alle technische details begrijpt, en werd het heel grondig uitgelegd. Het was dus een heel soepel proces en het maakte het gemakkelijk om zoiets te proberen te bouwen.

Hannah Clark: Dat is zo gaaf. Ik hoop dat dit bemoedigend is voor degenen onder ons, inclusief mezelf, die echt vanaf nul beginnen.

Ik wil hier een vraag van Tal bespreken en die aan Drew voorleggen. Tal vraagt: wat zou volgens jou een goede workflow zijn voor bestaande productbedrijven? Ik ben een PM bij een startup. We hebben een ontwerpsysteem en een werkend product met gebruikers. Waarom denk je dat ik Vibe Coding kan gebruiken voor specifieke functies of ideeën?

En wanneer gaat het terug naar design, of wordt design overgeslagen en gaat het rechtstreeks naar development?

Drew Falkman: Ik denk dat deze volledige workflow momenteel volop in ontwikkeling is. Er zijn nog geen best practices. Het is nog steeds het wilde westen als het gaat om dit alles samenbrengen. Maar als ik bij een bedrijf zou werken, zou ik design overslaan en wel met de designer afstemmen.

Ik zou mijn vibe-PRD gebruiken. Ik zou iets opstellen waarin de schermen en elementen worden beschreven. Zorg er wel voor dat je draagvlak bij de designers krijgt. Zij kunnen hier ook aan meewerken. Vergeet niet dat we dit niet geïsoleerd hoeven te doen. We kunnen allemaal naar hetzelfde project kijken en er samen aan werken.

Daarna zou ik het maken. Voor zover ik weet is er in Lovable geen magische manier om ontwerpsystemen te integreren. Sommige andere tools, zoals Cursor, zijn hiervoor een hulpmiddel op een lager niveau, omdat je chats en dergelijke kunt invoegen, maar je werkt dan echt in de code.

In een geïntegreerde ontwikkelomgeving moet je vaak ook iets via de opdrachtregel uitvoeren. Dat is dus wat technischer voor volledig niet-technische mensen, maar het biedt wel meer integratie en interactie met code. Dat kan voor deze toepassing dus een betere tool zijn. Als ik het hier zou doen, zou ik een tweewegsynchronisatie met GitHub gebruiken, wat ik vandaag zal proberen te laten zien als we tijd hebben.

Je zou een versie van een scherm kunnen maken en die naar GitHub kunnen plaatsen. Vervolgens kunnen je developers die ophalen. Zij kunnen al hun componenten en ontwerpsystemen toepassen en het weer terugplaatsen. Wanneer je daarna teruggaat, zou je al die zaken moeten kunnen zien en zou het idealiter goed moeten werken.

Hannah Clark: Geweldig. Deze vraag komt van Donald en is voor Drew. Wat is je ervaring met vibe coding voor iets dat meer een kopie is, bijvoorbeeld van een andere taakbeheerder, tegenover iets uniekers, zoals een sonificatie van Google Trends-gegevens? Met andere woorden: vibe coding voor iets dat lijkt op een versie van iets wat al op grote schaal bestaat, tegenover een volledig ongehoord en nog nooit eerder uitgevoerd idee.

Drew Falkman: Dat is een goede vraag. Mijn ervaring met prototypingtools en vibe-codingtools in het algemeen is dat alles wat al bestaat redelijk eenvoudig is. De tools begrijpen het. Ons standaardvoorbeeld vandaag is een reisapp. Dat kunnen ze de hele dag maken. Maar zodra je iets krijgt als sonificatie van Google Trends-gegevens, wordt het meer een strijd.

Ik zou eraan toevoegen dat je met deze tools, in ieder geval met Lovable en op het punt waar we ons vandaag bevinden, zult worstelen met alles wat buiten de standaardinterface-elementen valt, zoals vervolgkeuzemenu’s en knoppen, en waarvoor zeer aangepaste visualisatietools nodig zijn.

Er zijn misschien andere tools die dit eenvoudiger maken, maar op dit moment zijn dit zaken waarvoor je hulpmiddelen moet inschakelen en waarmee je moet samenwerken als je iets geks en echt afwijkends bouwt.

Hannah Clark: Goed, daarmee zijn we aan het einde van onze tijd. Ik wil Katie enorm bedanken dat ze hieraan heeft deelgenomen, en natuurlijk Drew, omdat hij zo’n geweldige bron is en zijn tijd en expertise vrijwillig heeft ingezet.

Bedankt voor het luisteren. Abonneer je voor meer geweldige inzichten, praktische handleidingen en toolrecensies op onze nieuwsbrief via theproductmanager.com/subscribe. Je kunt meer gesprekken zoals dit beluisteren door je te abonneren op The CPO Club, waar je je podcasts ook beluistert.