Insights28/7/2026
Cosa insegna l'agentic coding, a partire da un caso reale
Articolo a cura di
Marianna Paparazzo
Business Developer
L'accelerazione promessa dall'AI agentica nello sviluppo software è reale, misurabile e in alcuni ambiti impressionante. Ma è anche parziale: si manifesta con forza dove il lavoro è tecnicamente ben definito, e si riduce drasticamente, a volte fino a fermarsi, dove entrano in gioco decisioni architetturali, coordinamento con parti terze e validazione umana della conoscenza. Il vantaggio competitivo, per le aziende che adottano questi strumenti, non sta nell'avere agenti più veloci: sta nel sapere esattamente dove finisce la loro autonomia e dove inizia il governo umano del processo.
Il rischio di misurare solo la produttività tecnica dopo l'adozione dell'AI agentica
Molte organizzazioni che introducono l'AI agentica nello sviluppo software misurano il successo dell'iniziativa guardando solo alla produttività tecnica: righe di codice generate, casi di test prodotti, giorni/uomo risparmiati su attività isolate. Da questi numeri si tende a dedurre, per estensione, che l'intero progetto stia procedendo più velocemente.
È un'inferenza rischiosa. Un progetto software reale non è fatto solo di compiti tecnici: include scelte architetturali che impattano trasversalmente sul sistema, negoziazioni con fornitori o partner esterni, e — nei progetti che ereditano codice preesistente (brownfield) — la validazione umana della conoscenza che gli agenti estraggono da sistemi legacy spesso stratificati e ridondanti. Se l'introduzione degli agenti non si accompagna a un ripensamento di questi passaggi, l'accelerazione tecnica si scontra con un collo di bottiglia rimasto invariato — e il progetto, nel suo complesso, non si conclude prima.
I numeri reali: dal 3x di accelerazione tecnica alle due settimane ferme
Un caso concreto rende evidente questa dinamica: un progetto enterprise nel settore education condotto con un modello di sviluppo agentico e in parte su base brownfield (componenti e logiche preesistenti da recuperare e rifattorizzare).
- Attività di setup infrastrutturale stimate in 30-40 giornate/uomo, completate in 11 giornate/uomo — un'accelerazione di circa 3 volte.
- Oltre 900 casi di test scritti ed eseguiti (front-end e back-end) dall'avvio del progetto.
- Refactoring e analisi della documentazione con un'accelerazione ancora superiore rispetto al setup infrastrutturale.
- A fronte di questi numeri, due settimane di sviluppo sostanzialmente fermo, causate non da limiti tecnici ma da decisioni in sospeso con un partner esterno.
Layer esecutivo vs layer situazionale: la distinzione che spiega il divario
Il team di delivery ha inquadrato questa distinzione parlando esplicitamente di un “layer esecutivo” (tecnico, dove gli agenti lavorano bene) e di un “layer situazionale” (decisionale, dove l'accelerazione si azzera): la stessa iniziativa AI produce risultati opposti a seconda di quale dei due layer si sta osservando.
Nel layer esecutivo rientrano le attività a specifica chiusa: scrittura di codice, esecuzione di test front-end e back-end, refactoring su pattern noti, generazione di documentazione. Sono compiti in cui l'obiettivo è definito in anticipo e il criterio di successo è verificabile in autonomia dall'agente — motivo per cui, in questo progetto, hanno prodotto un'accelerazione di circa 3 volte sul setup infrastrutturale e oltre 900 casi di test in tempi ridotti.
Nel layer situazionale rientrano invece le decisioni che richiedono contesto non riducibile a specifica: una scelta architetturale con impatti trasversali sul sistema, la validazione della conoscenza estratta da un sistema legacy prima di poterla riusare, un compromesso da negoziare con un partner esterno. In questo progetto, ad esempio, il rallentamento di due settimane non è nato da un limite tecnico del team, ma da una decisione rimasta in sospeso lato partner esterno: l'agente non aveva — né avrebbe potuto avere — gli elementi per sciogliere quel nodo al posto delle persone coinvolte.
Questa distinzione conta perché le due metriche raccontano storie opposte: la produttività tecnica del layer esecutivo può correre a pieno regime nello stesso momento in cui il layer situazionale tiene fermo l'intero progetto.
Il vantaggio competitivo è nel governo, non nello strumento
Questo caso conferma una posizione che adesso.it porta avanti da tempo nel dibattito su AI e sviluppo software: il vantaggio competitivo non risiede nello strumento AI in sé, ma nella capacità di governarne gli effetti. Scrivere più codice, più in fretta, non è di per sé un obiettivo, lo diventa solo se accompagnato da un governo esplicito di cosa può essere delegato agli agenti e cosa deve restare in mano al team: le scelte architetturali, la validazione della conoscenza estratta dal legacy, il coordinamento con gli stakeholder esterni.
Quattro azioni pratiche per governare l'agentic coding nei progetti software
Per le organizzazioni che stanno adottando o valutando l'AI agentica nello sviluppo software, quattro passaggi concreti:
- Distinguere esplicitamente, in fase di pianificazione, quali attività appartengono al layer esecutivo (delegabile agli agenti) e quali al layer situazionale (decisionale, non delegabile) — non dare per scontato che l'accelerazione tecnica si propaghi automaticamente al progetto.
- Misurare la produttività di progetto, non solo quella tecnica. Tracciare il tempo reale che intercorre fino al rilascio, non solo i giorni/uomo risparmiati sulle singole attività: è il confronto tra questi due dati a rivelare dove si nasconde il vero collo di bottiglia
- In contesti brownfield, imporre un passaggio di validazione umana sulla conoscenza estratta dal codice legacy prima di usarla come input per gli agenti, per evitare di automatizzare duplicazioni o scelte non più valide.
- Trattare le dipendenze decisionali da parti esterne come rischio di progetto di prima classe, con owner e tempi dedicati — esattamente come si farebbe con un rischio tecnico.
FAQ
1.Cos'è l'agentic coding governato?
È un modello di sviluppo software in cui agenti AI eseguono in autonomia compiti tecnici ben definiti — scrittura di codice, test, refactoring, documentazione — mentre un framework di governance umano stabilisce quali decisioni restano non delegabili: scelte architetturali, validazione della conoscenza estratta da sistemi legacy, coordinamento con parti terze.
2.Perché l'AI accelera lo sviluppo ma non sempre riduce i tempi complessivi di un progetto?
Perché un progetto reale non è fatto solo di compiti tecnici. Include anche decisioni architetturali, negoziazioni con partner esterni e validazioni che restano umane per natura. Se l'accelerazione tecnica non si accompagna a una revisione di questi passaggi, il progetto resta vincolato al ritmo del collo di bottiglia più lento — che spesso è organizzativo, non tecnico.
3.Come si misura correttamente la produttività quando si introduce l'AI agentica?
Serve distinguere due metriche: la produttività tecnica (velocità di esecuzione di compiti definiti, es. giorni/uomo risparmiati, casi di test prodotti) e la produttività di progetto (tempo reale fino al rilascio). Solo la seconda cattura l'effetto dei colli di bottiglia decisionali e va tracciata con strumenti dedicati, non dedotta dalla prima.
4.Che ruolo ha la validazione umana quando gli agenti lavorano su codice legacy (brownfield)?
È un passaggio critico. I sistemi legacy contengono spesso duplicazioni e stratificazioni: se la conoscenza che un agente estrae da quel codice non viene validata da una persona prima di essere usata per generare nuovo codice, il rischio è costruire funzionalità non allineate con le aspettative reali del cliente.
CONTACT US
fill out the form
to get in touch with us