Vai al contenuto
Tutti gli articoli

Da 7 anni a 7 giorni con l’IA agentica

di Ghazi Triki · 5 min di lettura

Da sette anni a sette giorni
In questo articolo

Se le è mai capitato di fissare un foglio di calcolo COCOMO II che prevedeva 33 mesi di calendario per un progetto che il suo team ha consegnato in due sprint, conosce già il problema: ogni modello di stima oggi in uso è stato calibrato su un mondo in cui gli sviluppatori digitano ogni riga, i cambi di contesto hanno un costo e il calendario si ferma alle 17. Quel mondo non esiste più. Di recente abbiamo sviluppato da zero un’applicazione da 286 KLOC, 672 file e più sottosistemi (livello di protocollo, livello dati, motore di rendering, integrazione con la piattaforma) e abbiamo raggiunto una versione alpha pronta per i test in 7 giorni. L’intero pannello di modelli (COCOMO Basic/Intermediate/Post-Architecture, Function Points, baseline SLOC, Putnam/SLIM) ha restituito una previsione mediana di 30,3 mesi di calendario. Il moltiplicatore di produttività mediano: 4.240×. Anche la baseline più prudente (25 SLOC per giorno-sviluppatore per i sistemi complessi) era sbagliata di 1.433×. I modelli non sono errati: sono applicati male. Di seguito l’analisi modello per modello, la calibrazione empirica sullo stesso autore e ciò che la letteratura RCT dal 2024 al 2026 dice davvero su dove l’IA agentica comprime i tempi, e su dove non lo fa.

Il progetto che ha mandato in crisi le stime

In RIADVICE abbiamo sviluppato di recente un’applicazione complessa e ricca di funzionalità, del tipo che coordina più sottosistemi in un’architettura distribuita, come ambiente nativo multipiattaforma per mobile e desktop a partire da un’unica base di codice, spinti da requisiti di mercato che imponevano una nuova implementazione. La base di codice dice tutto sulla scala:

  • 286.662 SLOC (~286 KLOC) distribuite su 672 file sorgente
  • 1.329.399 righe di churn totale: 862.488 inserimenti e 466.911 cancellazioni
  • 700 commit in 7 giorni di sviluppo attivo per arrivare alla prima alpha pronta per i test
  • Internazionalizzazione completa in decine di lingue
  • Più sottosistemi profondamente distinti (gestione dei protocolli, gestione dei dati, rendering e integrazione con la piattaforma), tutti costruiti da zero per l’ambiente di destinazione

Non si trattava di un wrapper né di un semplice restyling. Era un’implementazione nativa costruita da zero per soddisfare requisiti di mercato che le soluzioni esistenti non riuscivano a soddisfare. Prima di scrivere una sola riga, ho collegato al progetto uno strumento di analisi personalizzato che applica alla base di codice, man mano che cresce, l’intero pannello dei modelli standard di settore per la stima dell’effort software. L’obiettivo era onesto: misurare il divario tra ciò che prevedono i modelli classici e ciò che produce realmente una consegna assistita dall’IA. I risultati non sono un errore di arrotondamento. Sono una rottura di categoria.

Che cosa prevedevano i modelli di stima e che cosa è successo davvero

Lo strumento esegue tutti i principali modelli di stima della letteratura di ingegneria del software (COCOMO Basic nelle varianti Organic, Semi-Detached ed Embedded; COCOMO Intermediate nelle varianti Semi-Detached ed Embedded, tarati; COCOMO II Post-Architecture, tarato; Function Points; la SLOC Productivity Baseline; Putnam/SLIM), calibrati sul tipo di progetto con le costanti pubblicate nella letteratura originale.

Modello di stimaEffort previstoCalendario previstoAccelerazione rispetto al reale
COCOMO Basic (Organic)913 mesi-persona33,3 mesi2.282×
COCOMO Basic (Semi-Detached)1.696 mesi-persona33,7 mesi4.240×
COCOMO Basic (Embedded)3.200 mesi-persona33,1 mesi8.000×
COCOMO Intermediate (Semi-Det., tarato)1.259 mesi-persona30,4 mesi3.148×
COCOMO Intermediate (Embedded, tarato)2.376 mesi-persona30,1 mesi5.940×
COCOMO II Post-Architecture (tarato)1.703 mesi-persona30,3 mesi4.257×
Function Points (stima di massima)17,9 mesi-persona7,5 mesi45×
SLOC Productivity Baseline (25 SLOC/giorno)573 mesi-persona573,3 mesi1.433×
Putnam/SLIMnon applicato (durata < 30 giorni; T 4/3 esplode)--

Il moltiplicatore di produttività mediano su tutti i modelli è 4.240×. Anche il modello più prudente prevede un tempo di consegna circa 1.400 volte più lungo di quello reale. Il più ottimista, Function Points, prevedeva comunque 7,5 mesi di calendario, 45× più dei 7 giorni effettivi. Secondo i modelli questo progetto avrebbe dovuto richiedere da 7 mesi a 47 anni. Una versione alpha era pronta per i test in 7 giorni.

I modelli non concordano tra loro, con scarti da 50× a 8.000×

Questi modelli non sono d’accordo tra loro. Sulla stessa base di codice le previsioni vanno da 17,9 a 3.200 mesi-persona, uno scarto di 178×. Il benchmark SEAA 2013 di COCOMO II, SEER-SEM, SLIM e TruePlanning su 51 progetti reali ha rilevato un MMRE dal 50 al 100%. Una valutazione del 2023 sul dataset COCOMO della NASA ha rilevato un MMRE vicino a 1,0 e PRED(0,25) = 0,0: nessun progetto stimato entro la fascia di errore del 25%. I modelli non sono mai stati pensati per un progetto assistito dall’IA. Ma l’entità del divario, anche tenendo conto dell’imprecisione dei modelli, ci dice che qualcosa di strutturale è cambiato.

Che cosa dice davvero la ricerca su IA agentica e produttività degli sviluppatori

Il dato di 4.240× è estremo, e non voglio esagerarne la portata. Lo scaffolding di un progetto greenfield gonfia il churn, e le SLOC sono un indicatore debole del valore. Guardiamo quindi la letteratura sottoposta a revisione paritaria. Gli assistenti in stile Copilot offrono guadagni modesti ma reali. Peng et al. (2023) hanno rilevato che gli sviluppatori che usavano un AI pair programmer completavano un compito il 55,8% più velocemente (IC 95%: dal 21 all’89%). L’RCT Microsoft/Accenture/Fortune 100 (2025), lo studio più ampio a oggi con n=4.867, ha rilevato un aumento del 26% dei compiti completati. L’RCT interno di Google (2024) ha rilevato una riduzione di circa il 21% del tempo dedicato al compito. L’esperimento sul campo BIS/Ant Group (2024) ha misurato un aumento del 55% della produzione di codice per il personale junior. La sintesi onesta: da 1,26× a 1,56× sui compiti adatti. Reale, ma non trasformativo. L’IA agentica opera in un regime diverso. La revisione 2025 di Devin pubblicata da Cognition riportava risultati dei clienti pari a 10× sulle migrazioni ETL, 14× sulle migrazioni di versione Java e 20× sulle correzioni di sicurezza. Nubank ha riportato un miglioramento dell’efficienza di 12× e un risparmio sui costi di 20× su un refactoring di diversi milioni di righe, stimato in precedenza come un impegno pluriennale da mille ingegneri. Il nostro porting si colloca pienamente in questo intervallo: l’istogramma dei commit mostra picchi densi alle 22:00, alle 00:00 e all’01:00, il segno distintivo di sessioni guidate da agenti. Le evidenze contrarie sono reali. L’RCT 2025 di Metr.org (16 sviluppatori esperti, 246 compiti su progetti maturi) ha rilevato che l’IA aumentava il tempo di completamento del 19%: ha rallentato sviluppatori esperti su basi di codice a loro familiari. Uno studio difference-in-differences del 2026 su 807 repository GitHub che avevano adottato strumenti di IA (He et al., MSR ’26) ha rilevato un aumento di velocità «transitorio» e un aumento «persistente» della complessità del codice, che ha provocato un rallentamento nel lungo periodo. Il titolo dice tutto: Speed at the Cost of Quality. Il consenso: l’IA aiuta molto nello sviluppo greenfield e strutturato, aiuta in modo modesto nei compiti di completamento e può danneggiare la velocità sulle basi di codice mature. Il debito di qualità è reale.

Perché i modelli saltano: tre cambiamenti strutturali

Nessuno dei fattori di costo dei modelli classici prevede un’impostazione per «lo sviluppatore dispone di un agente autonomo che non dorme mai e tiene in contesto l’intera base di codice». Tre cambiamenti fanno crollare la curva della durata:

  1. Il collo di bottiglia della digitazione è scomparso.

I modelli presuppongono che una parte significativa dell’effort sia meccanica: codice boilerplate, scaffolding, refactoring ripetitivi, risorse di localizzazione e altri dati strutturati. In questo porting gran parte del volume è costituita da testo e collegamenti molto regolari che un agente può generare o trasformare in blocco. Lo stesso codice scritto a mano (scaffolding, costruttori, collante con la piattaforma) ora viene generato a raffiche, non digitato riga per riga.

  1. Il costo del cambio di contesto sta crollando.

Una persona che passa dal livello di protocollo al livello dati e al motore di rendering paga ogni volta un costo per ricaricare il contesto. Un agente che ha letto l’intero repository di 672 file lo paga una volta sola. Su una base di codice di queste dimensioni, questa asimmetria si moltiplica rapidamente.

  1. Il calendario non è più il collo di bottiglia.

I modelli convertono i mesi-persona in mesi di calendario tramite un’equazione di staffing che presuppone una giornata lavorativa umana. Le sessioni degli agenti proseguono di notte. L’istogramma dei commit mostra una produzione costante dalle 07:00 all’01:00: 18 ore attive, non 8.

La calibrazione empirica sullo stesso autore

Poiché i modelli parametrici divergono di ordini di grandezza, ho eseguito anche una calibrazione empirica trasversale ai progetti, confrontando il mio churn di codice per giorno-persona prima e dopo l’adozione di uno strumento di IA agentica, su altri tre repository di produzione dello stesso ecosistema:

ProgettoChurn/giorno pre-IAChurn/giorno era IAMoltiplicatore
Progetto A (load balancer)6732.0563,1×
Progetto B (servizio di reporting)2392.1278,9×
Progetto C (servizio di elaborazione)1.3229820,7×
Aggregato (media / mediana)--4,2× / 3,1×

Stesso autore, stesso dominio, vero lavoro di manutenzione. Il moltiplicatore empirico è da 3 a 9×, molto più prudente del dato greenfield di 4.240× e coerente con la fascia alta della ricerca pubblicata sull’IA agentica. Un progetto è addirittura diventato più lento: i guadagni dipendono dal compito, non sono universali.

Che cosa significa per la pianificazione dei progetti

Se stima ancora i progetti software con modelli non calibrati e una baseline di 25 SLOC al giorno, sul lavoro assistito dall’IA sbaglierà da uno a tre ordini di grandezza. Ecco che cosa facciamo in RIADVICE:

  1. Calibrare sulla propria storia. Confronti la sua produzione di codice per giorno-persona con e senza IA. È più economico, più onesto e produce un intervallo da 3 a 9× che può difendere in un piano di progetto.
  2. Separare greenfield e manutenzione. Il moltiplicatore dell’IA agentica è massimo nello sviluppo greenfield e strutturato, minimo (talvolta negativo) nella manutenzione di basi di codice mature. Non applichi un unico numero a entrambi.
  3. Mettere a budget il debito di qualità. La velocità dell’IA porta con sé aumenti persistenti della complessità. Pianifichi una fase di consolidamento e la strumenti: tenga traccia della complessità ciclomatica ed esegua il rilevamento del codice duplicato a ogni release.
  4. Stimare l’intera curva, non solo la parte iniziale. Un guadagno di velocità di 10× che raddoppia la densità dei difetti non è un guadagno di 10×: è una pianificazione anticipata al prezzo di una coda di stabilizzazione più lunga.

In conclusione

Un progetto che secondo tutti i modelli di stima avrebbe dovuto richiedere da 7 mesi a 47 anni ha raggiunto una versione alpha pronta per i test in 7 giorni. Il moltiplicatore mediano di 4.240× non deve diventare il piano di progetto di nessuno. Ma è un segnale chiaro che la durata dello sviluppo di software complesso viene compressa dalla stessa forza che sta comprimendo l’effort. La ricerca pubblicata mostra che l’IA produce effetti che vanno da una spinta di 1,26× a un balzo di 20×, con un rischio reale di rendimenti negativi sulle basi di codice mature e un costo misurabile in termini di qualità. I modelli che ci dicevano che questo progetto avrebbe richiesto decenni sono gli stessi che ancora oggi girano nei fogli di calcolo di stima delle aziende. La domanda non è se l’IA agentica cambi la durata dei progetti: la ricerca ha già risposto. La domanda è se la sua pratica di stima sia al passo con le evidenze. Se i suoi numeri provengono ancora da un modello del 1981 calibrato su COBOL e assembly, è il momento di ricalibrare, o almeno di smettere di credere al calendario che stampa.

«Esiste ancora un ampio margine di miglioramento per affrontare meglio le sfide di previsione che si incontrano nella pratica.»

Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013

🏆 Competenza ingegneristica e cloud di fiducia

RIADVICE, il suo partner di fiducia per l’ingegneria del software

Progettiamo, sviluppiamo e mettiamo in produzione sistemi software complessi con la disciplina ingegneristica e gli strumenti necessari per consegnare nell’era dell’IA: nei tempi, nel budget e con la qualità attesa.

Scopra i nostri servizi →

📚 Fonti e approfondimenti

Questo articolo si basa su ricerche sottoposte a revisione paritaria, studi randomizzati controllati e rapporti di settore sulla produttività dello sviluppo software assistito dall’IA e sulla stima dell’effort software:

⚡ RIADVICE.com offre ingegneria affidabile, competenze cloud e soluzioni software di livello enterprise: nei tempi, nel budget e con la qualità attesa.

Condivida questo articolo

Articoli correlati