Uno sviluppatore chiede a un assistente IA di costruire un’API. Cinque minuti dopo esiste un’applicazione funzionante: autenticazione, logging, database, test, magari anche un frontend presentabile. Nelle settimane successive altri sviluppatori intervengono, altri agenti IA rifattorizzano parti del sistema. Il codice gira, i test passano, l’applicazione va in produzione e qualcuno inizia a dipenderne.

Poi qualcosa si rompe, e la domanda che segue è: perché è stato costruito così?

In molte organizzazioni, in questo momento, nessuno saprebbe rispondere con sicurezza. Non per incompetenza di chi ha scritto il codice, e non perché lo strumento IA abbia sbagliato. Il problema è più strutturale: la velocità con cui si genera codice ha superato la velocità con cui lo si comprende.

Non è un’osservazione aneddotica. È misurabile, ed è già misurata.

Generare codice non è fare ingegneria del software

Generare codice sta diventando economico. L’ingegneria del software no. Restano suoi compiti decidere cosa costruire e perché, cosa succede quando qualcosa fallisce, come il sistema si integra con il resto, quali sono le implicazioni di sicurezza, chi ne è responsabile, come lo si modifica senza romperlo, come lo si ritira quando non serve più.

Uno strumento IA può contribuire a rispondere ad alcune di queste domande. Ma può anche produrre una risposta plausibile senza “comprenderne” le conseguenze, perché non le comprende nel senso in cui lo fa un ingegnere: non ha responsabilità, non ha memoria del contesto organizzativo, non paga il costo di un incidente. E chi riceve quella risposta può accettarla altrettanto velocemente, senza verificarla davvero. È in quel doppio salto, la macchina che genera senza responsabilità, l’umano che approva senza verifica, che si forma il debito.

I numeri dietro l’intuizione

Per anni “debito tecnico da IA” è rimasto un timore diffuso ma poco quantificato. Nel 2025 e nel 2026 diversi studi indipendenti hanno iniziato a metterci dei numeri sopra, e il quadro che emerge è coerente.

GitClear, su 623 milioni di modifiche di codice (2023-2026), registra il refactoring crollato al 3,8% — dal 21% del 2022, prima della diffusione degli assistenti IA — mentre la duplicazione di codice è salita dell’81%: il copia-incolla oggi supera di cinque volte la riscrittura pulita, un rapporto ribaltato rispetto al 2022. Chi usa l’IA in modo intensivo produce dalle 4 alle 10 volte più codice, ma il guadagno di velocità reale, misurato end-to-end, resta intorno al 25%: il resto si perde a valle, in revisione e correzione.

Chi scrive codice con l’IA non si fida del codice con l’IA

Nel Developer Survey 2025 di Stack Overflow il 46% diffida dell’accuratezza del codice IA (contro il 33% che si fida), il 66% lo definisce “quasi giusto ma non del tutto”, e il 45% impiega più tempo a correggerlo che a scriverlo da zero. Gli sviluppatori con oltre dieci anni di esperienza (chi in azienda revisiona il lavoro altrui) sono i più scettici in assoluto.

Anche chi usa l’IA sovrastima quanto lo sta aiutando

Il punto più critico è la percezione. In uno studio randomizzato di METR, 16 sviluppatori esperti hanno completato issue reali il 19% più lentamente usando l’IA, ma restavano convinti di essere stati il 20% più veloci. È un dato che vale più di molte opinioni: il debito di comprensione è difficile da notare dall’interno perché la sensazione di controllo resta alta anche quando la produttività reale cala.

L’IA non crea disciplina dove non c’era. Il report DORA 2025 di Google conferma il meccanismo su scala più ampia: l’IA amplifica ciò che già esiste, accelerando i team con basi solide e il degrado di quelli con sistemi frammentati, che “generano debito tecnico più velocemente” invece di generarne meno. Nello stesso report il 30% dei professionisti dichiara scarsa fiducia nel codice IA, mentre oltre l’80% percepisce comunque un aumento di produttività; il divario tra sensazione e verifica, in un solo confronto.

Il debito di comprensione ha almeno sei facce

Il debito tecnico classico, architettura scadente, dipendenze non aggiornate, test insufficienti, non scompare con l’IA. In alcuni casi peggiora, perché diventa più facile da produrre. Ma sopra si sta formando uno strato diverso, che riguarda non cosa il sistema fa ma se qualcuno lo sa spiegare:

• Comprensione: nessuno in azienda riesce a spiegare con sicurezza perché il sistema è fatto così.

• Architettura: i singoli componenti hanno senso presi da soli, l’insieme no.

• Dipendenze: librerie e framework introdotti perché suggeriti dall’IA, non scelti consapevolmente.

• Decisioni: migliaia di scelte incorporate nel codice, senza traccia del perché siano state prese.

• Validazione: il codice viene generato più velocemente di quanto possa essere revisionato in modo sostanziale — coerente con il dato Stack Overflow sul tempo di debug.

• Ownership: nessuno è in grado di modificare il sistema in sicurezza senza chiedere all’IA di rispiegare il proprio stesso output.

Nessuna di queste voci compare in un audit di sicurezza standard. Nessuna genera un errore a runtime. Ma insieme determinano quanto un’organizzazione può fidarsi di ciò che ha costruito.

Dove si sposta il collo di bottiglia

Per decenni il vincolo principale nello sviluppo software è stato “non abbiamo abbastanza sviluppatori per scrivere codice”. L’IA generativa attacca esattamente questo vincolo, e lo fa bene. Ma se generare codice diventa drammaticamente più veloce, il vincolo si sposta a valle: non abbiamo abbastanza giudizio ingegneristico per revisionare, capire e governare quello che stiamo generando.

I dati DORA e METR descrivono lo stesso spostamento da due angolazioni diverse: l’IA amplifica il divario tra chi ha già disciplina ingegneristica e chi non ce l’ha, e lo fa mentre riduce — non aumenta — la percezione del rischio da parte di chi la usa. Sapere scrivere codice resta utile. Sapere perché il sistema deve contenere quel codice, come si comporta sotto carico, cosa succede quando una dipendenza smette di essere mantenuta, chi è responsabile quando qualcosa si rompe: questo diventa il fattore che separa un’organizzazione che scala da una che accumula rischio silenzioso.

Cosa succede tra qualche anno

Tra qualche anno molte organizzazioni si troveranno con centinaia di applicazioni costruite o pesantemente modificate con strumenti IA, spesso da persone che nel frattempo sono passate ad altri progetti o ad altre aziende. Alcune di quelle applicazioni saranno diventate critiche per il business senza che nessuno lo avesse pianificato. L’azienda saprà che funzionano, ma non saprà necessariamente come o perché.

A quel punto servirà qualcuno che sappia ricostruire cosa è stato fatto, quali ipotesi erano valide allora e quali lo sono ancora, di cosa ci si può fidare e cosa va sostituito prima che si rompa in produzione. Non è un problema di sintassi, ma un problema di architettura e di responsabilità. Lo stesso lavoro che oggi chiamiamo audit tecnico, solo su una scala molto più grande di quella a cui siamo abituati.

Non è un invito a smettere di usare l’IA

Sarebbe la conclusione sbagliata, e i dati stessi lo confermano: usata bene, l’IA generativa riduce tempi di sviluppo reali e libera capacità ingegneristica per i problemi che richiedono effettivamente giudizio. Il punto non è se usarla, ma chi resta responsabile di architettura, sicurezza, dipendenze, testing, osservabilità e ciclo di vita mentre la si usa, e se quella responsabilità è esplicita o solo presunta.

È lo stesso principio su cui costruiamo il nostro lavoro con l’IA nei progetti dei clienti: prima la produzione responsabile: architettura verificata, governance dei dati, sicurezza, osservabilità, poi la velocità. L’IA può aiutare a costruire la casa più in fretta. Qualcuno deve comunque poter spiegare perché le fondamenta sono dove sono.

Una domanda, per chi legge da un ruolo tecnico o di direzione: nella vostra organizzazione, se il sistema più recente costruito con assistenza IA smettesse di funzionare domani mattina, chi sarebbe in grado di spiegare perché è stato costruito così, e quanto ci vorrebbe?

Parliamone.

Verifichiamo dipendenze, sicurezza e comportamento in produzione prima che un sistema costruito con l’IA diventi critico per il business. Scopri il nostro approccio qui: https://www.reiser.it/reiser-servizi-ai/