Marginal Gains per le macchine: sistemi che migliorano ogni volta che sbagliano.

In breve. Nel ciclismo britannico i marginal gains significano migliorare ogni cosa dell'1% e lasciare che la somma faccia il resto: ne parla bene la guida esistente sul metodo applicato al SaaS. Alle macchine però serve un meccanismo diverso, che ho visto funzionare costruendo la Northstar Factory: non aggregare micro-miglioramenti, ma convertire ogni fallimento in una regola durevole con il suo test di regressione. Così il prossimo errore che ci sorprende è un errore nuovo: i vecchi sono già diventati test. Due factory e una manciata di regole: prova di esistenza, non statistica. Pubblicato il 3 ottobre 2026.

La credenza: basta non sbagliare

Per anni ho trattato gli errori dei miei sistemi come incidenti da chiudere in fretta: fix, deploy, dimentica. La salute di un sistema mi sembrava l'assenza di guasti, e il silenzio il segnale migliore. Ogni postmortem finiva in un documento che nessuno rileggeva e ogni lezione moriva con il turno di chi l'aveva imparata.

Mi sono accorto che stavo buttando via la parte più preziosa del lavoro quando ho contato quante volte lo stesso tipo di guasto tornava sotto nomi diversi. Il sistema non migliorava: riparava. E riparare senza imparare è un abbonamento a vita allo stesso incidente.

Dieci regole nate da dieci difetti

Nella constitution del progetto, le regole dalla 17 alla 26 hanno una caratteristica che le distingue dalle altre: ognuna nasce da un difetto riprodotto per esecuzione su un progetto reale, e ognuna ha il suo test di regressione nel repo. Non sono principi caduti dal cielo. Sono cicatrici con il referto.

L'esempio più fresco è di oggi. Il loop pubblicava articoli e per due volte ha lasciato passare un accento mancante, prima su "così" poi su "più": nessun gate copriva l'ortografia, quindi il difetto passava. Al secondo caso è scattato il meccanismo che avevamo scritto in anticipo: due osservazioni dello stesso difetto giustificano un gate generale. Ora esiste un gate di copy-edit deterministico, con i suoi test, che controlla accenti e refusi meccanici su ogni articolo futuro. Ieri il loop non sapeva farlo, oggi sì. Non perché qualcuno l'ha reso più intelligente: perché ha sbagliato due volte nello stesso punto e la seconda è diventata regola.

Pensavo che il problema fosse evitare gli errori. La cosa che non avevo capito è che l'errore è l'unica materia prima che un sistema non può comprare: ogni fallimento contiene gratis l'istruzione esatta per non ripeterlo, a patto di convertirlo subito in qualcosa che una macchina sa rieseguire. Una regola senza test è un postmortem. Una regola con test è un invariante.

Misurare per sbloccare, rimisurare dopo la cura

C'è un secondo meccanismo che compone con il primo. Nel loop, una misura verificata sblocca il lavoro che ne dipendeva: finché non sai misurare un problema, i lavori sopra restano fermi, e quando la misura arriva si muovono da soli. E dopo che una cura è partita, il sistema la rimisura in produzione prima di dichiararla buona: il verdetto sul deploy non chiude niente finché la realtà non conferma.

Qui secondo me sta la differenza con i marginal gains umani. L'1% di Brailsford si somma perché qualcuno lo mantiene. Nelle macchine niente si mantiene da solo: o il miglioramento è un test che gira, o è un ricordo che sbiadisce. Il compounding delle macchine non è addizione di micro-vittorie, è accumulo di invarianti verificate.

Saper dimenticare niente

L'ultimo pezzo è la memoria con provenance. Il diario dice cosa è successo, la memoria dice cosa abbiamo imparato, e le due cose restano separate: un futuro giro legge le regole, non migliaia di receipt. Le ipotesi smentite valgono quanto le cause confermate, perché escludono strade: è la conoscenza negativa di prima classe.

La regola che mi tengo più stretta è quella sul numero di osservazioni: nessuna regola durevole da una singola osservazione debole. Sembra prudenza, ma è il meccanismo anti-superstizione del sistema: senza, ogni coincidenza diventerebbe legge e il loop imparerebbe rumori invece di lezioni.

Cosa faccio adesso quando qualcosa fallisce

Tre mosse, sempre le stesse. Riproduco il difetto per esecuzione, mai a memoria. Scrivo la regola come esito da preservare, non come implementazione. Aggiungo il test che rigioca il caso e pretendo che resti verde. Se il difetto è il secondo della stessa specie, generalizzo nel gate corrispondente; se è il primo, resta episodio con provenance e aspetto.

Cosa non prometto

Non prometto che le organizzazioni che convertono ogni incidente in test battano quelle che scrivono postmortem: è una hypothesis, e la differenza si misura in anni, non in settimane. Quello che so è cosa è successo ai miei sistemi quando ho smesso di chiedermi "come evitiamo gli errori" e ho iniziato a chiedermi "come facciamo a sbagliare solo errori nuovi". La seconda domanda ha una risposta operativa. La prima no.

Domande frequenti

Non si rischia di accumulare troppe regole?

Sì, ed è il fallimento tipico: regole che nessuno osa toccare. L'antidoto è che ogni regola porta il suo test e la sua provenance: quando il contesto cambia, il test che fallisce dice esattamente quale regola è scaduta.

Vale anche per team di persone, non solo software?

Penso di sì nella forma: incidente riprodotto, regola scritta come esito, verifica rieseguibile. Ma la mia evidence è su sistemi software, quindi lo tratto come estensione ragionevole, non come promessa.

Da dove parte chi non ha niente?

Dal diario: registra cosa succede per una settimana senza cambiare nulla. Il primo pattern che si ripete due volte è la tua prima regola candidata.