--- title: "deploy to prod. make no mistakes. Gli errori che un deploy non vede" url: "https://simonebova.com/it/writing/deploy-to-prod-make-no-mistakes" lang: "it" updated: "2026-09-04" author: Simone Bova alternates: it: "https://simonebova.com/md/it/writing/deploy-to-prod-make-no-mistakes" en: "https://simonebova.com/md/en/writing/deploy-to-prod-make-no-mistakes" pl: "https://simonebova.com/md/pl/writing/deploy-to-prod-make-no-mistakes" --- # deploy to prod. make no mistakes. Gli errori che un deploy non vede 2026-09-04 · Diario Il Company Brain di Yempik era in produzione e la ricerca tornava vuota. Cosa chiede davvero «make no mistakes»: percorsi interi, sessioni lunghe, approvazioni vere. «deploy to prod. make no mistakes.» è il prompt che ho scritto a Claude una sera di fine luglio dalla [Italian Founders House](https://www.linkedin.com/company/italian-founders-house/), al campus di H-FARM, con il twin [Raffaele](https://www.linkedin.com/in/raffaele-zarrelli/) di fianco che promptava come un forsennato. Era la settimana del lancio del Company Brain di Yempik: un cervello aziendale governato, che persone e agent leggono e arricchiscono dai loro assistenti AI. Il deploy è stato la parte facile. Gli errori veri non li vedeva nessun deploy. Li hanno trovati l'uso reale e i test messi sui confini giusti, e quasi tutti avevano la stessa forma: ogni pezzo funzionava, e il percorso intero no. ## Un dato approvato può esistere ed essere invisibile Nei primi giorni un agent ha lavorato sul Brain per un'intera giornata vera: proposte, revisioni, letture da una sessione all'altra. Le approvazioni funzionavano. La ricerca no: domande naturali, che dovevano trovare conoscenza appena approvata, tornavano vuote. I dati c'erano. Il passaggio che rende cercabile un dato approvato falliva senza lasciare traccia, e nei log non c'era un solo errore. Scrittura riuscita, approvazione riuscita, dato salvato: sembrava un flusso completo. Il test che l'avrebbe preso è uno solo, e fa il percorso intero come lo fa chi usa il prodotto: crea, approva, cerca, trova. Recuperare i dati rimasti indietro chiudeva l'incidente e lasciava intatta l'ipotesi che l'aveva causato, cioè che ogni passaggio in background arrivi sempre a destinazione. Così nello stesso giorno ho aggiunto un check periodico che ripara da solo quello che è rimasto indietro, ho fatto in modo che il prodotto distingua «non c'è niente» da «sono ancora indietro», e ho messo quel test end to end sull'ambiente vero. Le stesse domande, rifatte dallo stesso assistente, hanno trovato la risposta giusta al primo posto. Pochi giorni dopo abbiamo costruito la review dei repository GitHub con lo stesso schema fin dall'inizio: ogni evento salvato prima di essere lavorato, e una riconciliazione per quelli persi. ## Una feature manca davvero se l'ingresso più usato non può darle i dati Poco dopo lo stesso bug è tornato in un'altra forma. Il Brain sapeva collegare la conoscenza a persone, aziende e progetti: il grafo esisteva da tempo, salvato e navigabile. Lo strumento con cui gli assistenti proponevano conoscenza però non aveva modo di dichiarare quei collegamenti, quindi tutto quello che era entrato da lì era nato scollegato. Ogni parte era stata validata per conto suo. Nessuno aveva seguito un oggetto vero dall'ingresso fino alla feature che lo usava. Lo stesso vale per la CI. Un audit onesto ci ha detto che la pipeline controllava tipi, lint, logica di base e permessi sul database. La build di produzione, i test dell'app e quelli sull'ambiente remoto li facevamo a mano in sessione, e una delle valutazioni si disattivava da sola senza avvisare. Il badge verde diceva solo che erano verdi i check eseguiti. Il resto era trust me bro. Da allora ogni release dichiara cosa è stato verificato, cosa è stato skippato e cosa resta da fare. Lo stesso lo chiedo a ogni PR: il template di questo sito vuole Testing, Risk e How to revert ([ne parlo qui](https://simonebova.com/it/writing/nessuno-legge-ogni-riga)). E il test va messo sul confine reale più profondo che riesci a esercitare senza fingere. Per alcune azioni, testare il percorso dall'interfaccia voleva dire simulare mezzo framework, e avremmo testato la simulazione. Abbiamo messo il test sull'operazione vera nel database, e l'interfaccia la guardiamo su un ambiente di preview. ## Una prima chiamata riuscita non dice niente sulla sessione Il connettore che collega gli assistenti al Brain superava il check iniziale: identità verificata, prima chiamata verde. Dopo pochi minuti chiedeva di nuovo di accedere. Sembrava un accesso che scadeva troppo presto. La causa stava nel modo in cui le connessioni parallele di uno stesso assistente rinnovavano l'accesso: si pestavano i piedi, e il sistema di autenticazione, per prudenza, le chiudeva tutte. Riconnettersi e vedere un'altra chiamata verde non avrebbe provato niente. Come prova ho accettato solo una sessione reale e lunga, con il rinnovo dell'accesso avvenuto in mezzo, tra due chiamate riuscite. Per qualunque connettore la verifica giusta è una sessione lunga, con più connessioni aperte insieme e il recupero quando una cade. ## Prima mostra conoscenza utile, poi chiedi di collegare l'assistente Collegare il proprio assistente al Brain era la cosa che ci distingueva, quindi veniva naturale metterla al primo passo dell'onboarding. Abbiamo scelto l'ordine opposto: prima collega la posta e approva la prima proposta, poi collega l'assistente, poi invita il team. Un assistente collegato a un Brain vuoto non ha niente da dire, e brucia il momento di attenzione migliore che avrai. Nella stessa decisione abbiamo tolto le domande al signup e il wizard a più schermate. Al loro posto c'è una checklist in home, con un'azione principale alla volta, perché un wizard nasconde il punto esatto in cui le persone si perdono. Il segnale che guardiamo è quanto ci vuole per arrivare alla prima conoscenza approvata, nella stessa sessione. ## L'approvazione umana è una dipendenza di produzione Il Brain ha una regola di fondo: tutto quello che arriva da chat, file, posta, routine o assistenti entra come proposta, e diventa verità solo dopo una decisione umana. Il nostro team però leggeva il Brain direttamente dagli assistenti, senza aprire l'app. Le proposte si accumulavano, e la parte approvata invecchiava ogni giorno. Una schermata di approvazione copre metà della governance. L'altra metà è portare la decisione a chi deve prenderla, dove lavora già. Abbiamo progettato reminder agli owner fuori dalla piattaforma: raggruppati, senza doppioni, con un link diretto alla queue, e che smettono da soli quando la queue è vuota. Una approval queue va guardata come qualunque altro backlog di produzione: se nessuno approva, la conoscenza nuova non arriva a chi la usa. ## Un'approvazione vale per l'azione che hai visto Dal Brain un'approvazione può al massimo preparare un draft di email, mai inviarla. Anche così abbiamo dovuto decidere cosa succede quando non sai se l'azione è andata a buon fine. Il retry è la risposta standard a un errore temporaneo, e qui produrrebbe draft doppi. Su un invio, email doppie a un cliente. Quando l'esito è ignoto, il sistema lo dice e aspetta una persona. L'approvazione poi è legata all'azione esatta che la persona ha visto: contenuto, fonti, destinatari, condizioni. Se qualcosa cambia dopo, l'approvazione decade. Prima di agire il sistema ricontrolla che chi ha approvato possa ancora farlo. Un «approvato» rimasto in interfaccia mentre l'azione cambia sotto autorizza una cosa che nessuno ha visto. ## L'obiezione: troppa governance per un prodotto appena nato L'obiezione più forte a tutto questo: un prodotto appena lanciato deve spedire e imparare, e tanta governance lo rallenta. Su questo non ho cambiato idea. La governance è la parte che usiamo ogni giorno, perché è quella che ci permette di far leggere e proporre gli agent senza che scrivano verità da soli. ## Da lunedì - Scrivi un test che faccia il percorso intero dal lato di chi usa il prodotto: crea, approva, cerca, trova. - Accanto a ogni passaggio in background che può fallire in silenzio metti un check che ripara. - Segui un oggetto vero dall'ingresso più usato fino all'ultima feature che ne dipende. - Testa i connettori su una sessione lunga, con più connessioni aperte. - Dai alle approvazioni un canale verso chi deve decidere. - Per ogni effetto esterno decidi prima cosa fai quando non sai se è andato a buon fine. - In ogni release dichiara i check eseguiti, skippati e ancora da fare. *// la scheda del Brain che documenta il bug dei collegamenti è anche la prima arrivata da un assistente con i collegamenti dichiarati.* [simone@yempik.ai](mailto:simone@yempik.ai) · [Book a call](https://calendar.app.google/LKDrQPKGV2EAFCMN9)