Prima di lavorare con gli agenti, in MioAssicuratore eravamo 5-6 sviluppatori e mettevamo in produzione 1-2 feature ogni due settimane. Oggi lo sviluppatore sono solo io, e nemmeno a tempo pieno. Con me lavorano il CEO e la product designer, che portano codice in produzione anche loro grazie agli agenti. In una settimana rilasciamo anche 5-6 feature.
Non abbiamo tagliato sulla qualità per andare più veloci. Ogni feature arriva in produzione con test unitari, test end-to-end e una review della pull request prima del merge, esattamente come prima. La differenza è che il codice non lo scriviamo più noi: lo scrivono gli agenti AI, tutto.
In questo articolo racconto come lavoriamo, passo per passo. Non è una lista di strumenti: è un metodo, e funziona indipendentemente dall'agente o dal modello che usi.
Da dove siamo partiti
Prima degli agenti il problema più grosso non era scrivere codice. Erano le stime sbagliate e la mancanza di tempo per fare un grooming fatto bene.
Da lì si rompeva tutto a catena. Una feature partiva con requisiti non del tutto chiari, lo sviluppo andava avanti lo stesso e alla fine il risultato non era esattamente quello che il prodotto voleva. A quel punto dovevamo rifare delle parti, togliendo tempo a tutto il resto.
Il cambio vero: chi sviluppa non scrive più codice
La prima cosa da capire è che lo sviluppo agentico non è un autocompletamento più potente. Se usi l'AI per scrivere più in fretta le stesse righe che avresti scritto tu, il collo di bottiglia resta lo stesso: la persona davanti all'editor.
Nel nostro team il 100% del codice lo scrivono gli agenti. Il lavoro delle persone si è spostato su tre cose:
- decidere cosa costruire, con precisione;
- guidare gli agenti, dando loro il contesto giusto;
- controllare il risultato, con test e review.
Sembra un dettaglio, ma cambia tutto. Il tempo non si spende più a scrivere codice, si spende a togliere ambiguità prima e a verificare dopo.
C'è una conseguenza che all'inizio non mi aspettavo: se il lavoro è decidere e verificare, non serve essere sviluppatori per contribuire. Il CEO e la product designer aprono issue, fanno il grooming con l'agente e portano le loro pull request fino al merge. Quello che non possono fare è valutare le scelte tecniche, e per questo le scelte tecniche passano sempre da me, oppure da un agente che risponde solo citando decisioni già prese e documentate. Se la risposta non c'è, la domanda arriva a me.
Il flusso, passo per passo
1. Tutto parte da una issue
Ogni feature nasce come issue su GitHub. Non serve che sia scritta bene: all'inizio è un'idea, a volte di poche righe. L'idea la spieghiamo a un agente, ed è da lì che comincia il lavoro vero.
2. Un agente ti intervista finché non restano punti aperti
Il primo agente non scrive codice: fa domande. Legge il codice esistente, chiede cosa succede nei casi limite, quali dati servono, come si comporta la feature quando qualcosa va storto, e per ogni scelta propone due o tre opzioni con pro e contro. Le decisioni le prendo io, l'agente le mette per iscritto. Si va avanti finché l'idea non diventa un'epica estremamente dettagliata e senza punti aperti.
È il grooming che prima non avevamo mai il tempo di fare bene. Oggi lo guida l'agente, e non si ferma finché ogni dubbio non ha una risposta.
È il passaggio più importante di tutto il flusso. Un agente che sviluppa su una specifica ambigua riempie i vuoti da solo, e lo fa con sicurezza: è lì che nascono gli errori più costosi. Spostare le domande prima dello sviluppo è quello che ci permette di fidarci di ciò che arriva dopo. Per questo un'epica passa allo sviluppo solo dopo un controllo automatico: nessuna decisione ancora aperta, casi limite e dati esistenti descritti, feature flag dichiarato.
Un esempio. Stavamo introducendo un credito prepagato per gli SMS con cui i clienti ricevono il codice per firmare i documenti. Durante il grooming l'agente ha chiesto cosa dovesse succedere quando il credito finisce. Se anche il codice inviato via email avesse consumato credito, a credito esaurito si sarebbero bloccati entrambi i canali e i clienti non avrebbero più potuto firmare.
Ne è uscito un principio scritto nell'epica: la firma non si blocca mai. L'email non consuma credito e, se il servizio che gestisce il credito non risponde, l'SMS parte comunque. Senza quella domanda l'avremmo scoperto in produzione, molto probabilmente dal primo cliente rimasto senza credito.
3. Un altro agente sviluppa, per deliverable
Quando l'epica è chiusa, la prende un secondo agente, specializzato nello sviluppo. Tenere separati i due ruoli, chi analizza e chi sviluppa, evita che l'agente che scrive codice si metta a reinterpretare i requisiti.
L'agente non affronta l'epica tutta insieme: lavora per deliverable, pezzi piccoli e verificabili, fino ad arrivare alla pull request. Pezzi piccoli significano review più semplici e problemi scoperti presto.
4. Test e review restano obbligatori
Ogni pull request arriva con test unitari e test end-to-end, e il codice di logica che cambia deve essere coperto dai test. Poi passa da una review indipendente: un altro agente, che parte da zero e conosce solo il numero della pull request, controlla il lavoro. Il merge avviene solo con il mio OK.
Su questo non facciamo eccezioni, e non è un caso: più codice produce l'agente, più i test diventano l'unico modo affidabile per sapere che funziona.
Chi pensa che con l'AI si possa fare a meno dei test ha il ragionamento al contrario. Lo sviluppo agentico richiede più rigore, non meno.
5. Tutto finisce su main, i feature flag decidono
Non teniamo branch di lunga durata: tutto viene integrato su main, sempre, con la nuova funzionalità spenta. Quello che decide cosa vedono gli utenti sono i feature flag.
Il collaudo lo facciamo direttamente in produzione: accendiamo il flag solo per un ambiente di collaudo e ripercorriamo i casi di test. Se qualcosa non va, il rollback è rispegnere il flag. Quando è tutto a posto, la funzionalità si accende per alcuni utenti o per tutti.
Con 5-6 feature a settimana, gestire rami paralleli sarebbe impossibile. Con i flag l'integrazione è continua e il rilascio diventa una decisione, non un'operazione.
Perché il metodo non dipende dallo strumento
Oggi usiamo Claude Code, ma il nostro modo di lavorare non è legato a un agente o a un modello. Il valore sta nella struttura: issue, epiche senza punti aperti, ruoli separati, deliverable piccoli, test obbligatori e feature flag. Se domani uscisse uno strumento migliore, cambieremmo strumento senza cambiare metodo.
È anche il consiglio che do a chi parte: non scegliere prima lo strumento. Scegli prima come vuoi lavorare.
Cosa non funziona ancora (e cosa abbiamo imparato)
Non è tutto liscio. Il metodo che ho descritto è il risultato di errori precisi, e alcuni li stiamo ancora correggendo.
- Aprire lavoro costa quasi zero, rivederlo no. Con gli agenti, una issue piccola può diventare in poche ore una pull request che tocca decine di file. L'attenzione di chi revisiona non scala allo stesso modo. Oggi ci sono limiti precisi: al massimo 2 epiche e 5 pull request aperte per persona, pull request sotto le 1.000 righe, una sessione per una issue per una pull request.
- Le regole devono farle rispettare gli strumenti, non la buona volontà. Quei limiti non sono scritti in un documento che l'agente può ignorare: li applica uno script che blocca l'agente quando prova a superarli.
- Le domande rimandate tornano sempre. In due settimane gli agenti ci hanno fatto 126 domande durante lo sviluppo, e più della metà riguardava il prodotto: erano buchi del grooming. Ora un'epica non parte con decisioni aperte. Se in sviluppo emerge comunque un dubbio, l'agente prende una decisione provvisoria dietro feature flag e la dichiara nella pull request.
- I test fatti da un agente sono inaffidabili, in entrambe le direzioni. Un agente che navigava l'applicazione come un utente dava falsi allarmi e, peggio, ha classificato come rumore un errore che era un bug vero, rimasto nascosto per un mese. Prima del merge usiamo solo test deterministici. Il collaudo vero è in produzione, a flag acceso solo per l'ambiente di collaudo.
- Una review che chiede sempre modifiche viene ignorata. Rilanciare la review AI a ogni giro non converge. Abbiamo fissato al massimo due giri, con un revisore che riparte ogni volta da zero.
Da dove partire nel tuo team
Non serve rivoluzionare tutto in un giorno. Se dovessi ripartire da zero, farei così:
- Inizia dalle specifiche. Prima ancora di far scrivere codice agli agenti, usali per trasformare le idee in epiche senza punti aperti. È il passaggio con il ritorno più alto e il rischio più basso.
- Rendi i test non negoziabili. Se oggi la copertura è bassa, è il primo investimento da fare: senza test non puoi fidarti di quello che produce un agente.
- Lavora per pezzi piccoli e integra spesso. Deliverable brevi, pull request piccole e feature flag per decidere quando rilasciare.
- Metti le regole in uno strumento, non in un documento. Ogni regola che conta va fatta rispettare da un controllo automatico, altrimenti prima o poi un agente la aggira.
Il resto viene da sé, ma richiede tempo e qualche errore. Se vuoi accorciare la strada, è esattamente il lavoro che faccio con i team tech.