Vibe Coding 101: Un laboratorio pratico da zero a uno

Leggi la trascrizione:

Stiamo provando a trascrivere i nostri podcast utilizzando un programma software. Per favore perdona eventuali errori di battitura poiché il bot non è sempre corretto al 100%.

Hannah Clark: Bene, ragazzi. Avviso per l’episodio—se siete già esperti nel Vibe coding, forse questo episodio non fa per voi. Ma se avete sentito parlare di Vibe Coding e volete sapere i fatti rispetto ai miti, e siete curiosi su come potete usare questa tecnologia per raggiungere i vostri obiettivi, allora adorerete questo episodio.

Se non avete seguito le nostre newsletter, come quelle a cui potete iscrivervi su theproductmanager.com/subscribe, non ho smesso di parlare dell’incredibile laboratorio pratico di Vibe Coding che abbiamo tenuto qualche settimana fa con Drew Falkman, Principal di Moves The Needle. Questo episodio del Product Manager Podcast è in realtà una registrazione del seminario di 30 minuti che abbiamo fatto prima di iniziare la nostra sessione di prototipazione live. Sentirete una spiegazione di cosa sia (e non sia) il vibe coding, casi d’uso ispirazionali della tecnologia e consigli su strumenti per iniziare a sperimentare e scoprire i vostri casi d’uso. Iniziamo.

A proposito, teniamo conversazioni come questa ogni settimana. Quindi se vi sembra interessante, perché non iscrivervi? Ok, ora entriamo nel vivo.

Sono Hannah Clark. Se non mi conoscete, sono la Executive Editor per The CPO Club e sono la conduttrice del podcast The CPO Club. E c’è anche la mia co-conduttrice, Katie.

Katie Sanders: Ciao a tutti, sono Katie Sanders. Sono Executive Editor al The CTO Club. Forse anche da The QA Lead. Alcuni di voi sapranno che abbiamo accorpato quei siti. Sono entusiasta. Questo è il mio primo laboratorio e sono davvero contenta di farlo con Hannah, perché c’è tanta sinergia tra prodotto e CTO. Quindi sono felice di conoscervi tutti. Benvenuti!

Hannah Clark: Sono molto felice di lavorare con Katie per questo. Se non la seguite ancora su LinkedIn, Katie Sanders, è davvero tosta. Ha dei contenuti fantastici, quindi sono davvero entusiasta che vi possiate conoscere.

Vorrei anche presentare il nostro relatore d’eccezione. Abbiamo qui Drew Falkman. Drew è un leader di prodotto, advisor ed educatore specializzato nella strategia prodotto da pre-seed a seed. Ha ottimizzato team alle prime armi. Ottimizza il product-market fit.

Ha esperienza in tutto. È un grande amico della nostra pubblicazione. Ha lavorato spesso con noi. E ha lavorato molto con me, il che vuol dire che è un uomo molto paziente. Siete in buone mani oggi. Ha anche molta esperienza su prodotti web, mobile, blockchain e AI. Quindi abbiamo qui un esperto incredibile.

Drew, vuoi salutare tutti?

Drew Falkman: Ciao a tutti, sono molto entusiasta di essere qui. Sarà divertente.

Hannah Clark: Iniziamo sfatando qualche mito, e parto io con la prima domanda, poi la mia adorata co-conduttrice Katie approfondirà alcuni miti e Drew li sfaterà per noi. Partiamo dando un po’ di contesto.

Sembra che tutti parlino di vibe coding e viene fuori in ogni post su LinkedIn adesso, incluso molti dei miei. Le persone sembrano o molto entusiaste, o spaventate, o molto confuse. Parliamo quindi di perché il Vibe coding è così popolare. Perché è così importante ora? Tocchiamo il mito riguardo a questo.

Katie Sanders: Bene, primo mito: il vibe coding sta sostituendo gli ingegneri. Ovviamente c’è, in generale, chi dice che l’AI sta sostituendo tutti i lavori. Direi che è un mito, forse sta cambiando il lavoro dell’ingegnere e sta producendo codice pronto per l’app, ma di certo non sostituisce completamente il lavoro di un ingegnere.

Come sempre, con l’AI, vogliamo tenere un umano nel processo decisionale, quindi nulla sarà approvato senza che lo abbia visto una persona, e penso che possiamo sfatare questo mito.

Hannah Clark: Drew, vuoi aggiungere qualcosa?

Drew Falkman: Sì, dico solo che è qualcosa di cui essere consapevoli e attenti se sei un ingegnere, perché sta arrivando.

Potrebbe accelerare il tuo processo. E come designer, product manager o founder non tecnico, ora avete la possibilità di creare MVP, validare prototipi e realizzare attività, poi passare il tutto agli ingegneri. Quando si deve lavorare sul codice di produzione, in genere, oltre un MVP.

Al giorno d’oggi certamente sono necessarie code review, controlli e assicurarsi che tutto sia sistemato, specialmente se ci sono normative, compliance o altri temi di attenzione.

Hannah Clark: Passiamo al secondo mito. Alcuni dicono che il vibe coding sia un mondo separato dal ciclo di sviluppo.

Cioè, se costruisci qualcosa in una app di vibe coding, sembra non essere davvero utilizzabile e devi ricostruirlo da zero con uno sviluppatore che scrive tutto il codice a mano. Drew, è vero?

Drew Falkman: Gli strumenti sono evoluti moltissimo e sta cambiando letteralmente ogni giorno.

Claude ha appena rilasciato una nuova versione della generazione di codice, nell’ultimo mese circa, ed è molto meglio di prima. Quindi continua a migliorare. Come tutte le AI generative può “allucinare”, fare cose strane o inattese. Quindi può far parte del ciclo di sviluppo e puoi effettivamente creare questi pezzi di codice.

Consegnarli agli ingegneri, ma bisogna considerare che probabilmente servirà qualche aggiustamento. Potresti dover riutilizzare dei componenti e penso che alcuni ingegneri potrebbero essere sorpresi dalla qualità del codice.

Hannah Clark: Ok. Un altro mito molto comune è che non servano PRD o una strategia di prodotto per fare vibe coding su uno strumento.

Drew, Katie, cosa ne pensate?

Drew Falkman: Guarda, bisogna sempre pensare prima. Penso che spesso le persone credono che con vibe coding si possa semplicemente aprire lo strumento e avere una app nell’arco di un giorno. Ma come tutte le cose, se non ci pensi prima, non sarà quello che vuoi. Devi pensare al tuo pubblico, al target di mercato.

Pensa al valore che vuoi portare. Pensa alle funzionalità e ai flussi principali nell’app. Quindi vale la pena prendersi un po’ di tempo e mettere giù qualcosa. La bellezza è che non serve un PRD da 5-10 pagine dettagliato, che definisce tutte le tecnologie o flussi.

Non serve pensarci troppo. Basta delineare la visione, cosa si sta costruendo, e io ho creato un piccolo “vibe PRD”, di una o due pagine, giusto per te e chi collabora, così siete allineati e potete avvicinarvi con un approccio ordinato.

E avrete codice più pulito nel lungo periodo.

Hannah Clark: Buono a sapersi. Andiamo avanti al prossimo mito, sulle industrie altamente regolamentate. Katie rappresenta il CTO Club, volevi rispondere tu su questo?

Katie Sanders: Sì, un altro punto che volevo toccare è che non è nuovo. Ad esempio, facciamo vibe coding da anni.

Non lo chiamavamo così fino a poco tempo fa ma, copiare e incollare da GitHub, Reddit o Hacker News, qualsiasi ottimo ingegnere risolve problemi, cerca, adatta e costruisce. Questo prompt è solo l’ennesima evoluzione. E Hannah, qual era l’altro mito?

Hannah Clark: Solo che se sei in industrie altamente regolamentate allora non puoi fare vibe coding. Tipo, non è sicuro.

Katie Sanders: Sì. Ovviamente pensiamo alla sanità o alla finanza, settori molto regolamentati. Bisogna assicurarsi di essere conformi HIPAA e a tutte quelle normative.

So che gli LLM a volte possono pescare da altre fonti. Considerate bene le questioni di compliance nel vostro settore. Credo che serva una protezione extra nei settori come sanità o finanza.

Hannah Clark: Sì, è come in tanti processi di sviluppo: gli strumenti di vibe coding non sostituiscono il personale.

Sono solo un complemento per accelerare il ciclo di sviluppo. Ma, sì, processi rigorosi di code review sono probabilmente più cruciali che mai ora che si delega parte del lavoro. Ok. Vediamo alcuni casi d’uso. Sarà interessante esplorare vari modi in cui la gente sta usando il vibe coding in modo efficace oggi.

Katie guiderà questa parte e passerà in rassegna alcuni casi d’uso particolari.

Katie Sanders: In realtà, molti di questi li ho presi da Reddit quando il Vibe Coding stava nascendo. Volevo vedere esempi reali. Tutti ne parlavano, ma non trovavo casi di successo.

Così ho scritto un articolo e uno dei casi era una persona che ha costruito, credo fosse un’app di organizzazione di partite di calcio di nicchia, per hobby personale. Non era sviluppatore, ma capiva come funzionano le app full-stack e si era sempre affidato a sviluppatori per realizzare le sue idee.

Giocando con strumenti come lovable e cursor ecc. ha realizzato questa app per organizzare le sue partite e alla fine l’ha pubblicata con successo. Sì, ha lanciato una app AI da cento righe di codice generato, ottenendo profitti in poche settimane, penso che guadagnasse tipo, era Michael?

Tipo 700 dollari a settimana? Un altro esempio era Work Aid, un tool di task management gamificato alimentato da AI. Rivoluzionando la lista delle cose da fare, per rendere il lavoro come un gioco. Questi sono alcuni esempi di successo che ho trovato su Reddit e possiamo darvi il link al thread.

Ce ne erano altri, credo che molti si divertiranno a sperimentare, ma alcuni avranno davvero successo, il che è fantastico.

Hannah Clark: Sì, molto figo. Intervengo solo un attimo perché Katya ci ha mandato un’ottima domanda.

Katya chiede: come PM, servono ancora wireframe e mockup del front-end? Posso semplicemente crearli col vibe coding e poi i dev possono usare il mio front-end come punto di partenza?

Drew Falkman: Sì, al 100%. Anzi, direi che con la maggior parte di questi tool di vibe coding sarebbe più difficile implementare un design esistente.

È difficile importare schermate o simili. In realtà è più semplice definirle da zero e lavorare con l’AI generativa per ottenere l’aspetto giusto, poi passarle agli sviluppatori che potranno verificare la coerenza con il design system o altro.

Hannah Clark: Grazie per la risposta Drew. Scusa Katie, per l’interruzione. Vuoi tornare a parlare di altri casi d’uso? So che ne hai altri interessanti.

Katie Sanders: Michael vuoi condividere il caso interno? Un nostro collega ha creato il Layoff Impact Analyzer. Michael, vuoi parlarne?

Michael Mordak: Certo. Questo è uno dei casi migliori: un collega ha realizzato un tool per un sito HR, per aiutare chi pianifica dei licenziamenti a calcolare l’impatto delle uscite. Ha fatto sì che per usarlo bisogna prima compilare un breve sondaggio.

Così può raccogliere dati su chi lo utilizza, cosa che gli interessava. Una volta compilato il form si accede al calcolatore. Ci sono poi esempi preimpostati. Per esempio, se siete un’azienda manifatturiera e dovete licenziare 200 persone, potete vedere come funziona.

Si inseriscono vari dettagli, ad esempio quante competenze hanno queste persone, quanto tempo servirà per formare qualcuno di nuovo, e il tool calcola l’impatto del licenziamento indicando l’effetto concreto.

Quindi è utile per chi lavora in HR, lo offre gratuitamente a chi vuole provarlo e dargli feedback. È un esempio interno. Un altro esempio è lo strumento di sondaggi che usiamo: l’ho programmato io stesso.

Ho pochissima esperienza di coding, eppure ho creato quest’app per raccogliere voti dal pubblico in tempo reale e mostrare i risultati, senza dover acquistare soluzioni a pagamento.

Di solito sono opzioni costose, ma io volevo solo quella funzione. Così ho creato lo strumento, ci posso dare qualunque nome, scegliere le opzioni, vedere un’anteprima e lanciare o eliminare i sondaggi all’occorrenza. Poi vengono mostrati a schermo.

Quindi state votando sull’app che ho creato io. Non raccolgo dati, restano qui dentro. Così abbiamo visto i risultati. L’ho finito circa 30 minuti prima di questa call, ma in tutto avrò impiegato una o due ore per prepararlo e dargli un po’ di branding secondo i miei gusti.

Non sono un designer, quindi non prendete spunto da me.

Katie Sanders: Ecco, abbiamo discusso i vantaggi. Certo, c’è chi pensa di poter fare tutto senza nessuna competenza tecnica. Ma c’è un esempio: un certo Leo Junior.

Il suo post è diventato virale su X. È il founder di Enrich Lead, uno strumento che raccoglie indirizzi IP e usa un LLM per generare lead commerciali. Ha costruito tutta l’app usando Cursor, e diceva orgoglioso: zero righe di codice scritte a mano, tutto AI.

Puoi lamentarti o metterti a costruire, con molta arroganza.

Così però, in 48 ore, è stato hackerato: si sono bypassati gli abbonamenti, i costi sono saliti alle stelle, l’LLM ha iniziato a inventare dati di lead inesistenti. Leo ha dovuto chiedere aiuto su Twitter: sono sotto attacco, succedono cose strane.

Non sono tecnico, quindi ci metto più tempo. Ora sta imparando a programmare per forza. Quindi la lezione è che serve sempre un umano nel loop, ed è divertente giocare con questi strumenti anche per i non tecnici, ma serve sempre anche la revisione tecnica di esperti.

Hannah Clark: Michael, vuoi raccontare agli ascoltatori com’è stato il processo di apprendimento per te la prima volta che hai usato questi strumenti?

Michael Mordak: Certo. Come dicevo ho pochissima esperienza di coding, quindi mi riconosco in chi dice: “sono quello delle idee, non ho mai costruito nulla”. Anch’io cerco modi nuovi per risparmiare sulle app o semplificare processi interni senza ricorrere a tool esterni. Ma tradurre tutto ciò in realtà è difficile.

Grand chiedeva del learning curve usando lovable, ma vale anche per altri tool. In realtà la curva è davvero graduale. È tutto basato su prompt testuali.

Spieghi cosa vuoi vedere, quali risultati vorresti ottenere e il tool ti offre esempi di quello che potrebbe creare. Puoi fornire ulteriori dettagli; per il mio caso, ho detto che volevo qualcosa simile all’app slido.com, che fa sondaggi live.

Può prendere spunto da questi esempi e poi inserisci branding e altre necessità.

Una volta creata la prima iterazione, non è finita: puoi continuare a dialogare con il tool nella chat e chiedere spiegazioni, oppure fare altre modifiche.

Per me è stato utile anche prendere quanto suggerito da lovable, copiarlo su ChatGPT e farmelo spiegare con parole semplici, da principiante, per sciogliere ogni dubbio tecnico. Quindi è andata liscia e mi ha consentito di creare qualcosa facilmente.

Hannah Clark: Davvero interessante. Spero sia incoraggiante per chi, come me, parte davvero da zero.

Volevo rivolgere una domanda a Drew da parte di Tal. Tal chiede: quale workflow suggeriresti per aziende di prodotto? Sono PM in una startup, abbiamo un design system e un prodotto funzionante. Credi che possa usare il vibe coding per alcune funzionalità o idee specifiche?

E il lavoro torna poi al design, oppure va direttamente in sviluppo?

Drew Falkman: Questo workflow è tutto work in progress in questo momento. Non esistono best practice. È ancora il far west. Come lo farei io? Saltando la parte di design ma coordinandomi col designer.

Farei un piccolo documento – il mio vibe PRD – dove elenco schermate ed elementi. Tutto allineato con i designer che possono anche collaborare. Ricordate che non dobbiamo lavorare in silos: possiamo lavorare tutti insieme allo stesso progetto.

Poi andrei a creare ciò che serve. Non ho sentito parlare di una vera integrazione dei design system dentro lovable. Altri strumenti come Cursor sono più a basso livello, gestendo codice e chat, ma sono più tecnici.

Cursor dà maggiore possibilità di integrazione e personalizzazione, ma è più complicato per chi non è tecnico. Però permette più interazione sul codice. Su lovable invece si può fare il sync bidirezionale con GitHub, che mostrerò se abbiamo tempo.

Quindi puoi fare una iterazione su una schermata, mandarla su GitHub, i dev la scaricano, applicano componenti e design system e la rimandano su. E quando torni su lovable puoi vedere i cambiamenti e dovrebbe funzionare bene.

Hannah Clark: Ottimo. Questa è una domanda di Donald per Drew. Che esperienza hai con il vibe coding per qualcosa di simile ad altri task manager, rispetto a qualcosa di unico, tipo una sonificazione di dati Google Trends? Quindi, vibe coding per un clone di uno strumento noto versus idee originali mai fatte prima.

Drew Falkman: Bella domanda. In generale, la mia esperienza con tool di prototipazione e vibe coding è che ciò che già esiste è più semplice: li riconosce e li sa replicare. Ad esempio, oggi faremo un’app di viaggi. Quello va liscio. Ma se parliamo di sonification di dati Google Trends, diventa dura.

Se servono visualizzazioni custom diverse da normali elementi UI come menu a tendina o bottoni, con questi strumenti si fatica – almeno oggi, con lovable. Magari altro strumenti fanno meglio, ma per ora per idee fuori dagli schemi servono sviluppatori che intervengano.

Hannah Clark: Detto ciò, siamo in chiusura. Grazie mille a Katie per essere con noi e a Drew per la sua disponibilità e competenza.

Grazie per averci seguito. Per altri approfondimenti, guide pratiche e recensioni di strumenti, iscrivetevi alla nostra newsletter su theproductmanager.com/subscribe. Potete ascoltare altre conversazioni come questa abbonandovi a The CPO Club dove preferite ascoltare podcast.