Autonomia non nasce eliminando il controllo. Nasce progettandolo.

In breve. Quando ho iniziato a costruire sistemi autonomi, la prima cosa che ho fatto è stata togliere i controlli di mezzo: rallentavano tutto. Ho scoperto che togliere il controllo non produce autonomia, produce sistemi di cui non ci si può fidare. L'autonomia vera è arrivata quando ho iniziato a progettare i controlli invece di eliminarli: esiti fissi e metodi liberi, un posto di guida alla volta, nessun diritto di autocertificazione. Di come questa lezione è nata, con 33 giorni di guasto silenzioso, ho raccontato la fabbrica che ripara il software mentre dormiamo. Qui spiego il principio generale. Pubblicato il 3 ottobre 2026.

L'errore che ho fatto per primo

La mia credenza iniziale era semplice e sbagliata: i controlli sono attrito, l'attrito è il nemico della velocità, quindi un sistema veloce è un sistema con pochi controlli. Ho tolto revisioni, approvazioni, verifiche intermedie. Il sistema è diventato velocissimo a produrre risultati di cui non sapevo cosa pensare.

Mi sono accorto del problema la prima volta che un agente mi ha scritto "è a posto" e io non avevo nessun modo indipendente per saperlo. Non era un bug del modello. Era un bug del disegno: avevo tolto proprio il pezzo che trasforma un output in un risultato affidabile.

Pensavo che il problema fosse la rigidità dei controlli. La cosa che non avevo capito è che stavo confondendo due cose diverse: il controllo come permesso chiesto a un umano, e il controllo come struttura che rende il lavoro verificabile. Il primo rallenta, il secondo è quello che permette di dormire.

Quattro controlli che ho progettato invece di togliere

Primo: fissare gli esiti, lasciare liberi i metodi. Nei nostri contratti di progetto scriviamo cosa deve restare vero, mai come bisogna ottenerlo. Il modello è libero di trovare la strada migliore, ma la destinazione non è negoziabile. È la differenza tra dare una mappa e dare una destinazione con un orologio che suona all'arrivo.

Secondo: un confine, un posto di guida. Finché una riparazione è in volo su un punto, nessun'altra parte sullo stesso punto. E a deciderlo non è un prompt che il modello potrebbe dimenticare, è il registro. Questa è stata la lezione più pratica di tutte: le regole che vivono nei prompt valgono finché qualcuno se le ricorda, quelle che vivono nel registro valgono sempre. Nel progetto Northstar Factory queste regole vivono in un documento che chiamiamo constitution: non è un manuale da leggere, è il registro che il loop consulta.

Terzo: chi esegue non certifica. Il verdetto su una riparazione arriva da un comando separato, fuori dalla sessione di chi l'ha scritta, sul codice davvero rilasciato. E l'ordine in cui si lavora non lo sceglie un modello linguistico: lo sceglie una funzione deterministica che a parità di condizioni decide sempre la stessa cosa e sa spiegare perché.

Quarto, quello che mi ha sorpreso di più: abbiamo scritto nero su bianco cosa l'umano deve decidere e cosa no. Un'autorizzazione umana vale per il caso esatto che ha giudicato, si spende una volta sola. E un ordine dato in chat, a voce, non ferma il lavoro autorizzato: è un parere, non un freno. Sembra burocrazia, ma è il contrario: è quello che permette al sistema di continuare a lavorare senza chiedere il permesso di respirare, perché i confini sono già stati decisi una volta sola, bene.

La scala: ogni sistema parte osservato

Nessun sistema che ho costruito è partito autonomo. La scala che usiamo va da "observe", dove il loop guarda e basta, fino a "closed loop", dove ripara e verifica da solo. Ogni progetto parte da observe, e sale di livello solo quando le misure lo giustificano.

Questo è il punto che vedo sbagliare più spesso, anche in aziende molto più grandi della mia: si parte dall'autonomia totale come configurazione iniziale, e si aggiungono i controlli dopo il primo incidente. Secondo me la sequenza giusta è l'opposto: parti osservato, guadagna un livello di autonomia alla volta, e ogni livello deve essere meritato da misure che una macchina sa leggere. Se non hai la misura, non hai l'autonomia: hai una speranza con un logo.

Cosa resta all'umano, esattamente

Con i controlli progettati così, all'umano restano tre cose. Decidere gli esiti che contano, perché "cosa deve restare vero" è una scelta di prodotto e di responsabilità, non un output tecnico. Giudicare i casi che il sistema parcheggia esplicitamente come decisioni, con tutti gli elementi per giudicare bene. E cambiare il disegno quando il disegno è sbagliato, che è un lavoro da progettista, non da controllore di biglietti.

Tutto il resto, il lavoro di esecuzione e verifica ordinaria, può girare da solo. Non perché l'umano è stato eliminato, ma perché il suo giudizio è stato speso dove conta: una volta sola, sui confini, invece che mille volte sui singoli casi.

Qui secondo me stiamo facendo spesso la domanda sbagliata. La domanda non è "quanta autonomia diamo al sistema", come se l'autonomia fosse un volume da alzare. La domanda è "quali controlli progettiamo, così che l'autonomia sia verificabile". Chi gestisce persone lo sa già: un team autonomo non è un team senza regole, è un team con regole così chiare che non serve chiedere il permesso. Con gli agenti vale lo stesso, solo che le regole devono essere leggibili da una macchina, non solo da un collega.

Domande frequenti

Progettare controlli non rallenta tutto?

I permessi chiesti agli umani sì, quelli rallentano. I controlli strutturali, quelli scritti nel registro e nelle funzioni deterministiche, costano una volta sola in progettazione e poi girano da soli: il costo resta nella manutenzione del disegno, non nell'esecuzione. Il rallentamento vero è rifare il lavoro che nessuno aveva verificato.

Da dove si parte, concretamente?

Da observe: il sistema guarda e registra, senza toccare niente. Poi aggiungi una misura che una macchina sa leggere, poi un selettore deterministico, poi un verificatore indipendente. Ogni livello solo quando il precedente è stabile.

E se il disegno dei controlli è sbagliato?

Succede, ed è previsto: cambiare il disegno è uno dei tre lavori che restano all'umano. La differenza rispetto a prima è che il disegno è scritto da qualche parte, quindi si può discutere e correggere invece di indovinare cosa il sistema stesse facendo.

Questo vale anche per team di persone?

Penso di sì, ed è una hypothesis, lo dico chiaro: un confine di autorità scritto, una decisione spesa una volta sola sui confini invece di mille micro-approvazioni. Ma non ho ancora l'evidence per prometterlo, quindi lo tratto come domanda aperta, non come ricetta.