Il contesto e le prime evidenze

Negli ultimi due anni l’integrazione di strumenti di programmazione assistita da intelligenza artificiale, comunemente noti come “vibe coding”, è stata accolta con grande entusiasmo. La promessa era semplice: se l’IA scrive il codice più velocemente, i team dovrebbero consegnare nuove funzionalità in tempi più brevi. Tuttavia, un nuovo studio condotto da Undo, azienda specializzata in strumenti di depurazione, rivela una realtà molto più complessa.

La ricerca, commissionata alla società di consulenza Coleman Parkes, ha intervistato 300 responsabili senior di ingegneria negli Stati Uniti e nel Regno Unito tra luglio e agosto 2026. Tutti i partecipanti lavorano in aziende con fatturato superiore a 250 milioni di dollari, prevalentemente nei settori finanziario, delle reti e del design di chip, dove un’interruzione del servizio ha costi elevatissimi.

Il risultato principale è sorprendente: il 79% dei leader afferma che i propri team producono codice più rapidamente grazie all’IA, ma i cicli di rilascio non sono migliorati. Il colpevole è la depurazione, che ora occupa il 42% della settimana lavorativa, un dato che comprende tutti i tipi di errori, non solo quelli introdotti dall’IA.

Come viene speso il tempo di un team di sviluppo

Per capire meglio il fenomeno, lo studio suddivide le attività settimanali di un tipico team di sviluppo (40 ore):

    • Produzione di codice: 9,8 ore (25%).
    • Depurazione durante lo sviluppo: 9,7 ore (24%).
    • Risoluzione di incidenti in produzione: 7,2 ore (18%).
    • Altre attività (riunioni, documentazione, ecc.): 13,3 ore (33%).

La depurazione, in entrambe le sue forme, è quasi pari al tempo dedicato alla scrittura. Se l’IA riducesse a metà le ore di produzione, si risparmierebbero circa cinque ore a settimana. Ma se il codice generato richiede altre cinque ore di depurazione, il beneficio si annulla: il tempo non viene guadagnato, ma semplicemente spostato da una fase all’altra.

Il costo del codice “quasi corretto”

La Stack Overflow Developer Survey 2025, con oltre 49.000 risposte, individua la più grande fonte di frustrazione per i programmatori: il 66% si lamenta di soluzioni IA “quasi giuste ma non del tutto”. Il 45% aggiunge che la depurazione di quel codice richiede più tempo rispetto al debugging del proprio codice.

Il codice che semplicemente non funziona è più facile da individuare: genera un errore immediato, la traccia è leggibile e la correzione è veloce. Il vero problema emerge con il codice “quasi corretto”, che compila, supera i test di base e sembra pulito, ma si rompe su casi limite non coperti (lista vuota, anno bisestile, fuso orario differente). Greg Law, fondatore di Undo, spiega: «quando il codice è chiaramente rotto, la causa è di solito facile da trovare». Invece, i bug che si manifestano solo in produzione richiedono indagini più lunghe e costose.

Incidenze concrete e “allucinazioni” dell’IA

Le conseguenze di integrare codice poco compreso sono evidenti. Il 35% del codice generato dall’IA arriva in produzione prima che il team lo comprenda completamente. Nei sei mesi precedenti, l’81% dei leader ha sperimentato almeno un’incidenza o un’interruzione di servizio attribuita all’uso di strumenti di programmazione IA.

Un dato ancora più inquietante: il 93% degli intervistati ha riconosciuto di essere stato condotto su una falsa pista da un’allucinazione dell’IA, ovvero una risposta errata che ha indicato una causa radice inesatta, talvolta persino suggerita dallo stesso strumento. Questo ribalta il tradizionale processo di debugging, dove il fallimento indica dove guardare; ora l’IA può indirizzare verso una zona sbagliata, allungando notevolmente i tempi di investigazione.

Utilizzo dell’IA nelle attività di sviluppo

La Stack Overflow Survey 2026, pubblicata il 6 ottobre, mostra come gli sviluppatori impieghino l’IA:

    • 69,3% la usa per generare codice in ambiti che già conoscono bene.
    • 63,8% la utilizza per depurare, risolvere problemi o refactoring.
    • 58,1% la impiega per scrivere test.
    • Solo il 13,8% si limita all’autocompletamento (es. GitHub Copilot).

Questi numeri indicano che l’IA è diventata una “seconda opinione” sul codice più che un semplice acceleratore di digitazione. Tuttavia, la fiducia non è cresciuta allo stesso ritmo: solo il 48% si fida del codice generato quando può verificarlo facilmente, e appena il 6,6% lo userebbe per decisioni critiche senza revisione.

Limiti dello studio e prospettive future

È importante contestualizzare i risultati. Undo, produttore di strumenti di debugging, ha un interesse diretto a mostrare la depurazione come un’attività costosa. Il rapporto conclude che l’82% dei partecipanti ritiene che gli agenti di codifica sarebbero più utili se avessero accesso al contesto di runtime, una caratteristica offerta da Undo stesso.

La campionatura è ristretta: 300 leader di grandi aziende statunitensi e britanniche, il 93% dei quali lavora con C o C++ in sistemi mission‑critical. Il 42% del tempo di depurazione comprende tutti gli errori, non distinguendo tra quelli introdotti dall’IA e quelli tradizionali. Per chi sviluppa applicazioni web leggere o utilizza Python/JavaScript, il quadro potrebbe essere molto diverso.

Che cosa possono fare gli sviluppatori?

Di fronte a questi dati, le organizzazioni possono adottare diverse strategie:

    • Integrare il contesto di esecuzione: strumenti che forniscono informazioni di runtime (tracciamenti, metriche) possono ridurre le false piste.
    • Rafforzare i test automatizzati: coprire casi limite (date particolari, input vuoti, diversi fusi orari) diminuisce le sorprese in produzione.
    • Formazione continua: insegnare ai team a leggere criticamente il codice generato dall’IA, evitando la tentazione di accettarlo acriticamente.
    • Politiche di revisione: stabilire che ogni snippet prodotto dall’IA debba passare almeno una revisione umana prima di essere mergiato.

In sintesi, l’IA ha effettivamente aumentato la velocità di scrittura del codice, ma la vera sfida ora è gestire la qualità e la comprensibilità del risultato. Fino a quando gli strumenti non riusciranno a fornire un contesto più ricco e a ridurre le “allucinazioni”, la depurazione continuerà a consumare la maggior parte del tempo dei team, neutralizzando i potenziali guadagni di produttività.