Ogni azienda con qualche anno di storia ha un software "di cui ci si fida ma che nessuno capisce". È stato scritto da un collaboratore che non c'è più, da una società che ha cambiato nome, da dieci mani diverse in quindici anni. Funziona, finché funziona. Quando bisogna cambiarlo, si scopre che nessuno sa cosa succede se si tocca quel pezzo.
Si chiama software legacy, "eredità": non necessariamente vecchio, ma difficile da capire e da modificare. Oggi le persone che si occupano di modernizzarlo hanno a disposizione strumenti di intelligenza artificiale. Questa guida spiega, a chi decide e non è tecnico, che cosa questi strumenti fanno bene, dove sbagliano, quali regole servono per usarli senza rischi e quali ruoli umani restano insostituibili. Nessuna promessa miracolosa: solo cosa è realistico aspettarsi.
Che cosa rende "legacy" un software
Il codice legacy ha di solito alcune di queste caratteristiche:
- Nessuna documentazione, o documentazione ferma a dieci anni fa.
- Nessun test automatico: chi modifica non ha modo di sapere cosa ha rotto.
- Regole di business nascoste nel codice: arrotondamenti, eccezioni per singoli clienti, casi particolari aggiunti di fretta.
- Tecnologie in declino o non più supportate.
- Dipendenza da una persona: "lo sa solo Mario".
- Paura di toccarlo: ogni intervento è un rischio, quindi si fanno solo toppe.
L'insieme di tutto questo si chiama debito tecnico: ogni scorciatoia presa in passato è un prestito che si paga con gli interessi, sotto forma di interventi più lenti, più costosi e più rischiosi.
Dove l'IA aiuta davvero
Tre attività, in cui gli strumenti attuali danno un aiuto concreto e misurabile.
1. Capire cosa c'è dentro
È la parte in cui l'IA dà più valore. Può leggere migliaia di righe in pochi minuti e rispondere a domande del tipo:
- "Quali parti del programma toccano la tabella dei clienti?"
- "Cosa fa questa funzione di quattrocento righe?"
- "Quali moduli dipendono da questa libreria obsoleta?"
Il risultato è una prima mappa del sistema, che un analista umano avrebbe impiegato giorni a costruire. Attenzione: è una prima mappa. Ogni affermazione va verificata, perché lo strumento può essere sicuro di sé anche quando sbaglia.
2. Scrivere documentazione e test di partenza
Dal codice si possono ricavare bozze di descrizioni ("questa funzione calcola lo sconto in base a tre soglie") e di test automatici che fissano il comportamento attuale. Sono bozze, non verità: serve qualcuno che le legga e dica "sì, questa è la regola" oppure "no, questo è un errore storico che i clienti si aspettano ancora".
3. Tradurre e riscrivere le parti ripetitive
Convertire codice dalla sintassi vecchia alla nuova, aggiornare chiamate a librerie, ripetere lo stesso schema su cento file: lavoro in cui l'IA è veloce. Il risultato va rivisto, ma il tempo risparmiato sulla parte meccanica è reale.
Dove l'IA sbaglia (e perché è un problema)
È qui che molte aspettative si scontrano con la realtà.
Capisce il codice, non il tuo business. Se un'azienda arrotonda sempre per eccesso perché un cliente importante lo pretende dal 2011, nel codice c'è scritto come, non perché. Lo strumento potrebbe "correggere" la regola, ritenendola un errore.
Può inventare. Gli strumenti generativi producono risposte plausibili anche quando non hanno abbastanza informazioni. In un riassunto di codice questo si traduce in affermazioni sicure e false.
Perde il filo nei sistemi grandi. Ogni strumento lavora su una quantità limitata di testo per volta. In un sistema con migliaia di file, rischia di ragionare su una parte senza vedere le altre.
Produce codice che funziona ma è mediocre. Il codice generato spesso supera i controlli e introduce nuovo debito tecnico: duplicazioni, scelte incoerenti, soluzioni che nessuno poi capisce. Si chiama "debito generato".
Non risponde delle conseguenze. Se una fattura esce con l'importo sbagliato, nessuno può citare in giudizio uno strumento. La responsabilità è di chi ha approvato il lavoro.
In un articolo dedicato ai rischi delle applicazioni create con l'IA senza controllo ("Vibe coding: i rischi di sicurezza di un'app creata con l'IA") abbiamo visto che lo stesso schema vale anche per il codice nuovo: l'IA scrive, ma qualcuno deve verificare.
Un metodo in sei passi
Un processo prudente di modernizzazione assistita dall'IA non è "dai il codice allo strumento e aspetta". Ha tappe precise, e ogni tappa ha un responsabile umano.
Passo 1 — Audit e mappa
Si esamina il sistema per capire cosa contiene: moduli, dati, integrazioni, tecnologie. L'IA accelera la lettura; un analista o architetto valida la mappa e la completa parlando con le persone che usano il software ("Cosa fa quando succede X?").
Risultato: un documento condiviso con moduli, dipendenze e punti critici.
Passo 2 — Scomporre in pezzi gestionabili
Un sistema intero è troppo grande per essere cambiato in una volta. Si divide in moduli con confini chiari (fatturazione, anagrafiche, magazzino…) e si decide l'ordine. Questa è una decisione di progetto: si sceglie in base a rischio, valore per l'azienda e dipendenze, non in base a quello che è più facile da tradurre.
Passo 3 — Un pilota piccolo e misurabile
Si sceglie un modulo a basso rischio e lo si modernizza per intero, misurando: tempo impiegato, errori trovati, quanto del lavoro dell'IA è stato accettato così com'è e quanto corretto. È la fase che evita illusioni: "su questo modulo l'IA ha fatto risparmiare il 25% del tempo ma ha richiesto più revisione del previsto" vale più di qualsiasi promessa.
Passo 4 — Traduzione e riscrittura con revisione
Si traducono e riscrivono i moduli, con l'IA che produce bozze e uno sviluppatore esperto che le rivede riga per riga, soprattutto sulle parti che toccano denaro, dati personali e permessi di accesso. Regola di base: l'IA non approva mai il proprio lavoro.
Passo 5 — Test che bloccano il comportamento
Prima si fissa il comportamento del vecchio sistema con test automatici (anche generati con l'IA, poi verificati da un tester). Poi si fa girare il nuovo sistema sugli stessi dati e si confrontano i risultati. Le differenze sono di due tipi: errori da correggere e comportamenti storici da decidere se mantenere.
Passo 6 — Rilascio a ondate
Si porta in produzione un modulo alla volta, con un piano per tornare indietro e un periodo di osservazione. Il project manager coordina tempi, comunicazione agli utenti e collaudo.
Quanto può far risparmiare? Una stima prudente
Non esistono numeri universali, e diffida di chi ne promette. Come ragionamento, ecco le ipotesi su un progetto di modernizzazione di medie dimensioni, dichiarate in modo da poterle rifare con i tuoi dati:
Ipotesi: 200 giornate di lavoro complessive in un approccio tradizionale; tariffa media 450 euro al giorno; suddivisione indicativa di quelle 200 giornate: 20% analisi e mappatura, 40% traduzione e riscrittura, 25% test e verifica, 15% coordinamento e rilascio.
| Attività | Peso | Può aiutare l'IA? | Riduzione prudente del tempo |
|---|---|---|---|
| Analisi e mappatura | 20% (40 gg) | Sì, per la lettura iniziale | 20 – 30% |
| Traduzione e riscrittura | 40% (80 gg) | Sì, sulle parti ripetitive | 15 – 30% |
| Test e verifica | 25% (50 gg) | In parte, per le bozze di test | 10 – 20% |
| Coordinamento e rilascio | 15% (30 gg) | Poco | 0 – 5% |
Con queste ipotesi il risparmio complessivo sta tra il 12% e il 24% circa (somma dei risparmi di riga: da 25 a 48 giornate su 200), cioè tra 11.250 e 21.600 euro. Una cifra significativa, ma ben lontana dal "dimezzo i costi". E attenzione: parte del risparmio si perde se la revisione è trascurata, perché gli errori scoperti tardi costano molto di più di quelli trovati subito.
Questi numeri sono ipotesi di lavoro, non dati di mercato: il valore del ragionamento sta nel metodo. Chiedi sempre al fornitore di mostrarti dove, concretamente, userà l'IA e quanto stima di risparmiare su ogni attività.
Regole per le aziende che commissionano il lavoro
Se stai per affidare a un fornitore un progetto di modernizzazione, ecco una lista di controllo da usare prima di firmare.
- Il codice resta tuo. Chiedi per iscritto dove viene elaborato: alcuni strumenti di IA inviano il codice a servizi esterni. Se contiene dati personali, segreti commerciali o credenziali, serve una scelta consapevole (contratti con il fornitore dello strumento, versioni aziendali, ambienti isolati).
- Niente segreti nel codice dato in pasto allo strumento. Password, chiavi di accesso e dati reali di clienti vanno rimossi o sostituiti prima.
- Revisione umana obbligatoria. Nessuna riga prodotta dall'IA entra in produzione senza che una persona l'abbia letta e approvata.
- Test prima, non dopo. Il comportamento attuale va fissato con test, altrimenti non esiste un criterio per dire "è uguale".
- Pilota prima del progetto. Un modulo piccolo, con misure.
- Tracciabilità. Chi ha fatto cosa, cosa è stato generato, chi l'ha approvato.
- Prezzi trasparenti. Se l'IA riduce i tempi, la riduzione deve vedersi nell'offerta; ma un prezzo troppo basso deve far scattare una domanda: dove si risparmia?
Domande da fare al fornitore
- "Quali strumenti di IA usate e per quali attività?"
- "Che cosa succede ai miei dati e al mio codice quando passano da questi strumenti?"
- "Chi rivede il lavoro? Con quale esperienza?"
- "Mi mostrate un caso simile con numeri veri (tempi, errori trovati, risparmio)?"
- "Come garantite che il software nuovo si comporti come il vecchio?"
- "Cosa non lasciate fare all'IA?"
La risposta all'ultima domanda dice molto: un professionista serio ha una lista; chi risponde "niente, fa tutto lui" va guardato con sospetto.
Il fattore umano: perché le persone non spariscono
Nei progetti di modernizzazione, la fatica non è scrivere codice nuovo: è sapere cosa deve fare. E questo sapere è fatto di:
- memoria dell'azienda: perché una regola esiste, quale cliente la pretende, cosa è già andato storto;
- giudizio: cosa tenere, cosa cambiare, cosa eliminare;
- responsabilità: qualcuno deve poter dire "lo garantisco".
Un analista che intervista gli utenti, un progettista che ridisegna l'architettura, uno sviluppatore che rivede e corregge, un tester che confronta vecchio e nuovo, un project manager che tiene insieme persone e scadenze: sono ruoli che l'IA rende più efficienti, non superflui. Anzi, con il codice che si produce più in fretta, la qualità della revisione diventa più importante, non meno.
Dove servono ancora le persone
La modernizzazione assistita dall'IA è un lavoro di squadra con regole chiare. L'analista decide cosa va conservato. Il progettista disegna come. Lo sviluppatore rivede ogni modifica. Il tester dimostra che nulla si è rotto. Il project manager tiene sotto controllo costi e tempi. L'IA è uno strumento nelle loro mani: più veloce di loro in alcune cose, e priva di qualunque responsabilità sul risultato.
In sintesi
- Il software legacy è difficile da capire e da cambiare più che "vecchio": mancano documentazione, test e conoscenza.
- L'IA aiuta soprattutto a leggere, documentare, abbozzare test e tradurre parti ripetitive.
- Non capisce le regole di business non scritte, può inventare e non risponde del risultato.
- Un metodo prudente procede a piccoli pezzi: mappa, scomposizione, pilota, traduzione con revisione, test, rilascio a ondate.
- Con ipotesi realistiche, il risparmio è una quota importante ma non miracolosa (indicativamente 10–25% del tempo), e dipende dalla qualità della revisione.
- Le persone, e le loro competenze, restano il centro del progetto.
Hai un software difficile da toccare e vuoi un parere? Iscriviti alla waitlist di LancerJob: quando il portale sarà online potrai descrivere il tuo caso e ricevere proposte da professionisti .NET. Per approfondire, leggi anche "Migrare da .NET Framework a .NET moderno" e "Dall'Excel al software: quando cambiare".