Di cosa parla questo capitolo
“Fare O non Fare, non esiste provare.” — citazione che Yoda rivolge a Luke ne L’Impero colpisce ancora, e che calza perfettamente con l’approccio al vibe coding consapevole.
In questo capitolo ribaltiamo la prospettiva: dopo aver visto il perché fare questo tipo di attività (capitolo 1) e come pianificare (capitolo 2), adesso guardiamo cosa non fare. Perché il vibe coding, affrontato senza metodo e senza serietà, è un modo molto veloce per farsi male — token sprecati, codice fragile, progetti che si incagliano, e frustrazione.
I punti chiave
“Provare” non basta
Avvicinarsi al vibe coding come un esperimento superficiale — “tanto provo, si vede cosa viene fuori” — è il primo errore. Senza impegno a seguire un metodo, l’LLM produce risultati casuali e incoerenti. O lo fai con consapevolezza, o è meglio non farlo affatto.
Cosa NON fare con il vibe coding
- Non usare l’LLM come un oracolo: chiedergli cose senza contesto, senza piano, senza storia. Ogni sessione parte da zero e il modello non sa cosa avete deciso prima.
- Non saltare la pianificazione: il piano non è un optional. Senza
Plan.mde documenti guida, il progetto diventa una bolla di sapone — cresce veloce e scoppia altrettanto veloce. - Non delegare le decisioni critiche: l’LLM suggerisce, tu decidi. Sicurezza, dati sensibili, scelte architetturali importanti restano di tua responsabilità.
- Non ignorare il versioning: senza Git, ogni modifica è un salto nel vuoto. Non puoi tornare indietro, non puoi confrontare, non puoi collaborare.
- Non mescolare progetti: ogni progetto merita la sua struttura, la sua pianificazione, il suo contesto. L’inquinamento delle falde informative è reale.
L’accompagnamento è fondamentale
Il vibe coding consapevole non è un’attività solitaria. Il confronto con altri che seguono lo stesso metodo, la possibilità di chiedere consiglio, di far revisionare le proprie scelte — tutto questo fa parte del per-corso. Se non hai un mentore o un gruppo, i documenti guida (Plan.md, Implementazioni.md, DevLog.md) diventano il tuo accompagnamento differito: scrivere le decisioni è il modo per costringerti a pensarle davvero.
La struttura diventa pubblica
Come conseguenza concreta del metodo descritto nei capitoli precedenti, lo scaffolding — la struttura di cartelle e file guida — è ora disponibile pubblicamente su GitHub:
👉 Vibe Coding Scaffolding — Repository GitHub
Puoi clonarlo, forkarlo, scaricare l’archivio e usarlo come template per i tuoi progetti. Include:
agents.mdcon le regole di base per il tuo agente AI- La struttura progetti con cartelle
planning/,code/,input/,output/,manuals/ - I quattro documenti guida (
plan.md,implementations.md,backlog.md,devlog.md) pronti da compilare
È lo stesso scheletro che uso nei miei progetti — basta duplicare projects/Project1/ e rinominarlo.
Guarda il video
Nel prossimo capitolo — e sì, i capitoli hanno ancora molta strada da fare — continuiamo ad approfondire gli strumenti e le pratiche per rendere il vibe coding non solo possibile, ma produttivo e sicuro.