Agile e stato progettato per gli umani. Funziona sorprendentemente bene per gli agenti AI, ma per motivi del tutto nuovi.

Quando nei primi anni Duemila il Manifesto Agile ha cambiato il modo di sviluppare software, il problema da risolvere era chiaro: team di persone che non riuscivano a coordinarsi, requisiti che cambiavano piu velocemente di quanto si riuscisse a documentarli, progetti che deragliavano perche nessuno aveva visibilita su cosa stesse realmente succedendo.

La soluzione era altrettanto chiara: spezzare il lavoro in incrementi piccoli, validare spesso, adattarsi continuamente. Epiche, user story, task. Sprint, review, retrospettive. Post-it su una board. Tutto pensato per ridurre il rischio di fraintendimento tra esseri umani.

Vent'anni dopo, stiamo scoprendo che quella stessa struttura funziona in modo eccellente per un tipo di "sviluppatore" completamente diverso: gli agenti AI. Ma le ragioni per cui funziona non sono quelle originali, e capire questa distinzione e fondamentale per chiunque stia integrando l'AI nei propri processi di sviluppo software.

Lo stesso framework, un problema diverso

Il fraintendimento tra persone non e il problema principale degli agenti AI. Un agente non ha ego, non interpreta male un'email, non dimentica cosa si e detto in una riunione perche stava controllando il telefono.

Il problema degli agenti e un altro: il context drift. Man mano che un agente lavora su un compito, il suo contesto si satura. Piu informazioni elabora, piu rischia di perdere il focus rispetto all'obiettivo originale. E un po' come chiedere a qualcuno di risolvere un puzzle mentre gli si versano addosso continuamente nuovi pezzi di un puzzle diverso.

Ed e qui che la struttura Agile si rivela utile per ragioni completamente nuove. Scomporre il lavoro in epiche, user story e task non serve piu a facilitare la comunicazione tra persone: serve a sezionare il contesto in modo che l'agente possa operare con un focus definito ma senza essere ingabbiato in istruzioni troppo rigide.

Epiche, user story, task: cosa cambia quando li usi per gli agenti

Epiche: il patrimonio informativo come punto di partenza

In un processo Agile tradizionale, le epiche nascono spesso da una combinazione di intuizione del product owner, feedback degli utenti e obiettivi di business. Con gli agenti, il punto di partenza diventa molto piu ricco.

Pensate a cosa e possibile fare oggi: raccogliere documenti di progetto, trascrizioni di call, email, specifiche tecniche e utilizzare agenti specializzati per sintetizzare tutto questo materiale in epiche strutturate. Non si tratta di un semplice riassunto: l'agente puo incrociare informazioni da fonti diverse, identificare requisiti impliciti, evidenziare contraddizioni tra documenti.

Il risultato sono epiche che partono da una base informativa che nessun product owner, per quanto bravo, potrebbe elaborare manualmente nella stessa quantita di tempo.

User story: quando il codice esistente entra nel design

Ecco dove le cose si fanno interessanti. Nelle user story tradizionali, il codice esistente e un "dettaglio implementativo" che resta nella testa degli sviluppatori. La user story descrive il cosa, il come e un problema di chi la implementa.

Con gli agenti, questa separazione perde senso. Se un agente deve generare una user story che poi verra implementata da un altro agente (o dallo stesso), includere il contesto del codice esistente nella story non e un eccesso di dettaglio: e un atto di design fondamentale. L'agente che analizza il codebase puo indicare nella user story quali moduli saranno impattati, quali pattern architetturali rispettare, quali dipendenze considerare.

Questo non rende la user story prescrittiva. La rende consapevole. E la differenza tra dire "l'utente deve poter filtrare i risultati per data" e dire "l'utente deve poter filtrare i risultati per data; il modulo di ricerca attuale usa Elasticsearch con un indice strutturato cosi, e il frontend gestisce i filtri tramite questo componente React".

Task: l'inversione piu significativa

Questa e probabilmente la trasformazione piu profonda, e vale la pena ragionarci con attenzione.

Nella pratica Agile classica, c'era una regola non scritta: i task non devono essere troppo dettagliati. Il ragionamento era pragmatico - dato che il vero output e il codice, investire troppo tempo a descrivere nel dettaglio un task significava fare il lavoro due volte. Meglio una descrizione essenziale e poi passare direttamente a scrivere codice.

Con gli agenti, questa logica si ribalta completamente.

Un task dettagliato non e piu un lavoro duplicato: e il vero artefatto di design. E, di fatto, il "prompt" che guidera l'agente nella generazione del codice. Piu il task e preciso nel definire il contesto, i vincoli, i criteri di accettazione, il comportamento atteso, piu l'agente sara in grado di produrre codice allineato con l'intenzione originale.

E qui c'e un vantaggio ulteriore: un task dettagliato, per quanto ricco, e comunque enormemente piu rapido da leggere e validare per un essere umano rispetto al codice che ne risulta. Dieci righe di task che descrivono con precisione cosa fare sono piu facili da verificare di duecento righe di codice. Questo significa che lo sviluppatore puo concentrare il proprio tempo sulla validazione del design (il task) piuttosto che su quella dell'implementazione (il codice), dove il valore aggiunto umano e piu alto.

I feedback loop: checkpoint naturali per la collaborazione uomo-agente

Se c'e un principio Agile che non solo sopravvive ma diventa ancora piu centrale con gli agenti, e il feedback continuo.

In un workflow basato su agenti, i momenti di transizione tra livelli (da epica a user story, da user story a task, da task a codice) diventano checkpoint naturali in cui l'essere umano rivede, corregge, arricchisce il lavoro dell'agente. Non si tratta di semplice approvazione: e una vera collaborazione, in cui lo sviluppatore o il product owner puo coinvolgere colleghi, raccogliere input da piu persone e restituire all'agente un feedback collettivo.

Ma il loop non si chiude qui. La parte piu interessante arriva dopo la generazione del codice. Quando il codice prodotto dall'agente viene confrontato con i task e le user story approvati, si apre un ulteriore ciclo di feedback. Lo sviluppatore puo verificare se l'implementazione rispetta le intenzioni del design, e se non lo fa, puo continuare a iterare direttamente nello strumento di sviluppo: l'agente legge i commenti di una pull request su GitHub, corregge, ripropone, finche tutti i criteri non sono soddisfatti.

E Agile nella sua forma piu pura: cicli brevi, feedback rapido, miglioramento incrementale. Solo che adesso il ciclo include un partecipante nuovo, che non si stanca, non perde il contesto tra un feedback e l'altro (purche il contesto sia stato ben sezionato), e puo iterare a una velocita che prima era impensabile.

Come FairMind implementa questo approccio

In FairMind abbiamo costruito la piattaforma proprio intorno a questi principi.

Il processo inizia dalla raccolta del patrimonio informativo: documenti di progetto, email, trascrizioni di call, specifiche tecniche. I nostri agenti specializzati sintetizzano questo materiale in epiche strutturate, incrociando le informazioni e identificando requisiti che spesso restano impliciti nelle conversazioni tra stakeholder.

Quando si passa alle user story, la piattaforma inizia a integrare il contesto del codice esistente. Gli agenti analizzano il codebase per capire come declinare le user story in funzione dell'architettura reale, non di quella teorica. Questo e particolarmente importante per le aziende europee con cui lavoriamo, che spesso hanno codebase legacy significativi: la user story non puo ignorare vent'anni di decisioni tecniche stratificate.

A livello di task, gli agenti sezionano il codice in profondita. Ogni task diventa un documento di design ricco che include il contesto architetturale rilevante, i vincoli specifici, i criteri di accettazione verificabili. E qui che il contesto viene gestito con piu attenzione: l'agente puo risalire agli input originali delle epiche se necessario, ma il suo focus resta sulla porzione di codebase rilevante per quel singolo task.

E a ogni passaggio, la piattaforma prevede momenti di feedback collaborativo. Gli utenti possono rivedere, commentare, coinvolgere colleghi, e fornire agli agenti un feedback strutturato prima di passare al livello successivo. Dopo la generazione del codice, il loop continua: l'agente monitora i commenti delle pull request e itera fino a quando l'implementazione non e allineata con il design approvato.

Post-it piu grandi, cicli piu veloci

C'e un'ultima riflessione che vale la pena condividere. La regola del post-it, quella per cui una user story doveva stare su un foglietto adesivo, era un vincolo brillante. Forzava la sintesi, riduceva gli incrementi, facilitava il feedback.

Con gli agenti, quel vincolo fisico non ha piu senso. Le user story e i task possono e devono essere piu ricchi, perche l'agente ha bisogno di contesto per lavorare bene e perche, a differenza di un essere umano che legge un post-it tra una riunione e l'altra, l'agente elabora tutto il contenuto con la stessa attenzione.

Ma il principio dietro al post-it resta valido: mantenere gli incrementi gestibili, validabili, reversibili. Quello che cambia e la scala. Un "incremento gestibile" per un agente e semplicemente piu grande di quello di un team umano, perche sia la produzione che la validazione avvengono piu rapidamente.

Non stiamo abbandonando Agile. Lo stiamo scalando per un nuovo tipo di collaboratore che lavora al nostro fianco, e scopriamo che i principi che avevamo progettato per le nostre limitazioni umane funzionano altrettanto bene per limitazioni completamente diverse. Forse e il segno che quei principi erano piu profondi di quanto pensassimo.