Abbiamo costruito una fabbrica che ripara il software mentre dormiamo
Una routine incastrata per 33 giorni senza che nessuno se ne accorgesse. Così abbiamo costruito un loop che trova i guasti da solo e li ripara di notte.
In breve. Il 24 luglio la routine che aggiornava i dati di un mio progetto si è incastrata. Me ne sono accorto il 26 agosto: 33 giorni dopo. Da lì abbiamo costruito un loop che sorveglia il progetto da solo, ripara un problema alla volta e fa verificare il risultato da un attore indipendente. Quattro problemi sono già stati chiusi così, dall'inizio alla fine, senza che io toccassi niente. Quattro casi non fanno una statistica: dimostrano che il giro esiste davvero. Pubblicato il 3 ottobre 2026.
Il guasto di cui mi sono accorto dopo 33 giorni
Nessun errore, nessuna pagina rotta. La routine girava, scriveva i suoi log, sembrava viva. Solo che i dati che produceva erano fermi. Per 33 giorni ho guardato un sistema che mi diceva che andava tutto bene, e gli ho creduto.
Quando finalmente ho guardato dentro, ho fatto un audit di un'ora su un progetto di 115 file. Quello che ho trovato mi ha dato fastidio più del guasto iniziale. Il miglior risultato della flotta era finto: l'unica strategia con un risultato statisticamente interessante girava su una cache ferma da due mesi e sceglieva sempre gli stessi tre titoli. Nel registro dei rendimenti c'erano 18 giornate mai vissute: il portafoglio diceva di tenere 71 titoli e aveva fatto esattamente 0,00% mentre il mercato saliva. Due strategie erano cieche da 78 giorni, e ogni mattina il sistema scriveva "torna nei prossimi giorni".
Pensavo che il problema fosse accorgersi in tempo. Mi sono accorto che il problema era un altro: avevo costruito un sistema che aveva bisogno di me sveglio per funzionare, e io non sono un buon sistema di monitoraggio.
Pensavo bastasse un agente sveglio
La prima reazione è stata quella ovvia: mettiamoci un agente sopra. Digli di sistemare le cose, fagli controllare ogni mattina, problema risolto. L'ho provato, e ho scoperto il secondo guasto, peggiore del primo.
Gli dici "sistema le cose", sistema qualcosa, ti scrive che è a posto. Chi ha fatto la modifica è anche l'unico che ha certificato che funziona. È come chiedere a chi ha corretto il proprio compito in classe di darsi il voto. A volte il voto è giusto, ma non lo saprai mai con certezza, e le volte in cui è sbagliato sono esattamente quelle che costano di più.
La cosa che non avevo capito è che stavo automatizzando la fiducia invece dell'affidabilità. Un agente che si dà la sufficienza da solo non è un sistema affidabile con un difetto: è un sistema non verificabile per costruzione.
Cosa abbiamo cambiato
Da lì abbiamo cambiato approccio. Tre regole, tutte noiose, nessuna intelligente. Il progetto dove vive questo loop si chiama Northstar Factory, e le tre regole sotto sono scritte nel suo registro, non nei suoi prompt.
Prima: un problema alla volta, un solo posto di guida. Finché una riparazione è in volo sullo stesso punto, nessun'altra parte. E a rifiutarla è il registro, non il prompt. Se la regola vive nel prompt, vale finché il modello se la ricorda. Se vive nel registro, vale sempre.
Seconda: il selettore che sceglie il prossimo problema non è un modello linguistico. È una funzione deterministica: a parità di condizioni sceglie sempre la stessa cosa, e si può rileggere il perché. Le decisioni strategiche le prende il modello; l'ordine di lavoro no.
Terza, quella che tiene su tutto: chi scrive la cura non ha le parole per dire che funziona. Il verdetto lo emette un comando separato, fuori dalla sua sessione, sul codice davvero rilasciato. Se il problema c'è ancora, resta aperto. Punto.
La sera del primo giro completo ho guardato i receipt di ogni passaggio e ho pensato che sembrava burocrazia. Poi ho contato: quattro problemi chiusi su un progetto vero, PR dalla numero 4 alla 7, dall'inizio alla fine, senza che io toccassi niente. La burocrazia aveva lavorato mentre dormivo.
Quanto è affidabile, onestamente
Qui devo essere onesto, perché i numeri senza contesto sono il modo più veloce per mentire dicendo la verità. La conformità del sistema alla sua stessa specifica di riferimento oggi è 69,7 su 100, con zero difetti gravi. La soglia che ci siamo dati per considerarlo usabile da altri è 90. E quel voto me lo do da solo: i casi di riferimento non sono ancora una suite eseguibile, è il prossimo lavoro in lista.
Quattro problemi chiusi non fanno una statistica. Fanno una prova di esistenza: il giro completo gira per davvero, non solo nei test. La differenza tra "funziona una volta" e "funziona sempre" è esattamente quello che il sistema sta cercando di misurare su se stesso.
Cosa significa "mentre dormiamo"
La notte è diventata un turno di lavoro. Il loop osserva, sceglie il prossimo problema, esegue la riparazione, la fa verificare da un verificatore indipendente, registra tutto in un diario che nessuno può riscrivere. La mattina trovo il diario, non una sensazione.
Questo cambia anche come penso ai costi, perché un sistema di agenti non costa solo i token del modello: pesano il contesto rimandato a ogni chiamata, i tentativi ripetuti, i controlli di qualità. Ne parlo in dettaglio nella guida agli agenti AI in azienda e nel pezzo su come organizzarli come un'azienda. La fabbrica non elimina questi costi, li rende visibili: ogni receipt dice cosa è stato fatto e da chi è stato verificato.
E c'è una condizione che va detta chiara, perché senza questa tutto il resto è teatro: se il tuo progetto non ha nemmeno una misura che una macchina sa leggere da sola, un loop del genere gira a vuoto e dice "tutto verde". Che è peggio del silenzio, perché sembra una risposta. Prima la misura, poi l'autonomia. Del debito tecnico nascosto di questi sistemi, e di come evitarlo, ho scritto una guida separata.
Cosa non prometto
Non prometto che questo disegno regga un team intero o un'azienda intera. È una domanda aperta, non una promessa: finora il loop ha riparato danni al codice, non ha preso decisioni di prodotto. Il passaggio da "ripara da solo" a "decide da solo" è un altro confine, con altre regole, e non l'ho attraversato.
Quello che so, perché l'ho visto succedere, è questo: i guasti che ti uccidono non sono quelli che fanno rumore. Sono quelli che scrivono "torna nei prossimi giorni" per 78 giorni di fila mentre nessuno guarda. E contro quelli, l'unica cosa che ha funzionato per me non è stata un agente più intelligente. È stato togliere all'agente il diritto di dire "è a posto".
Domande frequenti
Cosa fa esattamente questa "fabbrica"?
Sorveglia un progetto software, trova da sola i problemi che nessuno nota, ne ripara uno alla volta e fa verificare ogni riparazione da un verificatore indipendente. Un problema alla volta, mai in parallelo sullo stesso punto.
Perché il verificatore deve essere indipendente?
Perché chi ha fatto la modifica non può essere l'unico a certificarla. È la stessa ragione per cui in azienda chi spende non è chi approva il budget: non è sfiducia, è disegno del controllo.
Quanto costa farla girare?
Oltre ai token del modello, pesano contesto, tentativi ripetuti e controlli di qualità. La regola pratica che uso è in quanto costa usare un LLM: stimare "token per costo per richieste" sottovaluta quasi sempre la spesa reale.
Funziona su qualsiasi progetto?
No. Serve almeno una misura che una macchina sa leggere da sola: test, contratti, metriche. Senza quella, il loop gira a vuoto. È il prerequisito, non un dettaglio.