3. Fare O non Fare, non esiste provare!

Fri, 22 May 2026 00:00:00 +0000

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.md e 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.md con 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.

Responsabilità | Andrea Scarpetta