Quando il vibe coding è la scelta giusta (e quando no)

Lo strumento giusto al posto sbagliato è uno strumento sbagliato. Il vibe coding non è la risposta universale: è un moltiplicatore di velocità in alcuni contesti e un moltiplicatore di rischio in altri. Il criterio decisivo non è “so usarlo”, è “posso leggere, testare e mantenere ciò che produce?”.

Perché questa lezione conta

Chiude il modulo introduttivo con un giudizio operativo: quali progetti generare, quali studiare prima, quali delegare a esperti, quali non fare proprio con AI. Senza questo giudizio, il vibe coding diventa default per tutto, e accumuli rischi di dominio (medico, finanziario, legale), di scala (single-user → produzione), o di responsabilità (codice in mano a utenti reali che non sai mantenere).

Obiettivo operativo

Alla fine devi saper:

1. classificare un progetto in una griglia rischio/reversibilità/competenza;
2. decidere “costruisci ora / studia prima / delega a esperti / non generare” con motivazione;
3. riconoscere il segnale che ti dice di cambiare categoria a metà progetto.

Nucleo della lezione

1. Casi favorevoli

Vibe coding ha alto valore quando coincidono almeno tre di queste condizioni:

• Pattern noto, dominio comune: CRUD, form, autenticazione standard, dashboard, parsing dati. Il modello ha visto migliaia di esempi.
• Reversibile: prototipo, esplorazione, strumento interno usato da poche persone, refactor isolato. Costo di sbagliare è basso.
• Verificabile da te: sai leggere il linguaggio, sai testare, sai cosa significa “funziona”.
• Bassa criticità: nessun dato sensibile, nessuna decisione finanziaria, nessuna responsabilità legale, nessun utente che si fa male se sbagli.
• Time-to-feedback breve: puoi eseguire e vedere il risultato in minuti, non in settimane.

Esempi concreti: tool interno per importare CSV, prototipo di landing con form, script di automazione personale, refactor di una funzione, generazione di test per codice esistente, documentazione tecnica.

2. Casi rischiosi

Il vibe coding aumenta il rischio quando:

• Sistemi critici: pagamenti, salute, sicurezza fisica, infrastruttura. Errore = danno reale.
• Dati sensibili: GDPR, PII, dati medici, credenziali. Una falla generata può essere costosa anche legalmente.
• Domini che non capisci: codice di calcolo finanziario senza conoscenze finance, parsing di formati medici senza standard. Non puoi verificare correttezza.
• Requisiti legali/regolamentari: il modello non conosce le specifiche normative del tuo settore.
• Performance/concorrenza: race condition, deadlock, ottimizzazioni a livello di sistema. Modelli fanno errori sottili difficili da catturare.
• Sicurezza non banale: crittografia custom, protocolli di autenticazione non standard, gestione token. Lì serve esperto, non plausibilità.

In questi casi le opzioni sono: studia prima (impari il dominio), delega a esperti (consulente con competenza specifica), o non fare proprio. Il vibe coding usato qui produce codice che sembra giusto e fallisce in produzione in modi gravi.

3. Il criterio decisivo: leggere, testare, mantenere

Tre domande prima di decidere:

• Leggere: capisci ogni file generato, riga per riga, senza dover chiedere al modello “cosa fa qui”?
• Testare: sai costruire test che verificano correttamente il comportamento? Sai distinguere test che funzionano da test che dicono di funzionare?
• Mantenere: fra sei mesi, quando arriverà un bug o una richiesta di modifica, saprai navigare la codebase e correggere senza ricominciare da zero?

Tre sì → procedi. Anche un solo no → rallenta: studia prima, riduci scope, o delega.

Procedura pratica

Scheda di valutazione per ogni progetto:

1. Dominio: comune (CRUD, form, dashboard) o specialistico (medico, finanziario, sicurezza)?
2. Reversibilità: posso buttare via e ricominciare? O c’è un costo (utenti, dati, contratti)?
3. Competenza personale: so leggere il linguaggio? Conosco lo stack? Capisco il dominio?
4. Criticità: cosa succede se sbaglia? Bug fastidioso, perdita dati, danno legale, danno fisico?
5. Verifica: posso testare end-to-end? Esiste una definition of done osservabile?

Calcola: se almeno 4 su 5 sono verdi → costruisci ora. 2-3 verdi → studia prima o riduci scope. <2 verdi → delega o non fare con AI.

Laboratorio guidato

Dieci idee di progetto, classifica ciascuna su una griglia 4x: rischio (basso/alto), reversibilità (alta/bassa), valore (alto/basso), capacità di verifica (alta/bassa).

Esempi di idee:

1. App di to-do personale offline.
2. Calcolatore di tasse per piccola partita IVA.
3. Bot Discord che modera messaggi.
4. Form di contatto per portfolio.
5. Sistema di prenotazione visite mediche.
6. Generatore di QR code da link.
7. Wallet di criptovalute.
8. Dashboard interna di metriche aziendali.
9. App di tracking sintomi che dà consigli medici.
10. Strumento di rinomina batch di file.

Per ognuna: griglia + decisione “costruisci ora / studia prima / delega / non generare” con motivazione di una riga.

Output atteso

Una griglia decisionale personale con tre colonne (rischio, reversibilità, competenza) e quattro righe di output (costruisci ora / studia prima / delega / non generare). Da consultare ogni volta che arriva un’idea, prima di aprire chat o IDE.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: costruire giudizio: capire quando l’AI è un moltiplicatore utile e quando aumenta il rischio del progetto. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Casi favorevoli: prototipi, strumenti interni, esplorazione, refactor guidati, documentazione, automazioni circoscritte.
• Casi rischiosi: sistemi critici, dati sensibili, domini non compresi, requisiti legali, performance o sicurezza difficili da verificare.
• Il criterio decisivo: puoi leggere, testare e mantenere ciò che viene generato?

3. Applicazione: svolgi il laboratorio: valutare dieci idee su una scala di rischio, reversibilità, valore e capacità personale di verifica. L’output da ottenere è: una griglia ‘costruisci ora / studia prima / delega a esperti / non generare’ motivata caso per caso.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• ho almeno tre esempi personali di “costruisci ora” e tre di “non generare”;
• so spiegare perché un sistema di pagamento non si fa in vibe coding senza supervisione esperta;
• riconosco quando un progetto cambia categoria in corso d’opera (es. prototipo che diventa produzione);
• ho una soglia personale chiara: oltre quel punto, fermo e ridiscuto.

Errori comuni

Sopravvalutare la propria capacità di verifica. “Ho fatto codice tutta la vita, posso verificare qualunque cosa” è raramente vero quando entra dominio specialistico. Sicurezza, crittografia, contabilità, sanità: anche un dev senior non verifica per esperienza generica.

Ignorare la criticità per fretta. “È solo un prototipo” diventa “è in produzione con utenti reali” senza una decisione esplicita. La transizione va segnata.

Confondere “funziona sul mio computer” con “funziona”. Demo riuscita ≠ sistema robusto. Casi limite, concorrenza, errori di rete, attacchi: testabili separatamente.

Non aggiornare la decisione. Un progetto può iniziare in fascia “costruisci ora” e finire in fascia “delega” man mano che cresce. Il giudizio va rivisto a tappe.

Prompt di lavoro

Sto valutando se usare vibe coding per questo progetto:

[descrizione progetto in 5 righe: cosa fa, per chi, con quali dati, in quale ambiente, con quale criticità]

Per ciascuno di questi 5 criteri dammi punteggio 1-5 e motivazione di 2 righe:

1. Pattern noto vs dominio specialistico (5 = pattern comune)
2. Reversibilità (5 = posso buttare e rifare)
3. Mia capacità di verifica (5 = so testare ogni parte)
4. Criticità (5 = bug fastidioso e basta)
5. Time-to-feedback (5 = vedo risultato in minuti)

Concludi con raccomandazione: costruisci ora / studia prima / delega / non generare. Se siamo a metà strada, suggerisci come ridurre scope per portarlo nella prima fascia.

Esercizio finale

Prendi il prossimo progetto che vuoi fare. Compila la procedura. Se la raccomandazione è “studia prima”, quale corso o risorsa vai a leggere? Se è “delega”, chi è la persona di riferimento? La risposta deve essere concreta, non generica. Senza nome di risorsa o persona, la decisione è vuota e tornerai a vibe coding per default.