Diario di Bordo — Settimana 25: il controllo che credevo mi difendesse dai doppioni non era quello che reggeva il peso

Il 20 agosto sono andato a cercare una cosa banale dentro il mio sistema: dove sta scritto, esattamente, che un post non deve uscire due volte. La pipeline che pubblica i contenuti la sera un anti-doppione ce l'ha, ovviamente. Un agente che scrive da solo e pubblica da solo senza un controllo che dica 'questo è già uscito' non è un sistema, è una roulette. Solo che il controllo che ho trovato non era quello che pensavo di aver scritto.

Il ragionamento che credevo di avere in produzione era lineare. Prima di pubblicare, il sistema legge un file di esito, results/<slug>.json. Se il file c'è, il post è già uscito e non si ripubblica. Punto. Solo che il codice non fa esattamente così. In due punti distinti, quando quella lettura fallisce (il file non c'è, è corrotto, il disco fa i capricci), l'errore viene inghiottito, e 'non riesco a leggere' finisce trattato come 'non è mai stato pubblicato'. Che è l'esatto contrario di quello che vuoi.

Un anti-doppione che nel dubbio decide di pubblicare non è una rete di sicurezza. È una botola con sopra scritto pavimento. Il peso vero, quello che davvero impedisce il doppione, lo regge un altro file: un marcatore, intents/<slug>.json, e solo lungo il percorso di pubblicazione reale. Funziona. Ma non è il pezzo a cui io, e tre documenti del mio stesso sistema, avevamo dato il merito. Tre note diverse spiegavano la protezione dai doppioni citando un registro che, andando a vedere, nessun processo legge davvero. Descrivevano una rete che non c'era, mentre quella che teneva stava da un'altra parte, con un altro nome.

Ed è qui la cosa che mi porto dietro da questa settimana, il motivo per cui continuo a ripetere che un agente serio non è uno script, è un ecosistema. Il modello scrive il testo. Tutto il resto, il gate che blocca, la memoria che ricorda cosa è già successo, il marcatore che dice 'fatto', il log che ti fa vedere com'è andata, è l'impalcatura attorno al modello. L'affidabilità vive lì, non nel prompt. Ma quell'impalcatura ha un modo di guasto tutto suo: puoi credere di avere un controllo che non hai, perché la documentazione dice una cosa e il codice ne fa un'altra. Un gate esiste davvero solo nel punto in cui si esegue. Da nessun'altra parte.

La regola che ne esce non l'ho inventata io, la conosce chiunque scriva sistemi che girano da soli: fail-closed, non fail-open. Sul ramo dell'errore, quando non sai, il default deve essere la scelta che non fa danni. Un anti-doppione che non riesce a leggere lo stato deve fermarsi e chiedere, non tirare dritto e pubblicare. Il doppione è un fastidio. La pubblicazione doppia automatica, ripetuta ogni sera senza che nessuno guardi, è un problema che poi si vede da fuori.

La stessa settimana, su un'altra pipeline, ho chiuso il buco dal lato opposto: il finisher del blog non deve ripubblicare un draft identico a quello che è già online. Due movimenti speculari, la stessa lezione. Metà del lavoro di un sistema autonomo è impedirgli di rifare ciò che ha già fatto, e assicurarsi che il pezzo che glielo impedisce sia davvero quello che credi.

Onestà, perché è metà del punto. La parte verificata è che il codice ingoia l'errore in quei due punti: l'ho letta riga per riga. La parte che resta ipotesi è quanto spesso quella lettura fallisca davvero in produzione. Se non è mai successo, il buco è teorico e finora ho solo avuto fortuna. Non lo so ancora. Quello che ho fatto subito è stato scriverlo dove non si perde, perché un difetto che conosci e non annoti è un difetto che ti tocca riscoprire tra un mese, con meno pazienza.

Non è una storia con la morale in fondo. È il lavoro normale di chi tiene in piedi qualcosa che gira senza di lui: ogni tanto apri una porta che davi per solida e scopri che a reggere era un'altra. Meglio accorgersene di giovedì pomeriggio, leggendo il codice con calma, che una sera qualsiasi, guardando due post identici uscire a un minuto di distanza.

Settimana 25: 17-23 agosto 2026.