Pianificare prima di generare 🗺️

C’è un istante che conoscono tutti quelli che hanno provato un agente di coding: scrivi due righe di prompt, premi invio, e ti ritrovi una feature intera con test, refactor e una spiegazione così ordinata da sembrare scritta da un senior in un giorno buono. Ti senti leggero. Poi, tre giorni dopo, la demo si rompe in un modo che non avevi previsto, e ti rendi conto che stai pagando il conto del primo entusiasmo.

Quel conto si chiama rework. E questo articolo parla di come non doverlo pagare più di una volta.

Un agente non genera codice lento: genera fiducia sbagliata in fretta.

La scena del vibe coding 🎰

Chiamiamolo con il suo nome: vibe coding. Si aprono gli strumenti, si descrive l’obiettivo con una nuvola di sensazioni (“fammi una dashboard bella con le metriche”), e si lascia che il codice fiocchi. Il primo giro è sempre meraviglioso. Il problema non è il primo giro.

Il problema arriva al terzo: quando la dashboard deve rispettare un vincolo di accesso, quando le metriche vanno allineate alla fonte di verità, quando qualcuno chiede di cambiare una cosa che, a guardar bene, era la spina dorsale di tutto. Ogni modifica trascina il sistema in una direzione non prevista, e ogni correzione genera nuovo codice da correggere.

Il vibe coding non è “veloce”: è veloce al primo giro. Il tempo lo ripaghi dopo, con gli interessi.

Perché l’agente non pianifica da solo 🧭

Un agente di coding è un esecutore entusiasta del prossimo passo. Gli chiedi “aggiungi il filtro”, e lui lo aggiunge: nel modo più plausibile, con la struttura che gli appare più ovvia, senza chiedersi se il filtro doveva stare lì, o se rompe il flusso di chi viene dopo.

Non è un difetto, è una proprietà. L’agente ottimizza la mossa, non il percorso. Se non gli dai il percorso, ti darà mille mosse belle e un percorso a caso.

Il prompt chiede la prossima mossa. Il piano dice perché quella mossa è giusta.

È qui che si separano due modi di lavorare: chi usa l’agente come una macchina per generare codice, e chi lo usa come una macchina per eseguire decisioni già prese. Il secondo è più noioso all’inizio e infinitamente più sostenibile dopo. Se vuoi capire cosa succede dentro un agente quando “decide”, la lettura giusta è Cosa è un agente di coding.

Il piano come contratto 📜

La pianificazione esplicita è il contratto tra umano e agente. Non serve un documento di quaranta pagine: bastano poche righe che rispondano a domande scomode.

• Obiettivo: cosa deve essere vero alla fine, in una frase verificabile.
• Vincoli: cosa non si tocca, quali convenzioni valgono, quali risorse sono off-limits.
• Criteri di successo: come facciamo a dire che è finita.
• Confini: quali file può toccare, dove non deve mettere le mani.

Quando il piano esiste, l’output dell’agente smette di essere una proposta plausibile e diventa un impegno verificabile. Quando manca, stai delegando anche le decisioni — e poi ti sorprendi quando arrivano decisioni a caso.

Nel ciclo di lavoro pianifica → esegui → valida questa regola è il primo passo obbligato: non perché la burocrazia piaccia, ma perché un agente senza piano è un collega che inventa.

La matematica del non-pianificare 💸

Raccontiamola in termini poco romantici. Ogni volta che l’agente genera codice senza un piano, consumi tre risorse:

• Token: il codice sbagliato va generato, letto, criticato, rigenerato.
• Tempo umano: ogni giro di correzione richiede qualcuno che guardi, giudichi e rilanci.
• Fiducia: dopo tre smentite, il team smette di fidarsi — a ragione.

Il rework non è un costo lineare: è un costo composto. Ogni correzione affrettata sposta il sistema lontano da una struttura pulita, e il passo successivo costa di più. Il vibe coding è economico solo se non conti il secondo giro.

Pianifica → esegui → valida 🔁

La buona notizia è che la cura è una disciplina, non una tecnologia. Il ciclo di lavoro con un agente è semplice: si pianifica cosa fare, si esegue il piano, si valida il risultato contro i criteri di successo. Nessuna delle tre fasi può saltare le altre.

Il punto più delicato è il ritorno dalla validazione: se il risultato non soddisfa i criteri, non si genera altro codice a caso, si aggiorna il piano. È un dettaglio apparentemente piccolo, ma è la differenza tra correggere la rotta e correggere la mappa.

Il dettaglio completo del ciclo, con un esempio pratico passo per passo, è nella guida Il ciclo di lavoro: pianifica, esegui, valida.

Il piano scende dalla specifica 📐

C’è un livello ancora più a monte della pianificazione: la specifica. Il piano dice come procedere; la specifica dice cosa deve esistere e perché. Se la specifica è ambigua, qualsiasi piano è wishful thinking ben formattato.

Il metodo più onesto che conosco per evitarlo è chiedere prima le domande giuste: è lo stesso filo conduttore di Question-driven specification. Quando le domande sono chiare, il piano scrive quasi da solo. Quando mancano, il piano è una lista di auspici.

Conclusione: cinque righe prima di inviare ✅

Se vuoi una regola da applicare già domani, è questa: prima di premere invio su un prompt, scrivi cinque righe di piano — obiettivo, vincoli, criteri, confini, file coinvolti. Non è arte retorica, è un contratto con il tuo futuro io, quello che dovrà leggere il codice fra tre mesi.

L’agente può generare codice in un minuto. La parte che non puoi delegare è decidere cosa deve essere vero. E quella si fa prima, non dopo.

Pianifica prima, genera dopo: costa meno e finisce prima.