engineering · 2026-07-14

Il Continuous Evolution Loop: cosa significa davvero "auto-migliorante" (e cosa non significa ancora)

Un log di friction-proposal-outcome reale, testato, e usato dal vivo almeno una volta -- ma con un confine onesto tra quello che oggi è automatico e quello che ancora richiede un umano.

"Sistema auto-migliorante" è una delle frasi più abusate nel software AI-first, di solito perché descrive qualcosa che non è mai stato eseguito davvero. Preferiamo essere precisi su cosa succede oggi in questo sistema, passo per passo.

Il ciclo reale è: un'osservazione (un problema, una frizione, un gap ricorrente) viene registrata con una fonte reale. Da quella osservazione nasce una proposta strutturata -- evidenza, impatto, costo, priorità, raccomandazione -- scritta da chi ha osservato il problema, non generata automaticamente da un'analisi che il sistema non può ancora fare da solo senza un modello di linguaggio reale in produzione. La proposta passa attraverso un livello di approvazione reale, con un audit trail completo. Se approvata e implementata, l'esito viene registrato con un riferimento reale al commit che l'ha risolta.

Cosa manca, dichiarato apertamente invece di nascosto: oggi nessun passaggio avviene senza che un agente o un umano lo inneschi attivamente in una sessione di lavoro reale. Non esiste ancora un processo sempre acceso che osserva, propone e implementa senza supervisione -- costruirlo richiederebbe sia un servizio always-on (una decisione operativa separata) sia un modello di linguaggio reale in produzione capace di valutare autonomamente evidenza e impatto (oggi il motore di conversazione di produzione è ancora deterministico, non un vero LLM).

La scelta di essere precisi su questo confine, invece di descrivere il sistema come più autonomo di quanto sia, è essa stessa parte della filosofia di questo sistema: un'evidenza falsa costa più di un gap dichiarato onestamente.

Un esempio reale di questa sessione stessa illustra il ciclo completo: durante un lavoro di migrazione tecnica, un dispatch a un fornitore esterno e fallito per un limite di quota mal riconosciuto dal sistema -- l'osservazione (il fallimento), la causa reale (una parola nel messaggio di errore non ancora riconosciuta), e la correzione (aggiungere quella parola al riconoscimento) sono stati tutti registrati con riferimenti verificabili, non raccontati a parole. Ore dopo, lo stesso tipo di errore su un fornitore diverso e stato riconosciuto correttamente, dimostrando che la correzione era reale e non solo dichiarata.

Questo esempio mostra anche il limite dichiarato con onesta: qualcuno (un agente, un umano) ha dovuto notare il problema e proporre la correzione attivamente. Un ciclo davvero autonomo dovrebbe notare pattern simili da solo, su larga scala, senza che nessuno lo inneschi -- una capacita che richiede sia infrastruttura sempre attiva sia un modello capace di valutare autonomamente cosa merita attenzione, nessuna delle due presente oggi in produzione. La differenza tra 'abbiamo imparato una lezione' e 'il sistema impara da solo' e esattamente questo gap, ed e la ragione per cui il termine 'auto-migliorante' va usato con precisione, non come slogan.

Chi valuta se il proprio sistema e davvero "auto-migliorante" dovrebbe applicare un test semplice: se rimuovessi ogni intervento umano o di agente per una settimana, il sistema continuerebbe a migliorare da solo? Se la risposta onesta e no, il termine giusto e "assistito", non "autonomo" -- una distinzione che vale la pena mantenere anche quando meno impressionante da comunicare.