Come prepararsi per i progetti di modernizzazione del codice basati sull'IA

Nella serie Note dal campo, i team di sviluppo di Anthropic condividono le best practice ispirate a implementazioni reali dei clienti. In questo articolo, condividiamo la nostra esperienza nella gestione di progetti di modernizzazione del codice di grandi dimensioni.

Le modernizzazioni del codice, una volta previste come interventi pluriennali e intermedi ora possono essere completate in mesi (o settimane), ma il lavoro organizzativo su entrambi i lati spesso rimane lo stesso.

Ad esempio, ogni modifica a un sistema bancario critico deve passare attraverso la gestione del cambiamento, la revisione e l'approvazione. È un processo solido perché gli enti di regolamentazione, i revisori e l'azienda lo richiedono.

Questi processi sono ciò che rende i sistemi critici affidabili e sono stati creati partendo dal presupposto che un essere umano scriva ogni modifica e che un essere umano esamini ogni differ. Una volta che gli agenti accelerano la stesura delle modifiche, il collo di bottiglia passa dalla produzione delle modifiche alla mobilitazione dell'organizzazione per adattarle.

Questo articolo illustra le attività che le aziende devono svolgere prima di avviare la modernizzazione: definire cosa significa fatto, quali prove deve portare una modifica, come le modifiche certificate raggiungeranno la produzione e cosa deve essere pianificato per avviare la modernizzazione.

Suddividiamo questo processo in sei passaggi:

1. Definisci l'obiettivo: lo stack tecnologico e il comportamento che il codice modernizzato deve avere.
2. Crea il certificato: le condizioni che le modifiche devono soddisfare per essere considerate corrette nello stato target.
3. Imposta la politica di promozione: il percorso attraverso il quale le modifiche certificate vengono messe in produzione al ritmo di produzione.
4. Metti in atto i prerequisiti: ambiente, CI/CD, capacità di revisione e approvazioni.
5. Crea e perfeziona il flusso di lavoro agentico: il flusso di lavoro dinamico personalizzato di Claude Code che distribuisce la modernizzazione su molti flussi di lavoro di subagenti paralleli più piccoli che producono le modifiche. Questo è costruito intorno all'obiettivo, al certificato e alla politica di promozione.
6. Esegui la modernizzazione: verifica il flusso di lavoro per terminare su una piccola partizione della codebase, quindi scala.

Step 1: definisci l'obiettivo

L'obiettivo è lo stato finale della modernizzazione. Lo stato finale desiderato determina quale dei tre tipi di modernizzazione stai eseguendo, descritti in dettaglio nella tabella seguente.

Determina il tipo di modernizzazione

Determinare quale tipo di modernizzazione fare è spesso un argomento di discussione all'interno di un'organizzazione. Nella nostra esperienza, le persone più vicine alla produzione vogliono lo stack sostituito con un comportamento costante per contenere i rischi (trasforma la modernizzazione). Dall'altra parte ci sono spesso i team di sviluppo che hanno vissuto con la codebase e che desiderano la modernizzazione per estinguere il debito tecnologico, oltre ad altri stakeholder aziendali che desiderano cogliere l'opportunità per nominare nuovi requisiti (reinventare la modernizzazione).

Entrambe le posizioni sono ragionevoli, ma se la domanda viene lasciata irrisolta, riaffiorerà in seguito come un argomento sul fatto che una determinata modifica sia "corretta". Creare un consenso sulla strada da seguire aggiunge ostacoli iniziali, ma semplifica il progetto nel suo complesso.

Mappa la codebase e crea la specifica comportamentale

Comprendere il sistema attuale è spesso un buon primo passo per definire l'obiettivo. Estrarre cosa fa effettivamente il vecchio codice e creare un inventario del comportamento attuale rende facile decidere se le parti devono essere modificate o eliminate, e quindi se la modernizzazione è una trasformazione o una riprogettazione. Questo spesso rivela logiche di business sconosciute e casi di rilevanza.

Claude può fare gran parte di questa scoperta mappando le dipendenze e documentando i flussi di lavoro che nessuno ricorda di aver creato. La funzionalità di valutazione, mappatura ed estrazione delle regole del plugin per la modernizzazione del codice estrae le regole aziendali con citazioni delle fonti che i team di sviluppo possono quindi esaminare.

Tuttavia, la scoperta di Claude potrebbe non essere sufficiente a comprendere il comportamento di un sistema legacy. Le interviste con utenti aziendali e sviluppatori e la documentazione interna possono colmare queste lacune. La raccolta del contesto può richiedere un po' di tempo all'inizio, ma la qualità di quel contesto influisce su ogni decisione che il flusso di lavoro prende in seguito.

Per un reimagine, definire l'obiettivo richiede un lavoro aggiuntivo: occorre scrivere una specifica comportamentale dettagliata e concordare con i gruppi di utenti.

Stabilisci la giustificazione e gli obiettivi del progetto

Oltre a definire l'obiettivo, l'organizzazione dovrebbe valutare perché vale la pena intraprendere la modernizzazione. Modernizzare i sistemi legacy può ridurre i costi operativi e di manutenzione correnti, tuttavia nella nostra esperienza, la riduzione dei costi non è stata l'obiettivo principale della maggior parte dei progetti di modernizzazione.

Ad esempio, un sistema con vulnerabilità non ancora risolte può significare una violazione informatica o un'interruzione di servizio abbastanza grave da mettere a rischio l'intera attività. Un runtime non supportato o un numero sempre più ridotto di ingegneri che conoscono il sistema aggrava il rischio.

Gli strumenti di codifica agentici come Claude Code hanno ridotto i tempi di modernizzazione, ma i budget sono ancora difficili da stimare e ciò porta all'inerzia. Abbiamo reso pubblici i costi di alcune delle nostre modernizzazioni su larga scala e di altre. Questi possono servire come base di riferimento approssimativa, mentre abbiamo fornito ulteriori indicazioni sulle proiezioni di budget in fondo a questa guida.

La sfida principale nell'avviare questi progetti è di solito ottenere il consenso interno e l'impegno dei team che possiedono il sistema e dei team che ne dipendono. Sviluppare il business case e fissare gli obiettivi del progetto, spesso a livello di leadership, semplifica questa parte del processo. Questo aiuta anche a integrare i compromessi nella politica di certificazione e promozione che ne conseguono. Quando gli stakeholder non sono d'accordo su quanto di rischio può comportare un cambiamento, il rischio di non modernizzazione fa da contrappeso.

Step 2: definisci il certificato

Il certificato è l'insieme di condizioni o test che ogni modifica di modernizzazione deve soddisfare. Scegli le condizioni che forniscono le prove cumulative più solide che la modifica è corretta rispetto all'obiettivo.

Ogni condizione deve essere verificabile senza la presenza di un essere umano, in modo che il flusso di lavoro agentico possa iterare su una modifica fino a quando non soddisfa il certificato oppure segnalarla per la revisione umana se non è possibile.

Il contenuto del certificato dipende dall'obiettivo, ma di solito verrà utilizzato da questo elenco:

• La suite di test originale viene superata
• I test scritti da Claude durante la modernizzazione superano tutti i test
• La copertura dei test raggiunge una soglia concordata
• I test standardizzati delle prestazioni non superano i limiti concordati
• Le revisioni indipendenti delle contraddizioni da parte di Claude, ciascuna in una nuova finestra di contesto, non individuano problemi di blocco
• Per le interfacce utente, l'utilizzo del computer basato su Claude non rileva regressioni
• La versione attuale e quella prevista producono lo stesso risultato dallo stesso input, che può essere live, registrato o generato da Claude
• Ha persistito nello stato attuale e nel flusso di andata e ritorno dei formati tra la versione attuale e quella target
• Le modifiche vengono eseguite in staging per un periodo concordato senza regressioni nei tassi di errore, nella latenza o negli avvisi
• L'analisi statica e le scansioni di sicurezza non mostrano nuovi risultati
• Per gli obiettivi compilati, la compilazione è pulita e i controlli di tipo digitale sono approvati

La loro competenza influisce su ciò che il certificato misura e il loro coinvolgimento precoce è ciò che garantisce il loro buy-in quando le modifiche vengono revisionate. Un buon modo per verificare il certificato finale è se il cliente sarebbe disposto a combinare solo le prove contenute nel certificato. Se i dipendenti ritengono che abbia qualcosa in più, la politica di promozione descritta nel Passaggio 3 può essere più leggera.

Ciò su cui il certificato verifica e come dipende dal tipo di modernizzazione.

• Per una modernizzazione di rilievo, la parità è rispetto alla codebase originale e la suite di test originale può essere il fulcro del certificato.
• Per una modernizzazione di trasformazione, la parità è anche rispetto alla codebase originale, ma la suite di test originale raramente viene eseguita sul nuovo stack. Il riplay del traffico di produzione, i test differenziali tra vecchio e nuovo e una distribuzione prod-parallela fanno invece gran parte del lavoro.
• Per una modernizzazione di reimagine, il certificato è ancorato alla specifica comportamentale. Questo è il caso più difficile. Una specifica è meno oggettiva di un sistema esistente su cui contestare, quindi è necessario un grado maggiore di giudizio del modello, che può portare a risultati più variabili. In questo caso, il certificato si basa su test scritti partendo dalle specifiche tecniche, revisioni contraddittorie indipendenti di Claude che verificano ogni modifica rispetto al punto finale e controlli differenziali dove il nuovo sistema mantiene il comportamento del vecchio. Aspettatevi di rivedere il certificato man mano che le specifiche vengono chiarite: le lacune nelle specifiche vengono visualizzate qui per prime.

I sistemi più vecchi hanno spesso una copertura dei test scarsa, test imprecisi e scarsa telemetria. Parte della definizione del certificato è l'identificazione di queste lacune. Se risulta difficile dimostrare un certificato valido, una delle cose più utili da fare in questa fase è utilizzare Claude per costruire le prove mancanti, che si tratti di creare una configurazione prod-parallel, creare un replay harness o scrivere altri test.

Step 3: Imposta la politica di promozione

Gli agenti produrranno le modifiche molto più velocemente di quanto qualsiasi team umano possa esaminarle differenzialmente. La politica di promozione prevede un percorso di revisione su più livelli, scritto e concordato in anticipo, che definisce il livello di revisione umana per una modifica, in modo che la modernizzazione possa essere completata entro una tempistica accettabile.

Accetta il certificato, lavora su questa fase con i revisori e inseriscila nel processo di gestione del cambiamento esistente nella tua organizzazione, ovunque possibile. I dettagli varieranno a seconda dell'organizzazione e dei rischi che deve affrontare, ma alcune regole valgono ovunque:

• Classifica le modifiche in base all'entità dell'impatto e alla fiducia degli agenti. Utilizza la classificazione dei rischi o delle modifiche della tua organizzazione, se ne dispone una. Mantieni la revisione umana completa dei percorsi critici.
• Risolvi alla fonte i segnali ricorrenti. Raggruppa e analizza le modifiche segnalate nel tempo. Quando lo stesso tipo di segnalazione si ripete ripetutamente, correggi la causa nel flusso di lavoro dell'agente o nel certificato, anziché esaminare ciascuno di essi.
• Progetta il formato di output con i revisori. Concorda quali informazioni e formati rendono la revisione più rapida e quali segnali danno più sicurezza rispetto ad altri. Chiedi di esaminare i risultati dei campioni iniziali nel Passaggio 5.
• Alloca in modo efficace il tempo delle PMI. Le PMI non leggeranno ogni diff finale, ma il loro giudizio è ancora un input scarso. Rendi semplice accesso alle modifiche nei livelli a più alto rischio e alle decisioni degli agenti segnalate all'interno di ciascun livello, senza dover esaminare grandi differenze. Un piccolo numero di ore di lavoro degli esperti copre poi le modifiche che presentano i rischi maggiori.

Molte di queste regole anticipano le ore di lavoro delle PMI coinvolgendole nelle prime fasi del progetto. Il loro feedback perfeziona il certificato e il flusso di lavoro agentiche prima di dare inizio alla modernizzazione completa.

La loro approvazione sui campioni diventa anche un'ulteriore giustificazione per un percorso di revisione più leggero dove c'è un alto livello di affidabilità. Questo è l'inversione del modello tradizionale non agentico, in cui la revisione avviene alla fine.

La politica di promozione dovrebbe inoltre riflettere sulle aree in cui la modernizzazione si colloca nello spettro tra velocità e profondità delle revisioni. Una modernizzazione che sta scadendo entro una scadenza rigida, come la perdita del supporto al runtime, richiede una politica più rapida con una revisione umana più leggera e un accordo esplicito per accettare più rischi per ogni modifica.

Una modernizzazione su una tempistica più lunga può consentire una revisione umana più approfondita e un cutover più lento. Gli stakeholder decideranno su diversi punti di questo spettro in base alla loro propensione al rischio e ai vincoli esistenti, quindi vale la pena verificare prima di iniziare il lavoro.

In un ambiente regolamentato, scegliere un percorso di revisione umana più leggero per qualsiasi modifica può causare un vero disagio. I singoli approvatori esitano ad approvare perché comporta il rischio di un cambiamento negativo, mentre la leadership comporta il rischio maggiore di un sistema obsoleto.

In base alla nostra esperienza, è meglio che la direttiva per la politica di promozione venga dal vertice dell'organizzazione. È inoltre preferibile concordare in anticipo la responsabilità di un bug che raggiunge la produzione sia condivisa, anziché attribuirla a chi ha approvato la modifica.

Step 4: Metti in atto i prerequisiti

Gran parte di questa fase viene eseguita da team al di fuori della modernizzazione: piattaforma o infrastruttura per l'host, QA o release engineering per la capacità di test, sicurezza e conformità per le approvazioni. Ciascuno di questi team ha spesso un proprio backlog o un proprio processo di approvazione, quindi apri le conversazioni in anticipo, non appena hai identificato i requisiti, spesso mentre i passaggi da 1 a 3 sono ancora in corso.

Ambiente

• Un host remoto dedicato per l'esecuzione del flusso di lavoro con la codebase e altre fonti pertinenti raggiungibili da Claude
• Capacità di test come richiesto dal certificato
• Tutto ciò che rafforza il certificato: telemetria di produzione, una configurazione prod-parallela o dati di produzione per il replay

Codebase e CI/CD

• Una mappa delle dipendenze della codebase, basata sui log di build e compilazione, sull'analisi delle importazioni o sulle tracce di runtime. Nota: il comando mappa del plugin è un buon punto di partenza, ma a seconda delle dimensioni e dell'età della codebase, potrebbe essere necessario svolgere un lavoro iniziale più approfondito
• Trattamento pianificato di eventuali dipendenze o pacchetti, come parte della definizione degli obiettivi
• Un controllo di compatibilità pronto da aggiungere a CI/CD, se necessario
• Una politica di blocco del codice concordata, se stai aggiornando in loco
• Un piano di comunicazione per sviluppatori attivi, che include eventuali blocchi di codice e nuovi requisiti di compatibilità

Team e revisione

• Accordo con altri team che dipendono dalla codebase per le modalità di partecipazione, ad esempio per firmare il certificato o effettuare le revisioni in base alla politica di promozione, con tempo riservato per i revisori

Sicurezza e conformità

• Un modello di percorso di accesso per Claude Code approvato per il codice sorgente
• Accesso con privilegi minimi per il flusso di lavoro agentico: scrivi solo ai rami di modernizzazione e senza le credenziali di produzione
• Segreti e PII cancellati o mascherati dal ramo della modernizzazione
• Ogni modifica tracciabile e le PR collegate a una trascrizione dell'agente e a prove di certificazione
• Controlli di licenza e vulnerabilità sulle nuove dipendenze

Step 5: Crea e perfeziona il flusso di lavoro agentico

Usa Claude Code per sviluppare un flusso di lavoro dinamico personalizzato per modernizzare la codebase.

Ti consigliamo di iniziare con il plugin per la modernizzazione del codice e di mettere tutto ciò di cui il flusso di lavoro potrebbe aver bisogno sul file system o su MCP, dove Claude può raggiungerlo. Ciò include l'obiettivo, il certificato, la politica di promozione, la codebase, la documentazione e qualsiasi fonte di dati o strumento richiesto per il certificato. Puoi fornire questo articolo a Claude come contesto. Questa è la knowledge base centrale per il progetto.

Una volta implementato questo, creare il flusso di lavoro per la modernizzazione è diventata la parte facile. Chiedi alle PMI di esaminare il lavoro di Claude, se necessario, includendo eventuali competenze specifiche della codebase o regole estratte, prima che qualsiasi cosa a valle si basi su di esso.

Perfeziona ciò che hai sviluppato applicandolo a piccole parti della codebase, con le PMI che esaminano le modifiche prodotte, il processo degli agenti e le prove che il certificato è stato soddisfatto.

Step 6: Esegui la modernizzazione

Innanzitutto, completa la modernizzazione per completare una piccola parte della codebase, comprese la revisione e l'approvazione delle modifiche tramite la politica di promozione. Correggi tutto ciò che non funziona mentre è ancora economico, ripeti il processo finché non sei sicuro di averlo fatto, quindi scala fino all'intera codebase.

Mentre le modernizzazioni di trasformazione e riprogettazione implicano la creazione dell'obiettivo accanto al sistema esistente e la revisione una volta completata, un uplift ha una seconda opzione: modernizzare in loco sulla codebase mentre lo sviluppo prosegue.

Questa è la scelta abituale quando il sistema non può essere disponibile o quando la codebase cambia così rapidamente che è difficile mantenere aggiornata una copia separata e modernizzata. Ciò che abbiamo visto funzionare in questo caso è suddividere la codebase in partizioni logiche partendo dalle pagine verso l'interno; congelare e modernizzare una partizione alla volta; e applicare CI/CD in modo che i nuovi commit non possano annullare una partizione una volta modernizzata.

Una nota sul costo

Ci viene spesso chiesto quanto costerà in token una modernizzazione come questa. Ogni sforzo di modernizzazione è diverso, ma i principali fattori di costo includono:

• Quanto della codebase deve essere letta rispetto a quanto modificata;
• Quanto è coinvolto il certificato (la verifica, non la scrittura della modifica, è di solito la componente più importante in un ambiente regolamentato);
• Quanto richiede la stesura di nuovi test e la correzione dei test per il certificato; e
• Quanto lavoro di riconciliazione deriva dal fatto che altri team si uniscono intorno a te mentre la procedura è in corso.

Le misurazioni del progetto pilota mostrano inoltre dove ottimizzare il flusso di lavoro agentico in termini di costi. Individua le parti del flusso di lavoro che hanno consumato la maggior parte dei token e valuta come renderle più efficienti. Sposta i segnali di verifica più complessi in termini di calcolo e rinvia i sistemi più economici in modo che vengano eseguiti solo una volta che sono stati superati i controlli più semplici.

Considera l'utilizzo di modelli come Sonnet che bilanciano costi e capacità per le attività meccaniche e ad alto volume che il certificato controlla completamente Mantieni modelli più intelligenti per le trasformazioni complesse e le revisioni contraddittorie che ne verificano la correttezza.

Puoi anche passare a un modello più costoso quando uno meno costoso non riesce a soddisfare la certificazione, ma analizza attentamente i tassi di riprova durante la fase pilota, poiché diversi tentativi economici possono costare più di uno costoso. Se consenti a Claude di accedere sia al flusso di lavoro che ai dati del progetto pilota, potrà svolgere gran parte di queste analisi insieme a te.

Oltre la modernizzazione

La codebase modernizzata è un solo output. Gli altri sono il flusso di lavoro che ha prodotto la modifica, un certificato scritto che attesta cosa è considerata corretta, una politica di promozione che il tuo processo di gestione delle modifiche ha già accettato e una traccia delle prove per ogni modifica apportata. Codifica il playbook come una risorsa riutilizzabile, in modo che il modello sia già pronto per il prossimo aggiornamento o riscrittura.

I nostri ingegneri di Forward Deployment lavorano insieme ai clienti su queste fasi dei sistemi più critici. Se stai preparando una modernizzazione, parla con il nostro team.

Risorse aggiuntive

• Il plugin pubblico per codemod per Claude Code
• Il playbook AI-Native SDLC
• Playbook per la modernizzazione del codice
• Modernizzare COBOL con l'IA: come abbattere la barriera dei costi