Vai al contenuto
SwankyForge
SwankyForge
Tutti gli insights
Articolo10 min di lettura

L'IA ha reso più economico scrivere codice. Non ha reso automaticamente più economici i progetti software.

Le misurazioni controllate mostrano accelerazioni modeste o negative dagli strumenti di coding con IA, e la scrittura del codice è una parte minoritaria del tempo di progetto: uno sconto IA onesto è piccolo e si può attribuire fase per fase.

Nel luglio 2025 l'organizzazione di ricerca non profit METR ha pubblicato uno studio randomizzato sugli strumenti di coding con IA applicati a lavoro reale. Sedici sviluppatori open source esperti hanno completato 246 attività nei propri repository, e ogni attività è stata assegnata a caso a "IA consentita" o "IA non consentita". Con l'IA le attività hanno richiesto il 19% di tempo in più. Prima dello studio gli stessi sviluppatori si aspettavano che l'IA li accelerasse del 24%. Dopo, erano ancora convinti che li avesse resi più veloci di circa il 20%.

Questo divario tra velocità percepita e velocità misurata è la parte utile per chi acquista software. I fornitori oggi pubblicizzano una consegna accelerata dall'IA e la mettono nel prezzo. Una parte del risparmio è reale. La maggior parte della promessa riguarda la digitazione, applicata a un budget che per lo più non è digitazione.

Questa nota tratta cosa dicono i dati del 2025, dove vanno le ore in un progetto di machine learning e cosa chiedere a un fornitore che propone uno sconto IA.

Cosa dicono i dati del 2025

Quattro fonti, quattro metodi. Nessuna sostiene l'idea che un progetto costi la metà perché il codice è stato scritto con un assistente.

Fonte Metodo Risultato
METR, luglio 2025 Studio randomizzato: 16 sviluppatori, 246 attività, repository con in media oltre 22k stelle e oltre 1M righe di codice Più lenti del 19% con l'IA; gli sviluppatori credevano di essere più veloci di circa il 20%
Stack Overflow Developer Survey, luglio 2025 Sondaggio, 26k–34k risposte per domanda L'84% usa o intende usare strumenti IA; il 46% non si fida della loro accuratezza, il 33% sì; il 66% indica "quasi giusto, ma non del tutto" come frustrazione principale
Rapporto Google DORA, settembre 2025 Sondaggio su quasi 5.000 professionisti della tecnologia Il 90% usa l'IA al lavoro; l'adozione dell'IA è associata a un throughput di consegna più alto e, comunque, a una minore stabilità della consegna
Bain Technology Report, settembre 2025 Ricerca di settore I team con assistenti vedono guadagni di produttività del 10–15%; scrivere e testare il codice occupa il 25–35% del tempo dall'idea al lancio

Il risultato di METR ha limiti che gli autori dichiarano apertamente: un campione piccolo, sviluppatori esperti su codebase grandi che già conoscevano e strumenti di inizio 2025 (Cursor Pro con Claude 3.5 e 3.7 Sonnet). Non dimostra che l'IA rallenti tutti. Dimostra due cose più circoscritte. Le accelerazioni dichiarate dagli interessati non sono una prova. E su codice maturo e complesso il tempo speso a scrivere prompt, attendere, rivedere e correggere può annullare il tempo risparmiato nella scrittura.

I sondaggi vanno nella stessa direzione da un'altra angolazione. L'uso è abituale: il 51% degli sviluppatori professionisti nel sondaggio di Stack Overflow usa strumenti IA ogni giorno, e gli intervistati di DORA ci passano una mediana di due ore al giorno. La fiducia no: il 45% degli intervistati di Stack Overflow dice che il debug del codice generato dall'IA richiede più tempo, e il 30% degli intervistati di DORA dichiara poca o nessuna fiducia nel codice generato dall'IA. La sintesi di DORA è che l'IA amplifica ciò che un team già è. I team solidi diventano più veloci. I team con test deboli e feedback lento rilasciano più modifiche e ne rompono di più.

Perché digitare costa meno non significa che il progetto costi meno

I due numeri di Bain bastano per vedere il tetto. Se scrivere e testare il codice è il 30% del tempo dall'idea al lancio, e un assistente rende quella parte più veloce del 30%, l'intero progetto diventa più veloce del 9%: 0.30 × 0.30 = 0.09. Se il codice diventasse gratuito e istantaneo, il restante 65–75% del lavoro resterebbe comunque. Gli ingegneri lo conoscono come legge di Amdahl: accelerare una fase di una pipeline è limitato dalla quota di tempo che quella fase occupa.

Il resto di un progetto è specifica, lavoro sui dati, integrazione, review, test, valutazione, deployment ed esercizio. Ognuna di queste parti ha le sue ragioni per non ridursi allo stesso ritmo.

  • La specifica è una conversazione con chi è responsabile del problema. Un assistente può scrivere una bozza del documento. Non può decidere che la metrica sia il margine e non il fatturato.
  • Il lavoro sui dati consiste soprattutto nel capire cosa significa una colonna, chi è responsabile della tabella e perché alcune righe sono duplicate. Scrivere l'SQL non è mai stata la parte lenta.
  • Il tempo di integrazione va nell'API di un altro team, nelle credenziali, nei rate limit e nelle finestre di rilascio.
  • La review diventa più pesante. Più codice generato al giorno significa più codice da leggere al giorno, e il codice quasi giusto è il più costoso da rivedere perché sembra finito.
  • Valutazione ed esercizio seguono il calendario. Si aspetta una settimana di traffico, una chiusura di fine mese o che un gruppo di holdout accumuli abbastanza dati.

Il risultato di DORA sulla stabilità è la versione misurata del punto sulla review. I team rilasciano più modifiche e, senza test automatici solidi e cicli di feedback rapidi, una quota maggiore di quelle modifiche fallisce.

Dove vanno le ore in un progetto di ML

La tabella seguente è illustrativa. È la nostra ripartizione approssimativa per un progetto di machine learning di medie dimensioni, come un sistema di raccomandazione o di previsione collegato a un prodotto esistente, insieme alle nostre ipotesi su quanto l'assistenza IA faccia risparmiare in ogni fase. Le percentuali sono opinioni di pianificazione, non misurazioni. Sostituitele con le vostre e rifate il conto.

Fase Quota di ore Ore su 600 Risparmio IA ipotizzato Ore risparmiate
Discovery: metrica, baseline, specifica 10% 60 0% 0
Accesso ai dati, pulizia, pipeline di feature 25% 150 15% 22,5
Modellazione ed esperimenti 15% 90 20% 18
Integrazione con i vostri sistemi 15% 90 20% 18
Test, valutazione, code review 15% 90 0% 0
Deployment, monitoraggio, rollback 10% 60 10% 6
Demo, accettazione, passaggio di consegne 10% 60 0% 0
Totale 100% 600 64,5, circa l'11%

Il ragionamento dietro ogni riga:

  • La discovery non risparmia nulla perché il suo risultato sono decisioni, e le decisioni vengono dal business.
  • Il lavoro sui dati ottiene un risparmio modesto. Gli assistenti scrivono rapidamente query, parser e controlli di validazione, ma la maggior parte delle ore va nell'attesa degli accessi e nella comprensione dei dati.
  • Modellazione e integrazione ottengono il risparmio maggiore perché contengono più codice ripetitivo: cicli di training, client API, serializzazione, configurazione.
  • Test e review si compensano a zero. Gli assistenti scrivono velocemente l'impalcatura dei test, e il codice generato in più aggiunge tempo di review. I team con suite di test solide possono vedere un guadagno; i team senza possono vedere una perdita.
  • Il deployment risparmia un po' sui template di configurazione. L'attesa che un rilascio canary raccolga traffico non si accorcia.

Alla nostra tariffa pubblicata per ML engineer di 50 € l'ora, 600 ore sono 30.000 € e 64,5 ore sono circa 3.200 €. Questo è l'ordine di grandezza di uno sconto IA onesto su un progetto di questo tipo: reale, utile, e lontanissimo dalla metà. Cade anche dentro l'intervallo del 10–15% di Bain, il che è una verifica di plausibilità, non una prova.

L'altro dato di Bain è il più interessante. Le aziende che hanno ridisegnato l'intero processo intorno all'IA, invece di limitarsi a distribuire assistenti, hanno riportato guadagni del 25–30%. Quel risparmio viene dal cambiare ciò che succede tra una riga di codice e l'altra: come si scrivono le specifiche, come funziona la review, come si testano i rilasci. È un cambiamento di processo, e richiede impegno prima di ripagare. Bain nota anche che tre aziende su quattro dicono che far cambiare alle persone il modo di lavorare è la parte più difficile.

Come è cambiato il lavoro dello sviluppatore

Il lavoro si è spostato dallo scrivere allo specificare e al verificare. Uno sviluppatore con un assistente passa meno tempo sulla prima versione e più tempo su tre cose.

  1. Istruzioni precise. L'assistente fa ciò che dice la specifica, quindi una specifica vaga ora produce più in fretta codice sbagliato ma plausibile.
  2. Leggere e correggere l'output. È qui che vive la frustrazione del "quasi giusto". Il codice sbagliato che fallisce in modo evidente costa poco. Il codice che supera il test ovvio e fallisce sul caso limite costa molto.
  3. I controlli che rendono sicura la velocità. Test, set di valutazione, controlli di tipo, rilasci graduali.

Nel lavoro di machine learning il terzo punto pesa più degli altri. Una modifica al modello che sembra corretta in un notebook può abbassare una metrica di business in produzione. Un assistente può scrivere l'harness di valutazione. Non può decidere cosa debba contenere il set di valutazione, né quanto costi al business una regressione.

Dove compaiono i risparmi

La nostra opinione, che è un'opinione e non una misurazione: gli assistenti fanno risparmiare tempo reale su

  • prototipi e analisi usa e getta, dove il quasi giusto basta per imparare qualcosa;
  • codice con uno schema chiaro: client API, classi di dati, configurazione, migrazioni di schema;
  • librerie poco conosciute, dove l'assistente sostituisce un'ora di lettura della documentazione;
  • prime bozze di test e documentazione, che poi una persona corregge.

Fanno risparmiare poco su decisioni, attese, coordinamento e review. Uno sconto IA credibile dovrebbe essere coerente con questa ripartizione.

Cosa chiedere a un fornitore che promette uno sconto IA

  • Dove esattamente l'IA ha tagliato ore? Chiedete la stima per fase, con e senza assistenza. Uno sconto che non si può collocare in una fase è uno sconto commerciale. Va bene, ma andrebbe chiamato così.
  • Chi rivede il codice scritto dall'IA, e come? Chiedete se una persona rivede ogni modifica, cosa controlla e se il tempo di review è nella stima.
  • Come si misura la qualità? Test sui percorsi critici, un set di valutazione per il comportamento del modello, un change failure rate. Se la risposta è che il codice funziona, chiedete come lo sanno.
  • Cosa succede quando il codice generato è sbagliato in produzione? Monitoraggio, rollback e un responsabile di reperibilità fanno parte del piano, non di una change request successiva.
  • Dove sta il repository? Se il codice resta nell'account del fornitore fino alla fattura finale, non potete verificare nulla di quanto sopra finché conta ancora.

Come lo gestiamo noi

Il nostro listino è pubblicato per ruolo e per ora, quindi ogni stima che diamo si può verificare come ore per tariffa, fase per fase. Vedete una demo funzionante ogni settimana, il repository sta nella vostra organizzazione dal primo giorno e ogni milestone viene fatturata solo dopo la vostra accettazione. Gli intervalli tipici di progetto sono pubblicati accanto al listino, e un teardown prezza separatamente discovery, proof of concept e produzione. Se l'assistenza IA rende una fase più veloce, si vede come meno ore in fattura, non come una promessa nella proposta.

Fonti

Ha un processo che costa troppo?

Ce ne parli. La prima call è gratuita e, se l'AI non è la risposta, glielo diciamo.

Parliamo del suo caso