Fino a due anni fa, quando parlavamo di AI nei processi di sviluppo, intendevamo uno strumento che suggeriva righe di codice mentre scrivevi. Oggi parliamo di agenti che aprono pull request, scrivono test, toccano migration su database di produzione e aggiornano documentazione senza che nessuno li abbia guardati per ore. Il salto è grosso, e porta con sé una domanda che molti team stanno scoprendo nel modo più doloroso: devo stare nel loop, o sopra il loop?
Non è una questione di nomi. È una decisione architetturale che cambia come progetti le pipeline, come strutturi le review, come scrivi i contratti di SLA con i clienti. E nei progetti che vedo passare tra le nostre mani, dove si toccano CRM con migliaia di record, ERP che gestiscono fatturazione, o software custom con regole di business non banali, sbagliare quella scelta costa. Tanto.
La differenza, senza girarci intorno
Human-in-the-loop significa che l’agente si ferma e aspetta te. Prima di scrivere su disco, prima di mandare una mail, prima di committare, c’è un gate. Tu approvi, respingi, correggi. L’agente riparte.
Human-on-the-loop significa che l’agente va. Tu guardi, campioni, osservi metriche. Intervieni se qualcosa esce dai binari, ma di default il flusso continua senza di te.
La prima modalità tratta l’agente come uno stagista bravo ma nuovo. La seconda lo tratta come un collega junior che ha già passato il periodo di prova. La differenza vera non è nella fiducia, è nel costo dell’errore e nella reversibilità dell’azione.
Se un agente sbaglia a generare un blocco di codice, lo riscrivi. Se sbaglia una UPDATE su una tabella orders senza WHERE, stai facendo un restore da backup alle tre di notte.
Perché il dibattito esplode adesso
Due cose sono cambiate. Prima, gli agenti hanno smesso di essere demo e sono diventati strumenti che scrivono codice di produzione. Claude Code, Cursor Agent, le pipeline con tool use su Anthropic API, gli sciami di agenti specializzati: tutti girano nelle nostre macchine da mesi, non da settimane. Seconda, la qualità è salita al punto che lasciarli liberi su task ben definiti funziona spesso. Non sempre. Spesso.
Il problema è che “spesso” non basta quando gestisci l’ERP di un cliente che fattura sei milioni all’anno. E “spesso” è ancora peggio quando parliamo di CRM con dati personali dove il GDPR non fa sconti.
Chi si ferma al paradigma human-in-the-loop per tutto, a un certo punto, scopre che sta pagando uno sviluppatore senior per fare il tasto ENTER su centinaia di approvazioni al giorno. Chi passa troppo presto al human-on-the-loop scopre il costo della rollback.
La risposta giusta non è una delle due. È una matrice.
Cosa dipende dal tipo di azione
Un agente che tocca un repository può fare mille cose diverse. Alcune sono letteralmente irreversibili, altre sono esperimenti che buttiamo via ogni dieci minuti. Pensare a loro come a una categoria unica è l’errore di partenza.
Provo a mettere un po’ d’ordine sulle azioni che vediamo più spesso nei progetti Bajara:
Basso rischio, alta reversibilità: scrivere file in un branch feature, aggiornare commenti, generare bozze di documentazione, refactoring interno a un modulo non esposto, creazione di componenti UI in staging. Qui l’agente può andare in autonomia. Se sbaglia, git reset o chiudiamo la PR.
Rischio medio, reversibilità condizionata: modificare schema di database in dev, aggiornare dipendenze, cambiare configurazioni di build, toccare API pubbliche con contratti verso terze parti. Qui vuoi una review umana, ma non necessariamente synchronous. L’agente può aprire una PR, il team la valuta in un secondo momento.
Rischio alto, bassa reversibilità: deploy in produzione, migration su DB live, modifiche a sistemi di pagamento, gestione di credenziali, invio di comunicazioni automatiche a clienti, scritture su integrazioni esterne (SAP, Odoo, Stripe, sistemi bancari). Qui il gate umano non è negoziabile. E anche quando c’è, vuoi un secondo paio di occhi.
Questa classificazione non è nuova, è DevOps di base. Ma con gli agenti cambia la frequenza: dove prima lo sviluppatore passava la maggior parte del tempo nel primo gruppo, adesso l’agente lo copre. Il senior sviluppatore finisce a passare il tempo sul terzo gruppo. E questo è il vero cambiamento di ruolo.
Il caso CRM: dove il human-on-the-loop vince spesso
Chi costruisce CRM custom sa che gran parte del lavoro è ripetitivo nella struttura ma specifico nel dominio. Nuova entità cliente, relazioni, filtri, viste, export. Ogni progetto ha il suo modello dati, ma i pattern sono gli stessi.
In questo scenario, un agente con accesso al repo può fare l’80% del lavoro in modalità on-the-loop senza problemi reali. Genera i modelli Eloquent partendo dal diagramma ER, scrive le migration, crea i controller REST, aggiunge le form request per validazione, costruisce la UI con le tabelle filtrabili. Tutto in branch feature, tutto in PR aperta.
Il senior sviluppatore non sta a controllare ogni singolo file. Fa code review sulle PR quando sono pronte, guarda le metriche CI (test passati, coverage, tempo di build), e interviene solo se qualcosa suona male.
In un progetto recente, abbiamo misurato: su 140 task di tipo “aggiungi entità CRUD completa al CRM”, l’agente ha chiuso 118 PR mergiate senza modifiche manuali. 14 richiedevano piccoli tweak (naming, validazioni aggiuntive). 8 erano da rifare quasi da zero perché il contesto non era chiaro all’agente.
Numeri del genere rendono il human-on-the-loop conveniente. Lo sviluppatore senior che prima passava giornate su questi task adesso ne passa una su problemi architetturali, gli altri giorni li passa a sorvegliare e a sbloccare casi difficili.
Il caso ERP: dove cambia tutto
Prendiamo lo stesso approccio e proviamo ad applicarlo a un ERP. Un ERP che gestisce magazzino, fatturazione, logistica, contabilità. Qui il primo problema non è tecnico, è legale e finanziario. Una fattura generata male è un problema con l’Agenzia delle Entrate. Un ordine duplicato è una perdita reale. Una rettifica di magazzino sbagliata scassa la chiusura di bilancio.
In un ERP, il human-on-the-loop puro è quasi sempre un errore. Non perché l’agente sia meno bravo, ma perché il rapporto tra errore e danno cambia di due ordini di grandezza.
Quello che funziona, invece, è un approccio misto. Gli agenti generano codice, test, documentazione, ma il merge passa sempre per review umana. Se c’è una migration che tocca tabelle critiche (fatture, pagamenti, stock), non basta nemmeno la review: vuoi un test run su snapshot di produzione prima di procedere.
Nei progetti ERP che seguiamo, abbiamo adottato una regola semplice: se il diff tocca file in certe directory (per esempio app/Domain/Billing/ o app/Services/Accounting/), la PR richiede due approvazioni manuali prima del merge, indipendentemente da chi l’ha aperta. L’agente può preparare tutto, ma il gate umano è obbligatorio.
Nessuno si lamenta di questa regola. Non perché l’agente sia inaffidabile: perché il costo atteso di un errore non compensa il risparmio di tempo sulla review.
Software custom: dipende da quanto è “custom”
I progetti di software custom sono il caso più variabile. Abbiamo progetti dove l’agente gira praticamente da solo (portali interni, dashboard, tool di supporto), e altri dove anche un piccolo refactor passa da tre review.
La discriminante principale è: quanto contesto implicito serve per prendere decisioni corrette?
Un portale interno con utenti autenticati, che mostra dati read-only da un servizio esterno: contesto basso, agente può andare quasi da solo.
Un’applicazione che implementa logiche di business del cliente, dove le regole sono scritte per metà nel codice e per metà in email di due anni fa con il project manager: contesto altissimo, l’agente senza supervisione combina guai sottili che nessun test cattura.
Questa è la ragione per cui insisto con i clienti sulla documentazione delle regole di business, sui memory bank per gli agenti, sui CLAUDE.md ben scritti. Più contesto strutturato dai all’agente, più puoi spostare il cursore verso il human-on-the-loop.
In molti progetti abbiamo un file memory-bank/ARCHITECTURE.md che spiega decisioni non ovvie, trade-off presi, motivi per cui una certa scelta è stata fatta anche se sembra strana. Quel file vale come dieci ore di onboarding per un nuovo sviluppatore, e vale ancora di più per un agente AI che deve decidere se un pattern va bene o se sta andando contro una decisione precedente.
Il cambio di mestiere per lo sviluppatore
Parliamo di come cambia la giornata concretamente. Prima, uno sviluppatore senior su un progetto CRM passava indicativamente così il suo tempo: 40% a scrivere codice, 20% in review, 20% in debugging, 10% in meeting con il cliente, 10% in design e architettura.
Con agenti AI ben integrati e un approccio principalmente on-the-loop per il lavoro standard, la distribuzione diventa: 10% a scrivere codice (solo le parti delicate), 35% in review, 15% in debugging (meno ma più concentrato sui casi veri), 10% in meeting, 30% in design e orchestrazione.
Il tempo di scrivere codice banale sparisce. Il tempo di pensare a come le cose devono stare insieme aumenta. Il tempo di spiegare le cose, scritte bene, aumenta ancora di più: perché ora le spieghi non solo ai colleghi, ma agli agenti.
Questa transizione è difficile per molti sviluppatori. Non per incapacità tecnica, ma perché richiede un muscolo diverso. Chi ama scrivere codice e lo fa bene si trova a passare più tempo a leggere codice scritto da qualcun altro (l’agente) e a decidere se va bene. È un ruolo più vicino a quello del tech lead che a quello dello sviluppatore puro.
Chi sa fare review, architettura e comunicazione scritta precisa, vola. Chi invece si identificava con il “battere il ferro” del codice scritto a mano, fatica.
Strumenti per il human-on-the-loop che funzionano davvero
Passare al human-on-the-loop senza infrastruttura adeguata è come lasciare la macchina in autopilota senza guardare mai davanti. Servono strumenti che ti facciano dormire tranquillo.
I pezzi che secondo me non possono mancare:
CI robusta con test veri. Non test che dicono “il codice compila”. Test che falliscono se la logica di business si rompe. Se hai una copertura scarsa, il human-on-the-loop è pericoloso. Prima di delegare, investi in test. Gli agenti stessi possono aiutarti a scriverli.
Branch protection rigida. Niente push diretti su main. Tutto passa per PR. Le PR richiedono build verdi, test passati, linting ok. Se l’agente può bypassare questo, stai mentendo a te stesso sulla supervisione.
Audit log dettagliato. Ogni azione dell’agente deve essere tracciabile. Chi ha avviato il task, con quale prompt, quali tool ha usato, cosa ha scritto dove, quanto è costato in token. Se non vedi questi dati, non puoi campionare, non puoi intervenire.
Circuit breaker su costi e azioni. Se un agente ha bruciato 50 euro di token in un’ora invece dei soliti 3, qualcosa è rotto. Limita gli importi. Limita il numero di tool call consecutive. Limita le chiamate a endpoint critici.
Rollback semplificato. Se un agente fa una PR brutta, chiuderla deve costare secondi. Se un deploy automatico va male, il rollback deve essere un bottone. Se la rollback è una procedura di tre ore, il human-on-the-loop non sta in piedi.
Canali di feedback rapidi. L’agente deve poter ricevere correzioni e migliorare. Se ogni volta che sbaglia ripete lo stesso errore, non stai guidando un collaboratore, stai guidando un automa. Memory bank, feedback file, correzioni persistenti.
Gli errori che vediamo più spesso
Dai progetti che seguiamo, gli inciampi principali quando si passa al human-on-the-loop sono cinque, e tornano quasi sempre.
Primo: dare troppa libertà troppo presto. Un team che per due settimane ha visto l’agente fare miracoli decide di lasciarlo lavorare in produzione di notte, senza presenza umana. Primo errore critico, tre mesi di fiducia bruciati. Meglio crescere gradualmente: prima in dev, poi in staging, poi in production solo su classi di task specifiche.
Secondo: non definire cosa è fallimento. Un agente che produce sei PR al giorno, cinque utili e una che rompe un test non critico, sta fallendo o avendo successo? Dipende dalla definizione. Se non la scrivi, ognuno la interpreta a modo suo, e alla prima discussione seria il team si spacca.
Terzo: confondere “l’agente l’ha fatto” con “l’agente è responsabile”. Responsabile sei tu. L’agente è uno strumento. Se scrivi questo nel contratto con il cliente in modo diverso, hai un problema legale dietro l’angolo.
Quarto: metriche sbagliate. Contare le PR chiuse al giorno è una metrica pessima. Conta le PR chiuse che non hanno generato bug entro 30 giorni. Conta il tempo risparmiato al team umano. Conta la soddisfazione del cliente. Le metriche di output sono facili, quelle di outcome sono vere.
Quinto: trascurare il contesto. Il team che dice “l’agente fa quello che gli dici” sottovaluta quanto il suo output dipende dal contesto che gli fornisci. Prompt cachato, CLAUDE.md curati, memory bank aggiornati, spec chiari. Senza questo, stai chiedendo a un senior freelance di lavorare per te senza spiegargli il progetto. Risultato: variabile.
Quando delegare davvero, e quando no
Proviamo a essere pratici. Ecco la mia griglia personale dopo diversi progetti.
Delega in modalità on-the-loop:
- Generazione di codice boilerplate (controller, dto, form request, migration base)
- Scrittura di test unit e integration su codice esistente ben documentato
- Documentazione tecnica generata dai commenti e dalla struttura
- Refactor interno a moduli non critici, con test di copertura alta
- Aggiornamento di dipendenze minor e patch in ambienti non critici
- Bug fix di tipo “simple” che hanno log chiari e test che riproducono il problema
- Creazione di componenti UI standard in progetti con design system definito
Mantieni in modalità in-the-loop:
- Modifiche a logiche di business critiche
- Integrazioni con servizi terzi che hanno costi o rate limit rilevanti
- Migrazioni di dati in produzione
- Decisioni architetturali (introdurre un nuovo servizio, cambiare pattern)
- Gestione credenziali, sicurezza, autenticazione
- Comunicazioni automatiche a utenti finali (email transazionali incluse)
- Modifiche a contratti API pubbliche verso clienti o partner
Non delegare mai del tutto:
- Revisione di security review
- Approvazione di rilasci in produzione
- Decisioni su come gestire incidenti attivi
- Comunicazioni con clienti in caso di problemi
- Scelte di compromessi (trade-off tra qualità, tempo, costo)
Un esempio concreto di come abbiamo strutturato un workflow misto
Su un progetto recente, ERP custom in Laravel, con circa 40.000 righe di codice, abbiamo messo in piedi questo flusso.
Gli agenti ricevono task dal sistema di ticketing. Ogni task ha una classificazione automatica: feature/bugfix/chore, più un livello di rischio (1-3). Task di livello 1 vanno in modalità on-the-loop: l’agente lavora, apre PR, CI gira, un senior la guarda quando ha tempo, merge se ok. Task di livello 2 vanno in modalità in-the-loop soft: l’agente lavora, apre PR, ma richiede review sincrona entro 24 ore e almeno un test manuale documentato. Task di livello 3 sono sempre fatti con l’agente in supporto, ma la review, i test e il deploy li fa umano.
Il risultato dopo tre mesi: throughput del team raddoppiato, bug di produzione diminuiti del 30%, ore di stand-up passate da 45 a 20 minuti perché meno task triviali da discutere.
Non è un miracolo. È questione di separare bene i livelli di rischio e di dare all’agente il contesto giusto per ogni livello.
Dove vedo il settore andare nei prossimi due anni
Mi azzardo su alcune previsioni, con la consapevolezza che tra 18 mesi potrei riderci sopra.
Gli agenti prenderanno piede come default per task di livello 1 anche nelle aziende più conservative. Il rapporto costi/benefici lo rende inevitabile. I team che resistono perderanno competitività sui prezzi.
La figura dello sviluppatore “senior supervisore di agenti” diventerà un ruolo definito, con skill specifiche. Oggi è ancora ibrida, tra tech lead e sviluppatore puro. Tra due anni avrà un nome suo e corsi dedicati.
Ci sarà una spaccatura culturale nei team. Sviluppatori che abbracciano la supervisione come loro lavoro principale, e sviluppatori che si specializzano sul codice critico che gli agenti non toccano. Entrambi i profili avranno mercato, ma saranno mestieri diversi.
I contratti di sviluppo cambieranno. Clausole su chi è responsabile del codice generato, chi ha fatto review, con quali strumenti, per chi risponde degli errori. Non è sci-fi: lo stiamo già vedendo in alcune richieste per software nel settore sanitario e finanziario.
Le aziende che producono agenti sposteranno parte del valore sulla governance. Non basta un agente bravo: serve un agente tracciabile, certificabile, auditabile. Chi offrirà questo, vincerà i contratti enterprise.
Cosa fare domani mattina
Se sei un tech lead o un founder con un team di sviluppo, e vuoi capire da dove iniziare, ti suggerirei tre cose.
Primo, fai un inventario dei task che i tuoi sviluppatori fanno in una settimana. Classificali per rischio e reversibilità. Vedrai che una fetta grossa è a basso rischio, e sta occupando le ore delle persone più costose. Quella è la tua zona di partenza per il human-on-the-loop.
Secondo, investi in documentazione strutturata del progetto. Non documentazione noiosa per il compliance, documentazione che un agente può leggere e usare. Architettura, trade-off, vincoli, convenzioni. Questo sforzo paga due volte: serve agli agenti, serve ai nuovi sviluppatori.
Terzo, parti con un progetto pilota. Un pezzo del codice a basso rischio, una classe di task ben definita. Misura. Aggiusta. Solo dopo aver capito come funziona da te, estendi l’approccio ad altre parti del sistema.
Noi di Bajara.it stiamo lavorando da tempo su questi pattern nei progetti che seguiamo, e abbiamo visto che il setup iniziale è meno importante della capacità di iterare. Chi parte perfetto perde, chi parte e corregge in corsa vince.
Gli agenti AI non sono magia. Non sostituiranno il giudizio umano sui problemi che contano. Ma cambieranno, stanno già cambiando, il modo in cui è distribuito il tempo delle persone nei team di sviluppo. Capire dove stare nel loop e dove sopra il loop è la decisione che separa i team che trarranno vantaggio dagli agenti da quelli che li useranno come giocattoli o, peggio, che li lasceranno fare danni.
La risposta giusta è quasi mai “tutto in” o “tutto fuori”. È “ecco cosa delego, ecco cosa no, ecco come misuro se funziona”. Il resto è disciplina.