← CATALYST/Il metodo
METODO / 01
Il metodo

Come CATALYST modernizza un'applicazione, e come verifica di non aver rotto nulla

Questa pagina spiega che cosa fa CATALYST, in quale ordine, con quali controlli e perché è costruito così. È scritta per chi deve valutarlo — architetti, responsabili IT, auditor — ma si legge anche senza un passato da sviluppatore. Aggiornata a ottobre 2026.

Uno strumento di migrazione con i controlli dentro.

CATALYST è un insieme di agenti, competenze e controlli costruito su Claude Code di Anthropic. Si installa nell'infrastruttura del cliente come immagine chiusa e lo usa il team del cliente. Porta un'applicazione legacy su tecnologie attuali e, mentre lo fa, produce le evidenze che il nuovo sistema si comporta come il vecchio.

Applicazione legacy
Software costruito anni o decenni fa, spesso con tecnologie che non si sviluppano più, che regge ancora processi importanti.
Migrazione
Riscrivere un'applicazione su tecnologie attuali senza cambiarne il comportamento: stessi calcoli, stessi controlli, stessi risultati.
Parità
Il fatto che il nuovo sistema si comporti come il vecchio. CATALYST la verifica e ne lascia le evidenze; non è una prova matematica.

Prima di iniziare: il portafoglio, non la singola app.

Decine di applicazioni non sono decine di problemi indipendenti. Una libreria condivisa da trenta applicazioni si decide una volta, non trenta. Prima di migrare, CATALYST legge l'intero parco applicativo: individua librerie condivise, componenti nativi e dipendenze fra applicazioni, e ne ricava un ordine di lavoro consigliato, a ondate, in cui un'applicazione viene dopo quelle da cui dipende.

Le tre fasi, e il controllo che chiude ciascuna.

Ogni applicazione passa da tre fasi. Fra una fase e l'altra un programma controlla il risultato e decide se si può proseguire. Si può scavalcare un controllo solo con una motivazione scritta, che resta registrata con il suo autore.

Fase 01

Analizza

  • Un agente di analisi legge il codice e censisce cinque categorie di elementi: elementi dell'interfaccia, funzioni pubbliche, gestori di eventi, regole di business, dipendenze condivise. Ogni elemento ha un identificativo e il riferimento al file e alla riga da cui viene.
  • Scrive la scheda dell'applicazione, con tre parti che contano: le domande che richiedono un dato o una decisione del cliente; le decisioni prese seguendo le buone pratiche, ciascuna motivata; le migliorie consigliate, da fare dopo la migrazione.
  • Classifica la distanza fra partenza e arrivo, da B1 (stesso linguaggio, versioni nuove) a B4 (cambio di paradigma, per esempio da COBOL a Java). Più è grande, più la verifica ragiona per funzionalità invece che elemento per elemento.

Si chiude quando Il contratto della fase è valido e ogni categoria dell'inventario è popolata.

Fase 02

Migra

  • Un agente di migrazione, guidato dalle regole e dagli idiomi dello stack di destinazione, riscrive l'applicazione come la scriverebbe oggi uno sviluppatore esperto, non riga per riga.
  • Per ogni elemento censito registra lo stato: migrato, con il punto di destinazione; omesso con decisione, con la motivazione; codice morto, dimostrato tale dal sorgente.
  • Nelle applicazioni più grandi controlla la fedeltà a intervalli regolari, senza aspettare la fine. Lo schema del database non cambia senza autorizzazione, e le funzioni disattivate restano disattivate.

Si chiude quando Codice migrato e registro di copertura sono presenti, e ogni elemento ha uno dei tre stati ammessi.

Fase 03

Verifica

  • Prima i controlli deterministici: compilazione, ricerca di schemi d'errore noti, confronto dei formati.
  • Poi un agente di verifica, configurato con soli strumenti di lettura, confronta vecchio e nuovo elemento per elemento e cerca le differenze: regole spostate, semantica alterata, casi limite persi, aggiunte non giustificate. Propone i verdetti; a registrarli è il processo principale.
  • Nel programma di riferimento, la versione nuova viene anche avviata e ogni schermata confrontata con un riferimento versionato. Il confronto sui dati reali in pre-produzione lo esegue il team del cliente; CATALYST ne raccoglie le evidenze.

Si chiude quando Copertura almeno al 90%, nessun errore senza motivazione, e due o più avvisi sullo stesso tema contano come un errore. Poi il report di consegna e la firma del responsabile di business.

Chi fa che cosa — e che cosa non fa.

Gli agenti AI usano i modelli Claude di Anthropic: oggi Opus 5.5 per analisi, migrazione e verifica, Sonnet 5.5 per la cura della conoscenza. Accanto a loro lavorano programmi deterministici e persone.

I ruoli in CATALYST: che cosa fanno e che cosa non fanno
ChiChe cosa faChe cosa non fa
Agente di analisiLegge il codice legacy, censisce gli elementi, scrive la scheda dell'applicazione.Non modifica il codice legacy: un controllo automatico blocca gli strumenti di modifica su quella cartella.
Agente di migrazioneRiscrive l'applicazione e tiene il registro di copertura.Non scrive fuori dai percorsi autorizzati, e non inizia se l'analisi non ha superato il suo controllo.
Agente di verificaConfronta vecchio e nuovo e propone un verdetto per ogni elemento.Non corregge ciò che giudica: è configurato con soli strumenti di lettura.
Curatore della conoscenzaAlla fine di ogni fase propone nuove regole a partire da ciò che è emerso.Non cambia il metodo da solo: le proposte entrano solo dopo l'approvazione di una persona.
Programmi deterministiciControlli di fine fase, controlli intermedi, ordine di lavoro fra applicazioni: contano e confrontano, con esito ripetibile.Non interpretano: dove serve giudizio, il lavoro passa a un agente.
PersoneRispondono alle domande aperte, approvano le eccezioni ai controlli, firmano il rilascio.Non sono sostituite: senza la firma del responsabile di business l'applicazione nuova non va in produzione.

Dieci principi per decidere quando il caso non è previsto.

  1. Il codice che gira oggi è la specifica.

    Documentazione e conversazioni sono utili, ma l'ultima parola sul comportamento ce l'ha il sorgente in produzione.

  2. Prima la parità, poi le migliorie.

    La migrazione conserva il comportamento attivo, senza aggiungere né togliere funzioni. Le migliorie si annotano nella scheda e si fanno dopo.

  3. Ogni elemento ha uno stato.

    Migrato, omesso con decisione o codice morto dimostrato: nessun elemento resta fuori, nessuno sta in due stati.

  4. Programmi dove si può, AI dove serve.

    Se un controllo si fa contando e confrontando, lo fa un programma con esito ripetibile; l'AI interviene dove serve interpretare.

  5. Chi verifica non è chi scrive.

    Ogni agente ha strumenti limitati al proprio ruolo: chi verifica legge e segnala, chi scrive lavora solo nei percorsi autorizzati.

  6. Ogni vincolo importante, applicato più volte.

    Configurazione degli agenti, controlli automatici sugli strumenti, programmi di verifica: se uno cede, gli altri restano.

  7. Un controllo che non ha valutato nulla non è passato.

    Ogni controllo distingue tre esiti: a posto, problema, non verificato. Il terzo non diventa mai un via libera.

  8. Un registro per i controlli, un documento per le persone.

    Ogni fase produce un contratto strutturato, che i controlli leggono, e un documento leggibile, che lo cita. Lo stato non si ricava mai dalla prosa.

  9. La distanza conta.

    Passare da VB.NET a C# non è come passare da COBOL a Java: la distanza si dichiara all'inizio e calibra le attese, non i controlli.

  10. Ogni applicazione insegna qualcosa alla successiva.

    Le lezioni emerse diventano regole del metodo, ma solo dopo l'approvazione di una persona.

Come si aggiunge un linguaggio senza riscrivere il metodo.

CATALYST separa ciò che vale per ogni migrazione da ciò che dipende dal linguaggio e da ciò che appartiene al singolo cliente. Oggi è in produzione su applicazioni .NET, da VB.NET e .NET Framework a .NET 10 / C# 14. COBOL, PL/I, J2EE, SAP ABAP e PHP sono in roadmap.

  1. Il metodo

    Fasi, contratti, controlli, agenti: uguali per ogni linguaggio. È la parte che non cambia.

  2. L'adattatore dello stack

    Le regole, gli idiomi e gli schemi di migrazione di un linguaggio. Un linguaggio nuovo si aggiunge scrivendone uno, senza toccare il metodo.

  3. La conoscenza del progetto

    Il contesto del cliente, le decisioni prese, lo stato del programma. Cresce con il lavoro e resta al cliente.

Dove gira, e che cosa ne esce.

CATALYST è un'immagine chiusa che il cliente esegue nella propria infrastruttura: un server in sede o una macchina nel suo cloud (AWS, Google Cloud, Azure). Non contatta alcun servizio di KVA: il codice non passa dai nostri server. L'unico servizio esterno che lo elabora è il modello di AI, con la chiave e il contratto del cliente; si può raggiungere anche attraverso Amazon Bedrock, Google Vertex AI o Microsoft Foundry, configurando le variabili standard di Claude Code.

I controlli di sicurezza nel dettaglio →

Che cosa CATALYST oggi non fa.

Dirlo prima è ciò che rende credibile il resto.

  • Non genera test automatici: è in roadmap. Oggi la parità non richiede una suite di test preesistente, perché il riferimento è il comportamento del codice legacy.
  • Non esegue da solo il confronto in esecuzione parallela fra vecchio e nuovo sui dati reali: lo fa il team del cliente in pre-produzione, e l'automazione è in roadmap.
  • Non produce una prova matematica di equivalenza: produce una verifica ripetibile, con le sue evidenze.
  • Non prepara né invia comunicazioni alle autorità: fornisce le evidenze a supporto; valutazione e invio restano del cliente.

Un'ora su codice reale →← Torna alla home