Strategia brownfield
Come trasferire un codebase esistente allo sviluppo AI-native: quando risanare in loco, quando fare lo strangler-fig, quando ricostruire, quando isolare, e la metodologia che rende ciascuno praticabile.
Il tuo codebase è davvero brownfield?
Le quattro modalità di questa pagina si applicano ai codebase brownfield: codice esistente con decisioni accumulate, utenti in produzione e un team che ci lavora dentro. Prima di scegliere una modalità, verifica lo stato del codebase. In pratica ne emergono tre:
| Stato | Cosa significa | Cosa fare |
|---|---|---|
| Greenfield (in sviluppo, pre-GA) | Nuovo codebase, non ancora in produzione, o in produzione ma abbastanza giovane che tutto il codice è ancora attivamente progettato. I punteggi di maturità bassi qui sono decisioni di programmazione, non debito. | Continua lo sviluppo. Chiudi i gap di maturità nei tempi della roadmap. Esegui nuovamente la valutazione della maturità alla GA e tratta i gap non chiusi come brownfield allora. |
| Brownfield (produzione, accumulato) | Il codice esiste, gira in produzione, ha utenti reali, porta anni di decisioni. I gap di maturità sono debito. | Scegli una modalità usando le quattro qui sotto. |
| Ibrido | Un nuovo servizio pronto per il Livello 5 all'interno di un'organizzazione i cui altri sistemi sono brownfield. Il nuovo servizio è greenfield; il confine di integrazione legacy è brownfield. | Valuta il nuovo servizio come greenfield. Per ogni confine legacy, scegli una modalità separatamente. La versione più comune: una nuova app AI-native che legge o scrive dati attraverso un'API legacy. |
Le quattro modalità
Ogni modalità è un percorso diverso verso il Livello 5. La domanda non è "quale modalità ha la capacità il team": è una decisione di allocazione delle risorse a valle. La domanda è "quale modalità è il percorso più breve verso il Livello 5 per questo codebase, sulla base delle prove." Dimensione del team, priorità strategiche e costo opportunità sono input che un umano pesa dopo aver letto la raccomandazione; non sono input alla raccomandazione stessa.
| Modalità | Cosa significa "Percorso verso il Livello 5" |
|---|---|
| Risanare in loco | Il Livello 5 avviene in questo codebase tramite costruzione del harness a fasi. |
| Strangler-fig | Il Livello 5 avviene gradualmente: i nuovi pezzi sono costruiti pronti per il Livello 5 mentre i vecchi vanno in pensione. |
| Ricostruzione completa | Il Livello 5 avviene in una nuova versione di questo codebase; la versione vecchia va in pensione al momento del cutover. |
| Isolare e aggirare | Il Livello 5 non avviene in questo codebase. Avviene in nuovi codebase pronti per il Livello 5 accanto a esso; questo rimane congelato. |
Modalità 1: Risanare in loco
Mantieni il codice esistente. Investi nel harness: test, tipi, convenzioni, intento documentato. Usa l'IA per accelerare il risanamento stesso tramite la metodologia Ricerca-Revisione-Ricostruzione qui sotto.
Quando è giusto: l'architettura è fondamentalmente solida (il problema è il harness, non la struttura); il team ha expertise di dominio legata al codebase attuale; la continuità aziendale non può tollerare sistemi paralleli.
Il rischio: si risana il harness e il codice rimane fondamentalmente al Livello 3 perché la struttura ti combatte. Hai speso sei mesi e non riesci ancora a raggiungere il Grado 5.
Modalità 2: Migrazione strangler-fig
Costruisci nuove funzionalità pronte per il Livello 5 accanto al sistema vecchio. Instrada il traffico attraverso una facade. Elimina i pezzi del sistema vecchio uno per uno man mano che i nuovi si dimostrano affidabili. Lo Strangler Fig Pattern di Martin Fowler è il riferimento canonico.
Quando è giusto: il sistema esistente ha seami puliti per l'estrazione; la continuità aziendale conta; il tempo di ricostruzione dell'intero sistema supererebbe la tolleranza aziendale.
Il rischio: l'identificazione dei seami è difficile. Se i seami non sono puliti, finisci con due sistemi accoppiati invece di uno: il doppio della complessità, nessun beneficio.
Modalità 3: Ricostruzione completa
Ricomincia da zero con un codebase pronto per il Livello 5. Esegui i due sistemi in parallelo, migra i dati, fai il cutover quando il nuovo sistema si dimostra equivalente o migliore.
Quando è giusto: la struttura esistente impedisce attivamente il lavoro che devi fare; il costo del risanamento continuato supera il costo della ricostruzione; l'economia di ricostruzione assistita dall'IA rende la ricostruzione praticabile in una finestra temporale che prima non era fattibile; il dominio è ben compreso (si sta sostituendo il come, non riscoprendo il cosa).
Il rischio: l'effetto del secondo sistema. Le ricostruzioni raccolgono ogni richiesta di funzionalità differita dal vecchio sistema e falliscono sotto il proprio peso. Mantieni la disciplina sullo scope.
Modalità 4: Isolare e aggirare
Congela il legacy. Mantienilo a mano al livello che il business richiede ancora. Costruisci nuovo valore come nuove app pronte per il Livello 5 accanto a esso, instradando attraverso qualsiasi API o livello di dati che già funziona. Non tentare di modernizzare il legacy stesso.
Quando è giusto: il costo del risanamento supera il valore residuo nel legacy; il nuovo valore può essere consegnato in parallelo senza integrazione profonda; il legacy ha un seam di integrazione praticabile (API, database, coda) attraverso cui le nuove app possono instradare; il business tollera la modalità di manutenzione per un periodo esteso.
Il rischio: il legacy aggirato accumula altro debito nel tempo. Alla fine qualcosa forza la decisione: una patch di sicurezza che non può essere applicata, un EOL della piattaforma, un modello di dati che non può reggere nuovi requisiti. Isolare e aggirare compra tempo; non risolve il problema.
"Non investire" è un risultato legittimo qui. Non ogni legacy vale la pena sistemare. Il segnale: stai scrivendo il tuo terzo piano di risanamento per lo stesso modulo, i test che hai aggiunto l'ultimo trimestre non sono più verdi, e il business consegna ancora valore attraverso questo codice. Non è un codebase che aspetta di essere modernizzato. È un codebase che aspetta di essere sostituito.
Criteri di decisione
| Domanda | Risanare | Strangler | Ricostruire | Isolare |
|---|---|---|---|---|
| L'architettura è fondamentalmente solida? | Sì | Perlopiù | No | Non importa |
| Ci sono seami puliti per l'estrazione? | N/A | Sì | N/A | Almeno un punto di integrazione utilizzabile |
| Il team può descrivere l'intento del sistema? | Sì | Sì | Sì (o usa Black Box to Blueprint) | Non richiesto per il legacy |
| Il business può tollerare sistemi paralleli? | N/A | Sì | Sì | Sì |
| Il pagamento del debito continuato è più economico della sostituzione? | Sì | Parzialmente | No | Sì, mentre il nuovo valore viene spedito accanto |
| Il legacy ha valore residuo che vale la pena preservare? | Sì | Sì | Sì | Sì, ma non vale la pena sistemarlo |
| Hai la capacità del team per l'opzione più difficile? | Minima | Media | Massima | Bassa (il legacy rimane congelato) |
Nessun sì netto sulla riga della ricostruzione? Non ricostruire. L'effetto del secondo sistema punisce i team che hanno scelto la ricostruzione per ragioni diverse dall'adeguatezza.
Diverse risposte "no" tra Risanare/Strangler/Ricostruire, ma il legacy ha ancora valore per il business? Isolare e aggirare è probabilmente la modalità giusta.
Il Technical Debt Quadrant affina la decisione di ricostruzione:
| Tipo di debito | Causa | Rimedio |
|---|---|---|
| Prudente, deliberato | Abbiamo spedito sapendo della scorciatoia. | Di solito rimediabile. |
| Prudente, involontario | Abbiamo imparato meglio dopo. | Rimediabile, ma verifica se l'apprendimento ha invalidato decisioni strutturali. |
| Sconsiderato, deliberato | Sapevamo meglio, lo abbiamo fatto comunque. | Spesso rimediabile con disciplina, ma segnala problemi di processo che sopravvivono al codebase. |
| Sconsiderato, involontario | Non sapevamo cosa stavamo facendo. | Candidato alla ricostruzione. La struttura riflette ignoranza che la conoscenza successiva non può sciogliere in loco. |
Hai bisogno di aiuto per scegliere la modalità giusta? La skill Claude Code codebase-readiness valuta un codebase rispetto al modello di maturità a nove dimensioni e raccomanda un percorso verso il Livello 5, incluso quale delle quattro modalità si applica.
La metodologia: Ricerca, Revisione, Ricostruzione
Pubblicata da Fowler ed EPAM in Research, Review, Rebuild, questa è la metodologia brownfield più concreta disponibile. Si applica direttamente alle Modalità 1–3; nella Modalità 4 si applica al seam di integrazione anche se il legacy rimane congelato. Il deployment diretto degli agenti in un codebase legacy opaco produce in modo affidabile output confidentemente sbagliato. La struttura a fasi previene questo.
Fase 1: Ricerca. L'IA analizza il codice esistente: ricostruisce l'intento, estrae contratti comportamentali, identifica pattern, documenta il grafico delle dipendenze. Strumenti come i connettori MCP permettono agli agenti di attraversare sistematicamente il codebase. Output: una mappa dell'intento: cosa fa il sistema, indipendentemente da come è strutturato.
Fase 2: Revisione. Gli esperti di dominio validano la mappa dell'intento. L'IA può estrarre cosa fa il codice. Solo gli umani possono distinguere il comportamento intenzionale dall'incidente storico. Questo è il collo di bottiglia della capacità: nel caso studio Bahmni (da AngularJS a React), la revisione umana ha richiesto circa 20 minuti per componente. Pianifica la capacità per la revisione, non solo per la generazione.
Fase 3: Ricostruzione. Con l'intento validato, l'IA genera codice sostitutivo con ambiguità minima. Su Bahmni: circa 2 $ per componente in meno di un'ora, contro 3–6 giorni manualmente. L'economia è convincente quando le Fasi 1 e 2 sono disciplinate, e peggiore del tradizionale quando vengono saltate.
L'ordine è portante. I team che saltano ricerca e revisione per arrivare più velocemente alla ricostruzione non risparmiano tempo; producono output sbagliati più velocemente e spendono il tempo risparmiato nel debug del comportamento allucinato.
Economia: cosa implicano i numeri
Il dato di Bahmni riorganizza la matematica: quella che era una migrazione di 18 mesi diventa una migrazione di 6 mesi, dove il vincolo è la capacità dei revisori, non le ore ingegneristiche. Il tuo risultato varierà con l'architettura, la copertura dei test e la complessità del dominio, e l'economia funziona solo quando Ricerca e Revisione sono disciplinate. Saltarle fa collassare l'accelerazione.
Black Box to Blueprint: retroingegneria dell'intento
Quando il team originale se n'è andato, la documentazione è sbagliata e il codice è l'unica fonte di verità, la Fase 1 diventa un problema di retroingegneria. Il Black Box to Blueprint di Fowler descrive cinque tecniche:
- Ricostruzione del livello UI: inferire il comportamento dall'interfaccia utente e dalle sue transizioni di stato.
- Change data capture: osservare come il sistema modifica i dati in produzione per inferire la logica di business.
- Inferenza della logica server: analizzare i confini API e i pattern richiesta/risposta per ricostruire la logica sottostante.
- Archeologia binaria: ricostruire da binari, log e interfacce esterne quando il codice sorgente è perso.
- Arricchimento progressivo multi-pass: suddividere gli artefatti in blocchi gestibili, estrarre insight parziali per ogni pass, costruire contesto in modo incrementale. L'analisi in un singolo shot dell'intero sistema fallisce su scala.
Due discipline non negoziabili: triangolazione (ogni ipotesi sull'intento confermata attraverso due fonti indipendenti: UI + log, API + database, codice + comportamento osservato) e tracciamento della provenienza (per ogni affermazione, registra le prove su cui si basa, così le prove inaffidabili sono identificabili in seguito).
Spec-from-code: l'inversione brownfield
Gli Standard di esecuzione IA e la Guida alle specifiche assumono che le specifiche precedano il codice. Il brownfield inverte questo: il codice esiste già, e la specifica deve essere retroingegnerizzata da esso. Questo è un flusso di lavoro diverso.
Gli strumenti di spec-driven development come spec-kit, Kiro e Tessl sono principalmente orientati al greenfield. Il "Brownfield Bootstrap" di spec-kit è l'eccezione: scoperta automatica dell'architettura esistente per stabilire una Costituzione (principi di governance persistenti), poi applicazione dello spec-driven development solo alle nuove feature mentre Ricerca e Revisione recuperano sulla superficie legacy.
Il pattern che funziona:
- Estrarre la specifica implicita. Cosa fa davvero il sistema? Vedi la sequenza brownfield del Lab IA per la versione disciplinata.
- Scrivere scenari end-to-end che descrivono il comportamento atteso corrente dalla specifica estratta.
- Verificare che gli scenari passino sul codice esistente. Questo diventa il tuo harness di regressione.
- Applicare il spec-first a tutto il nuovo lavoro. Nessuna eccezione.
- Migrare con lo strangler-fig componente per componente, usando gli scenari come protezione durante la migrazione.
Il primo passo è il lavoro umano più difficile nella transizione. Gli agenti possono documentare cosa fa il sistema; solo gli umani possono rispondere se è quello che dovrebbe fare.
Insidie comuni
Sottovalutare il collo di bottiglia della revisione umana. I costi di generazione dell'IA sono crollati di ordini di grandezza. I costi di revisione umana no. Pianifica la capacità dei revisori come un vincolo di prima classe, non un'aggiunta.
Brownfield mezzo-Lab. Eseguire parte del progetto in modalità AI-native e parte in modalità tradizionale perché "quella parte è più veloce nel vecchio modo" non produce nessun beneficio. L'elenco delle insidie del Lab IA cita questo specificamente.
Trattare i seami come dati quando sono impliciti. Lo strangler-fig funziona bene sulle lavagne bianche. In pratica, i "seami puliti" sono dove le responsabilità possono essere estratte senza accoppiamento a otto altri moduli. Se questo non è vero del tuo codebase, lo strangler-fig diventa una ricostruzione completa con passaggi extra.
Confondere il costo di modernizzazione con il costo di sostituzione. La decisione "risanare vs. ricostruire" non riguarda se il fixing costa denaro: entrambi costano. Riguarda se la struttura può reggere ciò di cui hai bisogno. Il debito sconsiderato-involontario non può essere sciolto in loco indipendentemente dal budget.
Panorama degli strumenti (snapshot)
Il framework non raccomanda strumenti specifici; il panorama cambia troppo velocemente. Ma vale la pena conoscere: spec-driven development (spec-kit, Kiro, Tessl: vedi il confronto di Fowler); connettori MCP per l'attraversamento sistematico del codebase; piattaforme agente (Claude Code, Cursor, Aider, Devin) con diversi tradeoff autonomia/human-in-the-loop; benchmark (SWE-bench, IDE-Bench): ma i punteggi benchmark su problemi curati non predicono le prestazioni brownfield sul tuo codice.
Specchio: strategia e affidabilità
L'Ingegneria dell'affidabilità riguarda la creazione di sistemi affidabili da output IA inaffidabili. La strategia brownfield riguarda il rendere gli agenti IA efficaci su codebase inaffidabili. I due convergono nel harness: sensori veloci, intento documentato, validazione a livello di scenario. Una migrazione brownfield che non termina con il codebase al Livello 5 di maturità e non corrisponde alla disciplina dell'Affidabilità ha avuto successo nella forma ma non nella sostanza.
Correlati
- Maturità del codice: la diagnostica da cui dipende questa pagina
- Lab IA: la modalità di lavoro per il Grado 5 una volta arrivati
- Ingegneria dell'affidabilità: il problema speculare
- Standard di esecuzione IA e Guida alle specifiche: ingegneria delle specifiche
- Pratiche ereditate: i pattern umani che spesso accompagnano il codice legacy
Fonti
- Fowler, M. (2026). "Harness Engineering for Coding Agent Users." martinfowler.com
- Fowler, M. (2026). "From Black Box to Blueprint: Reverse-Engineering Legacy Systems with AI." martinfowler.com
- Fowler, M. & EPAM. (2026). "Research, Review, Rebuild: AI-Assisted Legacy Modernization." martinfowler.com
- Fowler, M. (2024). "Rewriting the Strangler Fig Application." martinfowler.com
- Fowler, M. "Strangler Fig Application." martinfowler.com
- Fowler, M. "Technical Debt Quadrant." martinfowler.com
- Fowler, M. (2026). "Spec-Driven Development: The Three Tools." martinfowler.com
- GitHub. "Spec Kit." github.com/github/spec-kit
- Duvall, P. (2026). "AI Development Patterns." github.com/PaulDuvall/ai-development-patterns
- Feathers, M. (2004). Working Effectively with Legacy Code. Addison-Wesley.
- "Artificial Intelligence for Software Architecture: A Literature Review." (2025). arXiv. arxiv.org/abs/2504.04334
- "IDE-Bench: Evaluating LLM Agents on Real Codebases." (2026). arXiv. arxiv.org/abs/2601.20886
- SWE-bench. swebench.com
← Torna alla home · Maturità del codice · Lab IA · Ingegneria dell'affidabilità · Glossario