Case study: proteggere un prodotto legacy ancora redditizio con l'AI

Un'azienda con oltre quattro decenni di codice alle spalle del proprio prodotto di punta ci ha contattato con una domanda che molte aziende si stanno facendo, spesso a bassa voce: come si fa a tenere competitivo un sistema profittevole e business-critical quando la tecnologia su cui è costruito non è più mainstream?

Il prodotto è solido, redditizio, ancora in uso attivo presso i clienti. Riscriverlo da zero non è nei piani di nessuno, e i numeri non lo giustificherebbero. Quello di cui avevano bisogno era un modo per proteggere decenni di logica di business accumulata, ridurre la dipendenza dalle persone chiave, accorciare i tempi di onboarding e dare al team strumenti moderni per continuare a muoversi velocemente. Volevano capire se l'Al potesse aiutarli, e volevano una risposta onesta.

Il contesto di business

Il prodotto è scritto in un linguaggio legacy di nicchia, nel caso specifico xbase++ (famiglia dBASE), ma la dinamica è la stessa per qualunque stack uscito dal mainstream: Delphi, Visual Basic 6, COBOL, vecchie versioni di PHP o di .NET Framework. La codebase è grande, matura e racchiude anni di regole di business che un competitor farebbe molta fatica a replicare. È ciò che la rende strategicamente preziosa, ed è ciò che la rende rischiosa da toccare.

Come molte aziende che vivono di sistemi longevi, anche questa si trovava davanti a una serie di pressioni che non avevano nulla a che fare con la qualità del prodotto, e molto a che fare con come è cambiato il mercato intorno:

• Rischio competenze. Linguaggi così non si insegnano all'università e non compaiono nelle offerte di lavoro. Assumere diventava più difficile anno dopo anno, e la dipendenza da un piccolo gruppo di senior continuava a crescere.
• Conoscenza concentrata. La logica di business critica e le ragioni dietro alle scelte vivevano nelle teste delle persone, non nella documentazione. L'onboarding di un nuovo sviluppatore si misurava in mesi, non in settimane.
• Un workflow manuale che frenava la velocità. Il team usava un IDE legacy, i file erano sparsi su più cartelle condivise, non c'era version control, non c'era CI/CD e i deploy erano completamente manuali. Ogni modifica portava con sé più rischio operativo del necessario.

Quello che colpiva era l'atteggiamento proattivo del management: invece di aspettare che queste pressioni diventassero un'emergenza, avevano deciso di muoversi mentre l'azienda era in salute e c'era margine per investire.

La sfida: un team già deluso dall'Al

Prima di rivolgersi a noi il team aveva provato gli assistenti Al per conto proprio. L'esperienza era stata frustrante: suggerimenti nel dialetto sbagliato, nomi di funzioni inventati, codice che non rispettava le loro convenzioni. La conclusione interna era comprensibile: "l'Al non è ancora pronta per il nostro mondo".

Quel precedente contava. Non stavamo entrando in una conversazione mossa dalla curiosità, ma in una con uno scetticismo del tutto giustificato. Qualunque pitch non supportato da prove concrete sul loro codice sarebbe stato bocciato sul nascere.

È una situazione tipica dei contesti legacy: pochi dati di training pubblici sul linguaggio, dialetti e interpreti custom su cui l'Al generica ricade su varianti più note generando codice che sembra corretto ma non gira, e una struttura di progetto non convenzionale che la maggior parte del tooling dà per scontata.

Sapevamo che Copilot appena installato avrebbe deluso, esattamente come era successo al team. Ma sapevamo anche, perché l'avevamo verificato in prima persona, che lo stesso strumento configurato a dovere è in grado di dare risultati radicalmente diversi. Il workshop esiste proprio per colmare quel divario con prove, non con promesse.

Come abbiamo affrontato il progetto

Abbiamo portato il nostro Agentic Development Workshop con GitHub Copilot nella loro azienda, adattandolo completamente al loro ambiente. Il funzionamento del workshop nel dettaglio è raccontato nell'articolo dedicato; qui ci concentriamo su cosa ha significato sul piano del business.

Una preparazione mirata, prima ancora di incontrare il team

Prima della sessione abbiamo fatto una call con sviluppatori e responsabili per capire il loro contesto: stack, strumenti, flussi di lavoro, dove si perdeva più tempo. Quel confronto ci ha permesso di orientare il workshop su casi concreti e rilevanti per loro, invece di portare una demo generica che su xbase++ non avrebbe retto. La credibilità dell'intervento si giocava nella prima ora, e un team già deluso dall'Al non concede facilmente una seconda possibilità.

Togliere l'attrito che bloccava il team

Portare il team su un editor moderno (Visual Studio Code) è stato di per sé un passo significativo: ha aperto la porta a un ecosistema di tooling più sano, ha reso possibili gli step successivi di modernizzazione e ha dato a Copilot una base su cui lavorare davvero.

Risolvere il problema delle allucinazioni alla radice

La prima esperienza con l'Al era fallita per un motivo semplice: lo strumento indovinava le funzioni invece di cercarle. Lo abbiamo affrontato dando a Copilot modi deterministici per recuperare le informazioni giuste, sia sulla libreria standard del linguaggio sia sul codice proprietario del team. In termini di impatto concreto, i suggerimenti hanno iniziato ad arrivare nel dialetto corretto, rispettando le convenzioni del team, già dal primo giorno di workshop.

Il momento in cui è cambiata la prospettiva

La parte più convincente è stata una sessione di mob programming su una piccola feature reale del loro backlog, non un esercizio costruito ad hoc. Con gli sviluppatori a guidare sulle convenzioni e le pratiche custom del loro progetto, e Copilot a gestire navigazione tra file e generazione di codice, abbiamo implementato la feature rispettando esattamente il modo in cui quel team lavora.

Vedere lo strumento generare codice valido e coerente con il contesto, su un problema reale di produzione, davanti alle persone che quel sistema lo conoscono meglio di chiunque, è stato il momento in cui lo scetticismo ha lasciato il posto a una conclusione molto più operativa: "questo possiamo usarlo ogni giorno, perché conosce abbastanza del nostro ambiente da essere affidabile".

Risultati di business

Più velocità di delivery, con lo stesso team

Con la configurazione giusta, il team scrive e naviga il codice molto più velocemente, con un crollo degli errori che in passato avevano reso i suggerimenti Al inaffidabili. Le stesse persone, sullo stesso prodotto, chiudono più lavoro per sprint senza assumersi alcun rischio aggiuntivo.

Meno dipendenza dalle persone chiave

I nuovi arrivati possono chiedere a Copilot di spiegare le funzioni, seguire la logica nel codebase e far emergere il ragionamento dietro alle implementazioni esistenti. Per un'azienda in cui la conoscenza critica era concentrata in poche figure senior, questa è una riduzione concreta del rischio: l'onboarding si accorcia, le opzioni di hiring si ampliano e l'impatto di una singola uscita diventa molto meno pesante.

Conoscenza tribale che diventa un asset documentato

Il team usa Copilot per generare spiegazioni e commenti inline su porzioni di codice rimaste opache per anni. Nel tempo, questo trasforma una passività nascosta, la logica di business non documentata, in un asset trasferibile che incide direttamente sulla sicurezza con cui si può continuare a far evolvere il prodotto.

Un team che vuole continuare

Forse l'esito più strategico è culturale. Un team partito da uno scetticismo legittimo è arrivato a fine intervento spingendo attivamente per i passi successivi della modernizzazione. È uno slancio che non si costruisce artificialmente, e vale oro per un management che vuole vedere il cambiamento nascere dall'interno, non calato dall'alto.

Cosa sta facendo adesso l'azienda

Il workshop è stato l'innesco, non il traguardo. Con un team ora a suo agio con il nuovo tooling, l'azienda sta portando avanti una roadmap di modernizzazione più ampia:

• Roll-out di VS Code e Copilot sull'intera organizzazione di sviluppo.
• Costruzione di nuove skill di dominio per estendere la comprensione che Copilot ha del loro business.
• Esplorazione di end-to-end testing automatizzato tramite un'integrazione MCP costruita su misura.
• Test automatici sui code path critici, primo passo concreto verso una pipeline CI/CD.

Il workshop ha messo in moto questo ciclo senza imporre un rewrite distruttivo di un prodotto che continua a fatturare.

Cosa si porta a casa il management

Se il vostro business si regge su un sistema maturo e profittevole, costruito su una tecnologia che il mercato ha lasciato indietro, non siete obbligati a scegliere tra non fare nulla o riscrivere tutto. C'è una terza strada: modernizzare il modo in cui il vostro team costruisce e mantiene il prodotto, prima ancora di toccare il prodotto stesso.

È un percorso che protegge la logica di business che vi rende competitivi, riduce l'esposizione al rischio competenze e alla dipendenza dalle persone chiave, e dà alla vostra organizzazione di sviluppo la velocità necessaria per stare al passo, mantenendo intanto in produzione, e ben saldo, il sistema che paga gli stipendi.

È esattamente ciò che il nostro Agentic Development Workshop è progettato per fare: un intervento mirato, basato su prove concrete, che trasforma lo scetticismo in adozione e dà al vostro team un punto di partenza in giorni, non in trimestri.

Se vi sembra una conversazione che vale la pena fare, scriveteci o contattateci a it-tech@claranet.com. Niente moduli da compilare e poi aspettare: preferiamo parlare direttamente con chi ha il problema, capire la situazione e decidere insieme se un workshop su misura è la mossa giusta.