Il ciclo di lavoro: pianifica, esegui, valida 🔄

Il modo più efficace di usare un agente di coding non è una feature dell’IDE: è un ciclo di lavoro in tre fasi. Chi lo salta finisce invariabilmente in una delle due trappole: l’agente che genera una montagna di codice sbagliato (e tu a smontarla), oppure l’agente che promette di aver sistemato tutto senza aver mai eseguito un test.

Il ciclo giusto è sempre lo stesso: prima il piano, poi il codice, poi la prova. L’ordine non è negoziabile.

Fase 1 — Pianificazione in sola lettura 📝

Prima di qualsiasi modifica ai file, l’agente lavora in sola lettura:

• analizza la struttura del repository e il contesto che hai indicato;
• formula domande sulle ambiguità che incontra;
• produce un piano d’azione: moduli coinvolti, file da creare o modificare, test da eseguire.

Il piano va approvato esplicitamente prima di proseguire. Questo passaggio ha due effetti: impedisce scritture affrettate su file sbagliati e, siccome i token di output costano più di quelli di input, contiene anche i costi. Un piano rifiutato costa poco; una sessione di implementazione finita nel posto sbagliato costa molto.

Non confondere la pianificazione con la prosa: il piano deve essere verificabile, non elegante. Se non riesci a capire cosa farà, l’agente non lo capirà nemmeno durante l’esecuzione.

Fase 2 — Esecuzione a micro-incrementi ⚙️

Solo dopo l’approvazione si implementa. La regola è micro-incrementi: l’agente modifica un modulo, si ferma, verifica, poi passa al successivo. L’alternativa — lasciarlo lavorare in autopilot su tutto il task — è accettabile solo per lavori ben delimitati e coperti da test esaustivi.

In pratica:

• un task complesso si scompone in passi che puoi controllare uno alla volta;
• dopo ogni passo, verifica intermedia con build, test e lint;
• se un passo deriva, lo fermi subito, non alla fine.

Alcuni strumenti permettono anche l’esecuzione asincrona: il task viene affidato a un agente che lavora in un contesto separato e consegna una pull request. Funziona bene per lavori ben specificati; non sostituisce il controllo su ciò che arriva nel repository.

Fase 3 — Validazione deterministica 🧪

L’ultima fase è quella che quasi tutti saltano, ed è la più importante. La verifica del lavoro non si affida all’agente: si affida agli strumenti.

• l’agente esegue build, test e lint e interpreta i loro report — non certifica a parole che “funziona”;
• i criteri di completamento definiti nella fase 1 sono l’unità di misura dell’esito;
• una revisione del codice (umana o assistita) chiude il ciclo prima del merge.

La differenza tra “l’agente dice di aver verificato” e “l’agente ha eseguito la suite e i test sono verdi” è la differenza tra fiducia e prova.

Il flusso completo 🔁

    flowchart TD
  Task[Task definito] --> Plan[Pianificazione: sola lettura, domande, piano]
  Plan --> Approve{Piano approvato?}
  Approve -->|No| Revise[Chiarire e riformulare]
  Revise --> Plan
  Approve -->|Sì| Impl[Esecuzione a micro-incrementi]
  Impl --> Val[Validazione: build, test, lint]
  Val --> OK{Criteri di completamento soddisfatti?}
  OK -->|No| Fix[Correzione mirata]
  Fix --> Val
  OK -->|Sì| PR[Pull request e review]
  

Nota come la pianificazione e la validazione siano i due architravi del ciclo. Se ne elimini uno, hai di nuovo l’autopilot con il rework al posto della qualità.

Quando la pianificazione è superflua 🪶

La pianificazione esplicita non serve sempre. La regola pratica: è obbligatoria quando il task tocca più di 2-3 file, introduce una nuova funzionalità o attraversa i confini del modulo. È superflua per modifiche puntuali a una singola funzione, dove sai già cosa deve cambiare e il rischio è basso.

L’obiettivo non è la burocrazia: è il controllo sul punto in cui il costo di sbagliare supera il costo di pianificare.

Quando NON usare questo ciclo ⛔

• Task banali e ripetitivi dove il piano sarebbe più lungo del codice.
• Codebase senza test: se la fase 3 non ha strumenti su cui appoggiarsi, stai validando a vista — il ciclo regge male.
• Esplorazione pura: se stai solo capendo un progetto, non c’è un piano da approvare, c’è un percorso di lettura da seguire.

Checklist finale ✅

• Ho definito l’obiettivo con criteri di completamento chiari?
• Per task multi-file ho fatto pianificare in sola lettura e ho approvato il piano?
• L’esecuzione procede a micro-incrementi con verifica intermedia?
• La validazione usa build, test e lint reali, non l’affermazione dell’agente?
• Prima del merge c’è una review (umana o assistita)?

Approfondimenti 📚

• Scrivere prompt che funzionano — il livello precedente: come formulare la richiesta che entra in questo ciclo.
• Che cos’è un agente di coding — i fondamenti dell’architettura.
• Blog: Question-driven specification e Unknowns-driven development.