Un'applicazione enterprise con più di 20 anni di funzionalità accumulate in un unico monolite. Il cliente chiede nuove funzionalità che la vecchia architettura non può supportare. Il problema principale: non si può riscrivere tutto, non si può fermare nulla.

L'Event Storming e la modellazione a Eventi ci hanno aiutato ad affrontare il problema portando alla luce processi dimenticati dagli analisti e funzionalità deprecate di cui nessuno sapeva l'esistenza. Da lì abbiamo applicato i principi di Strangler Fig per isolare il perimetro delle nuove funzionalità e ricostruirlo a partire da una fonte di eventi, senza interrompere il sistema in produzione.

Tuttavia, lo Strangler Fig da solo non è esaustivo nel spiegare l'approccio: le vecchie funzionalità non possono essere rimosse subito, perché altre parti del legacy le consumano ancora. Sopravvivono in uno stato di «animazione sospesa», alimentate dagli eventi del nuovo sistema, in attesa che anche l'ultimo consumatore venga migrato. È il principio o la teoria del tardigrado come organismo microscopico che sospende il metabolismo e sopravvive a tutto, finché ha acqua per reidratarsi.

Poi c'è il problema che nessuno racconta: nel team c'è un Junior. Non conosce i meccanismi dell'architettura ad eventi né strumenti come Claude Code o Codex. Come assegnare quindi le attività? La risposta più ovvia, o forse no, è stata anche la più efficace: ho messo da parte la programmazione, ho lasciato che l'IA implementasse le parti più complesse — meccanismi di riconciliazione, regole di policy, process managers — e ho dedicato il mio tempo al mentoring del Junior, che ha costruito con le sue mani comandi, eventi e viste che tengono in vita il Tardigrado.

L'IA non ha sostituito nessuno. Ha liberato il tempo del Senior per fare ciò che conta di più: far crescere chi verrà dopo.