Software legacy con AI: come valutare se è recuperabile

La conclusione prima di tutto

Puoi recuperare un software legacy con codice AI dentro, ma solo se sai cosa stai guardando. La maggior parte degli audit fallisce perché tratta il codice AI generato come codice normale: stesse metriche, stessa logica di valutazione. Non funziona così. Il codice prodotto da strumenti AI ha difetti strutturali specifici che un audit standard non intercetta. Questa guida ti dà i passi per farlo nel modo giusto, con i segnali concreti che separano un sistema recuperabile da uno che vale la pena riscrivere.

Passo 1: capire cosa hai davvero tra le mani

Prima di qualsiasi valutazione tecnica, serve un inventario. Non un inventario formale da presentare in riunione: una mappa rapida di cosa gira, dove, e con quale frequenza viene toccato.

Cosa fare

Chiedi al team (o al fornitore uscente) di elencare tutti i moduli del sistema, distinguendo tra codice scritto da sviluppatori umani e codice generato o assistito da AI. Se non lo sanno con certezza, ci sono segnali riconoscibili: blocchi di codice uniformi e privi di commenti, pattern ripetitivi identici in più file, nomi di variabili generici tipo result, data, response senza contesto.
Annota anche quando ogni modulo è stato scritto l’ultima volta e con quale frequenza viene modificato. Un modulo che nessuno tocca da due anni è diverso da uno che viene aggiornato ogni settimana.

Cosa va storto di solito

Il team sottostima la quantità di codice AI generato. Spesso il codice è stato inserito pezzo per pezzo, da persone diverse, senza una traccia sistematica. Trovi snippet generati da AI mescolati a codice scritto a mano nello stesso file, a volte nella stessa funzione. Senza un’analisi file per file, l’inventario è inutile.

Passo 2: l’audit tecnico in quattro dimensioni

Questo è il cuore della valutazione. Misuri quattro aree, ognuna con un peso diverso sulla decisione finale.

Copertura dei test

Quante righe di codice sono coperte da test automatici? Sotto il 30% su un sistema che va in produzione ogni settimana, sei in zona rischio. Il codice AI generato tende a non avere test: chi lo produce spesso lo incolla e va avanti. Se trovi moduli AI senza un singolo test, considera quel modulo come una scatola nera che non puoi toccare senza rompere qualcosa.

Dipendenze e aggiornabilità

Elenca tutte le librerie esterne usate dal sistema. Per ognuna, verifica se è ancora mantenuta e se esiste un percorso di aggiornamento alla versione attuale. Le dipendenze fuori supporto sono il segnale più chiaro che un sistema sta andando verso il punto di non ritorno. Il codice AI generato spesso usa librerie popolari al momento della generazione, che però possono essere già deprecate qualche mese dopo.

Qualità del codice AI generato

Qui serve un occhio tecnico. Il codice AI generato ha pattern riconoscibili: funzioni troppo lunghe, logica duplicata, assenza di gestione degli errori, commenti che descrivono l’ovvio invece di spiegare il perché. Se il codice supera una certa soglia di complessità ciclomatica (indicativamente oltre 20-25 per funzione), diventa difficile da modificare senza introdurre regressioni.

Documentazione esistente

Documentazione zero non significa automaticamente sistema irrecuperabile, ma allunga i tempi di qualsiasi intervento. Se vuoi capire come gestire questo aspetto in modo sistematico, la guida su come recuperare documentazione mancante nel software copre i passi operativi per ricostruirla anche a partire dal codice.

Cosa va storto di solito

Si tende a guardare solo la copertura dei test e a fermarsi lì. Le dipendenze vengono ignorate finché non si rompe qualcosa in produzione. La qualità del codice AI generato viene valutata “a occhio” da chi non conosce i pattern specifici di quel tipo di codice. Il risultato è una valutazione parziale che porta a decisioni sbagliate.

Passo 3: il segnale che cambia tutto

C’è una domanda che vale più di qualsiasi metrica: il team che ha scritto questo codice è ancora disponibile?
Se il codice AI è stato generato con un modello specifico, da una persona specifica, in un contesto specifico, e quella persona non c’è più, la situazione cambia radicalmente. Il codice AI generato senza documentazione e senza test è già difficile da leggere. Senza nessuno che ricordi le scelte fatte, diventa un sistema che puoi solo osservare dall’esterno.
Questo non vuol dire che sia irrecuperabile. Vuol dire che il costo del recupero sale, e che devi mettere in conto una fase di reverse engineering prima di poter toccare qualcosa. Se stai valutando un sistema in questo stato dopo un cambio di fornitore, la guida su come prendere in carico codice da un fornitore precedente copre esattamente questa situazione.

Passo 4: costruire il quadro decisionale

A questo punto hai i dati. Devi trasformarli in una decisione: recuperare, riscrivere parzialmente, o riscrivere da zero.
La logica che usiamo è semplice: conta quante delle quattro dimensioni dell’audit sono in ordine (test sufficienti, dipendenze aggiornabili, codice leggibile, documentazione presente anche parzialmente). Se tre o quattro sono in ordine, il recupero è quasi sempre la scelta giusta. Se solo una o zero sono in ordine, la riscrittura mirata o completa diventa più conveniente.
Il caso più comune che troviamo è due su quattro: test quasi assenti, dipendenze parzialmente obsolete, ma codice ancora leggibile e qualcuno che ricorda la logica di business. In questo caso il recupero è possibile, ma richiede un piano di lavoro che includa una fase di stabilizzazione prima di qualsiasi nuova funzionalità.
Se sei in questa situazione e vuoi un confronto tecnico esterno prima di decidere, raccontaci il tuo caso e vediamo insieme cosa ha senso fare.

Passo 5: i problemi specifici del codice AI generato

Il codice AI generato non è semplicemente “codice scritto male”. Ha caratteristiche proprie che lo rendono diverso dal codice legacy tradizionale, e che richiedono attenzione specifica.
Il problema più sottovalutato è la coerenza interna. Un modello AI genera codice che funziona nel contesto della singola richiesta, ma non necessariamente è coerente con il resto del sistema. Trovi la stessa logica implementata in tre modi diversi in tre punti diversi del codice, perché ogni generazione era indipendente. Questo frammenta la base di codice in modo che non si vede subito, ma emerge quando devi fare una modifica che tocca più moduli.
Il secondo problema è la dipendenza da versioni specifiche di librerie. I modelli AI tendono a generare codice basato sul training data, che ha una data di taglio. Se il sistema usa librerie generate con un modello di due o tre anni fa, potresti trovare pattern che erano corretti allora ma che oggi sono deprecati o insicuri.
Terzo: la gestione degli errori. Il codice AI generato spesso ignora i casi limite. Funziona nel caso felice, ma non gestisce eccezioni, timeout, o input malformati. In produzione, questo si traduce in crash silenziosi o comportamenti imprevedibili difficili da diagnosticare.
Per chi gestisce già un sistema con moduli AI in produzione, la guida sulla manutenzione di software con AI integrato entra nel dettaglio di come strutturare il lavoro di manutenzione continuativa.

Passo 6: quando il recupero non conviene

Diciamolo chiaramente: il recupero è sopravvalutato come opzione predefinita. Molti team scelgono di recuperare per paura del costo di una riscrittura, senza calcolare il costo del recupero stesso.
Ci sono tre situazioni in cui la riscrittura è la scelta migliore, anche se fa più paura.
La prima: le dipendenze core del sistema sono fuori supporto e non esiste un percorso di aggiornamento praticabile. Aggiornare il framework o il linguaggio richiederebbe riscrivere comunque la maggior parte del codice: a quel punto tanto vale farlo con un’architettura pulita.
La seconda: il codice AI generato copre più del 60-70% del sistema, non ha test, non ha documentazione, e nessuno ricorda le scelte originali. Recuperare significa capire un sistema che non si capisce, con il rischio di introdurre bug che non vedi fino a produzione.
La terza: il sistema non regge il carico attuale e le modifiche necessarie per farlo reggere sono strutturali. Rattoppare un’architettura che non scala non è recupero, è rinvio.
Se sei in uno di questi casi, la guida sul refactoring del software legacy aziendale ti aiuta a capire come impostare una riscrittura in modo che non blocchi l’operatività.

Passo 7: il piano di recupero minimo

Se hai deciso che il recupero vale la pena, hai bisogno di un piano con priorità chiare. Non si recupera tutto insieme: si stabilizza prima, si migliora dopo.
La sequenza corretta è questa:

1. Congela le funzionalità: nessuna nuova feature finché il sistema non è stabile.
2. Scrivi i test sui moduli più critici, anche retroattivamente. Non devi coprire tutto: coprire i percorsi principali ti dà già una rete di sicurezza.
3. Aggiorna le dipendenze con rischi di sicurezza noti, partendo da quelle con CVE attivi.
4. Documenta la logica di business mentre la capisci, non dopo.
5. Solo a questo punto, pianifica le modifiche evolutive.

Saltare uno di questi passi, soprattutto i primi due, porta quasi sempre a dover ricominciare da capo dopo qualche mese.

Domande frequenti

Q: Cosa si intende per software legacy con codice AI?
A: Un software aziendale datato che include moduli generati o assistiti da strumenti di intelligenza artificiale, spesso aggiunti in fasi successive allo sviluppo originale. Questi moduli hanno caratteristiche di manutenzione diverse dal codice scritto interamente da sviluppatori.
Q: Come si capisce se il codice legacy è recuperabile?
A: Si parte da un audit su quattro dimensioni: copertura dei test, aggiornabilità delle dipendenze, leggibilità del codice AI generato e presenza di documentazione anche parziale. Se almeno due di queste quattro sono in ordine, il recupero è spesso conveniente rispetto a una riscrittura completa.
Q: Quali problemi specifici crea il codice generato da AI in un sistema legacy?
A: I tre principali sono: incoerenza interna tra moduli generati in sessioni diverse, dipendenze basate su versioni ormai deprecate, e gestione degli errori assente o incompleta. Questi problemi si amplificano nel tempo e diventano molto più costosi da risolvere se ignorati.
Q: Quando conviene riscrivere invece di recuperare?
A: Quando le dipendenze core sono fuori supporto senza percorso di aggiornamento praticabile, quando il codice AI generato copre la maggior parte del sistema senza test né documentazione, o quando le modifiche necessarie per far reggere il sistema sotto carico sono strutturali e non puntuali.

Se gestisci un software aziendale con moduli AI integrati e non sai da dove partire per valutarne lo stato, raccontaci il tuo caso: facciamo un’analisi tecnica del codice e ti diciamo cosa ha senso fare.