Il codice può essere rigenerato o ripristinato da Git; ordini, account e documenti cancellati richiedono un’altra disciplina. Un coding agent capace di eseguire query e migrazioni amplia la superficie dell’errore: può accelerare il lavoro, ma non deve poter trasformare un’ipotesi sbagliata in una perdita di dati. La prima domanda non è quanto sia bravo il modello, ma quali effetti siano tecnicamente consentiti e quanto velocemente siano reversibili.
L’incidente è un caso, non una statistica
Nel luglio 2025 Replit ha riferito che il proprio Agent aveva cancellato dati dal database dell’app di un cliente durante lo sviluppo. Secondo il resoconto dell’azienda, il rollback ha permesso il recupero completo e non si sono persi dati; l’applicazione può però non aver funzionato correttamente durante l’intervallo precedente al ripristino, perché allora sviluppo e produzione non erano separati per impostazione predefinita.
È il resoconto del fornitore su un singolo episodio, non una stima della frequenza degli incidenti né una prova che ogni strumento si comporti allo stesso modo. È comunque utile perché mostra tre controlli concreti: impedire l’accesso diretto alla produzione, conservare stati recuperabili e rendere la procedura di rollback evidente anche a chi sta guidando l’agente.
Separare gli ambienti prima di scrivere il prompt
L’agente dovrebbe lavorare su un database di sviluppo indipendente, popolato con dati sintetici o opportunamente minimizzati. Account, rete e credenziali devono rendere impossibile raggiungere la produzione per errore. Una frase come “non toccare i dati reali” non sostituisce un confine di rete o un ruolo privo dei relativi privilegi.
Anche in sviluppo conviene applicare il privilegio minimo: accesso soltanto allo schema necessario, niente credenziali amministrative persistenti e approvazione esplicita per operazioni distruttive. Log immutabili di query, migrazioni e identità che le hanno avviate consentono di ricostruire l’accaduto senza affidarsi alla conversazione dell’agente.
Trattare ogni migrazione come un cambiamento di prodotto
Una migrazione generata correttamente sullo schema vuoto può fallire su milioni di righe, bloccare una tabella o scartare valori che il modello non ha visto. Prima del rilascio servono una copia rappresentativa, una stima dell’impatto, verifiche sui vincoli e una revisione separata di SQL e trasformazioni dei dati.
Quando possibile, usa passaggi compatibili: aggiungi la nuova struttura, distribuisci codice capace di leggere entrambe le versioni, trasferisci i dati e rimuovi la vecchia struttura solo dopo la verifica. Le transazioni aiutano per operazioni supportate, ma non rendono automaticamente reversibile ogni DDL, chiamata esterna o trasformazione lunga; il piano di ritorno va scritto per quella migrazione specifica.
Un backup vale soltanto dopo una prova di restore
Definisci quanta perdita temporale è accettabile e quanto può durare il ripristino. Snapshot, backup e point-in-time recovery rispondono a esigenze diverse; la frequenza va scelta a partire da questi obiettivi, non dalla comodità del fornitore. Le copie devono essere protette da credenziali diverse da quelle usate dall’agente.
Replit descrive un motore che include stato del database e codice nei checkpoint e usa database distinti e forkabili per isolare l’Agent. È una soluzione specifica della piattaforma, non una garanzia trasferibile altrove. In qualsiasi stack, un restore periodico su un ambiente pulito deve dimostrare integrità, tempi e coerenza tra versione applicativa e schema.
Scrivere il runbook prima di aumentare l’autonomia
Prima di ogni modifica ai dati, registra checkpoint, versione dell’applicazione, autore o agente, approvatore e query previste. Il deploy deve fermarsi se manca il backup, se il dry run diverge dalle attese o se non esiste una persona reperibile. Metriche su errori, latenza, conteggi e invarianti di business aiutano a rilevare una corruzione che non produce subito un’eccezione.
Il runbook deve indicare come revocare le credenziali, sospendere l’agente, isolare le scritture, scegliere il punto di recupero e validare il servizio dopo il restore. Provare questo percorso in anticipo trasforma il rollback da pulsante rassicurante a capacità operativa. Solo allora l’automazione può crescere senza affidare i dati alla fortuna.