La seconda regola fondamentale per lavorare con gli Agent AI: suddividere una richiesta ampia in una granularità più fine, con verifica dopo ogni passo, produce risultati migliori di un unico prompt gigante.
Se si affronta una grande nuova funzionalità, è meglio suddividerla in Task più piccoli, per diverse ragioni.
Una delle cose più importanti da ricordare è come si comporta nel tempo il costo dello sviluppo software. Il libro Code Complete contiene un noto grafico che mostra quanto più costosa diventi la correzione di un bug a seconda della fase di sviluppo in cui lo si individua: durante l'analisi il costo è quasi zero, ma quando il software è in produzione presso il cliente il costo è di un ordine di grandezza superiore, o più. Con la velocità con cui oggi l'AI genera codice, occorre essere ancora più attenti a progettare l'architettura in anticipo — perché il refactoring è proprio ciò che l'AI non gestisce particolarmente bene. L'approccio migliore è attenersi agli standard descritti nei libri di clean code e usare pattern consolidati per la struttura e la logica di business — i libri sono una delle fonti di maggiore qualità da cui un modello AI ha appreso le pratiche corrette durante l'addestramento, quindi li comprende meglio. Per l'AI è inoltre importante mantenere il codice suddiviso in livelli chiari, anche in un monolite — l'Agent trova allora la strada nel codice con molta più facilità.
Torniamo a come suddividere correttamente i Task. Supponiamo che il compito sia: realizzare un nuovo modulo di valutazione della soddisfazione dei clienti. Di quali fasi avremo bisogno?
- UI — il modulo, i suoi campi e l'evento di invio.
- Logica di business — validazione del modulo, associazione della richiesta all'account del cliente, priorità della richiesta.
- Struttura dei dati — come i dati viaggiano verso il BE e ritornano al FE.
- BE — di nuovo validazione e logica di business, ora lato backend.
- Livello dati — mappatura dalla struttura dei dati al database.
- Persistenza dei dati, più la corrispondente struttura che ritorna dal BE al FE.
Per l'AI non importa davvero da dove si inizia — conta descrivere correttamente ogni passo. Per l'utente è più pratico partire dal database oppure dal frontend.
Con questo sono coperti tutti i Task. La domanda ora è: qual è la differenza tra un grande Task e diversi Task più piccoli?
Con un unico Task il vantaggio è un contesto condiviso (cache) tra i passi — l'Agent non deve mai cercare nulla di nuovo. Ma su più turni quel vantaggio si ribalta: più si resta in un unico contesto, più token vengono rinviati ed elaborati di nuovo a ogni turno successivo, per cui il costo per turno continua a crescere con le dimensioni del contesto — in un Task lungo e con molti turni può sommarsi in una cifra apprezzabile.
Se invece i Task vengono suddivisi, l'AI svolge sempre solo la propria parte specifica, che alla fine può essere testata in modo indipendente — individuando gli errori prima ancora che inizi il lavoro sulla parte successiva. Complessivamente si consumano meno token e poter verificare ogni passo in modo indipendente permette di individuare allucinazioni o scostamenti dal requisito molto prima che al termine di un unico Task gigante. I Task più piccoli non richiedono inoltre al modello di mantenere l'attenzione su ogni dettaglio contemporaneamente.
Perché è così importante per i modelli AI? Hanno una capacità limitata di mantenere la priorità su un gran numero di istruzioni contemporaneamente. Se in un unico prompt si scrive "aggiungi una nuova funzionalità, rifattorizza la vecchia logica e correggi tre bug correlati", il modello compone un proprio ordine di priorità — che potrebbe non coincidere con il proprio. Il risultato: una parte del Task viene svolta in modo brillante, una parte viene trascurata e nessuno se ne accorge finché non si rompe in produzione.
È esattamente per questo che AITM suddivide le richieste ampie in Task concatenati invece di lasciarle procedere come un unico passaggio continuo.
Come appare nella pratica: una normale chat AI e AITM a confronto
Un normale Agent AI (chat/copilot dell'IDE): gli si dà un unico prompt lungo e l'Agent si mette al lavoro in un unico contesto continuo. Se a circa l'80% sbaglia un dettaglio, non lo si scopre finché non si esamina l'intero diff — nel frattempo il lavoro sui punti successivi è proseguito sopra le fondamenta rotte.
AITM: la stessa richiesta viene suddivisa in Chat/Brainstorm in chiamate di Task concatenate e separate con dipendenze — il Task B può iniziare solo dopo che il Task A ha attraversato l'intera Pipeline ed è stato integrato con il merge. Se il Task A fallisce alla review o ai test, il Task B non parte sopra fondamenta rotte — attende. Nel frattempo il Watchdog valuta da solo il fallimento del Task A: se riesce ad analizzare l'errore e a proporre una correzione, il Task riparte automaticamente con un prompt che descrive esattamente quell'errore e la correzione proposta; se l'errore non è chiaro o non è risolvibile senza una decisione umana, il Task si ferma e attende che sia l'utente a decidere come procedere. Inoltre, dopo il merge dell'ultimo Task della catena, viene eseguito un passo chain-audit — un controllo finale deterministico (non AI) che riconvalida i contratti interessati dall'intera catena.
La differenza che l'utente vede: con un normale Agent si ottiene alla fine un unico diff grande e opaco. Con AITM si ottengono diversi Task più piccoli, con un nome e verificati in modo indipendente, ciascuno con la propria storia — e si sa esattamente dove qualcosa è andato storto se non è andato secondo i piani.