← Nicola VitraniScrivimi

Note dal lavoro · AI

Vibe coding con criterio: dalla scintilla al codice che puoi mantenere

AI · 5 min di lettura

«Vibe coding» è l’espressione, coniata da Andrej Karpathy nel 2025, per indicare un modo di programmare in cui descrivi cosa vuoi in linguaggio naturale e lasci che un modello scriva il codice, accettandolo in gran parte senza leggerlo riga per riga. Funziona sorprendentemente bene per prototipi e piccoli strumenti. Per qualcosa che deve restare in piedi sei mesi dopo serve un po’ di criterio. Questo è il modo in cui lavoro con un agente AI, per esempio su questo portfolio, costruito iterando in conversazione.

1. I vincoli prima del codice

Le richieste vaghe producono codice generico. Prima di chiedere una funzione dico all’agente il contesto e i limiti: lo stack (qui React e Vite, senza nuove dipendenze se non necessarie), il tono grafico da rispettare, cosa non deve toccare e quando considero il lavoro finito. Un vincolo scritto in una riga evita mezz’ora di correzioni.

2. Passi piccoli, uno alla volta

Un’unica richiesta enorme («rifai tutta la hero con effetti 3D e ottimizza la SEO») produce un diff enorme che nessuno legge davvero. Meglio una modifica per volta, ognuna verificabile. Il reticolo 3D di cui parlo in un’altra nota è nato così: l’ho chiesto, l’ho guardato, non mi è piaciuto e l’ho fatto togliere. Con passi piccoli, cambiare idea costa poco.

3. Leggere sempre il diff

Il punto del vibe coding non è smettere di leggere, ma leggere meglio: i cambiamenti, non ogni riga scritta da zero. Guardo quali file sono toccati, se compaiono dipendenze nuove, se spariscono pezzi che non c’entrano. Un file tolto o una riga cancellata per sbaglio si vedono in un diff, quasi mai a occhio sul risultato.

4. Il commit lo decido io

Una regola semplice che mi ha salvato più volte: l’agente modifica i file, ma commit e push li faccio solo quando lo dico. Fino a quel momento tutto è reversibile e posso guardare il lavoro intero prima di renderlo storia.

5. Misurare, non fidarsi

  • Faccio girare la build e, dove esistono, i test.
  • Guardo il risultato in un browser a più larghezze, non solo sul desktop.
  • Per prestazioni, accessibilità e SEO uso numeri (Lighthouse), non impressioni.

Ne parlo in dettaglio nella nota sulla verifica del lavoro di un agente.

Quando non lo userei

Per codice con requisiti di sicurezza, di conformità o di proprietà intellettuale rigidi, dove ogni riga va compresa e giustificata, e dove i dati di un cliente non devono finire in strumenti esterni senza il suo consenso. In quei casi l’AI può aiutare a capire e a rivedere, ma l’autore resta chi firma.