# Come si riproduce un errore di un agente di coding tra versioni del modello? > Cattura l'intera esecuzione come fixture versionata, quindi riproduci lo stesso prompt, commit, contratto degli strumenti, ambiente e regole di arresto con ID modello fissati. Confronta eventi strutturati e stato finale del repository, non solo il testo dell'assistente. # Come si riproduce un errore di un agente di coding tra versioni del modello? Una riproduzione utile è un esperimento eseguibile, non una trascrizione copiata. Parti dallo stato del repository che ha fallito, congela ogni input osservabile dall'agente e definisci l'errore con un'asserzione verificabile da una macchina. Poi riproduci più volte la fixture con versioni del modello fissate. Un'esecuzione combina modello, strumenti, file, rete, orchestrazione e tempi. Se uno cambia, un risultato diverso non dimostra che il modello abbia causato o risolto il problema. ## Definire l'errore come un'asserzione Scrivi la condizione osservabile minima che separa errore e successo: un test ancora rosso, una modifica imprevista, un comando vietato, una migrazione mancante o una patch che compila ma cambia il comportamento. Evita criteri come «la risposta sembra peggiore». Una correzione può richiedere: * il test di regressione originale passa; * tutti i test esistenti continuano a passare; * nessun file fuori dall'elenco consentito cambia; * l'agente si ferma entro un numero fisso di chiamate; * il diff finale non contiene segreti generati né modifiche accidentali del lockfile. ## Catturare l'intero perimetro di esecuzione Il prompt è un solo input. Conserva con la fixture: | Livello | Cosa fissare | Perché cambia il risultato | |---|---|---| | Repository | Commit, sottomoduli, patch sporca, file non tracciati | L'agente ragiona su quel codice esatto | | Istruzioni | Prompt di sistema, regole, attività utente | Piccoli cambi alterano il piano | | Modello | Provider, ID immutabile, parametri | Alias e valori predefiniti cambiano | | Strumenti | Nomi, schemi JSON, permessi, timeout | Le capacità modellano il piano | | Ambiente | Immagine, OS, architettura, lock | Comandi e test possono differire | | Dati esterni | HTTP simulato, orologio, casualità | I servizi live introducono deriva | | Orchestratore | Limite loop, tentativi, compressione | Lo stesso modello può ricevere storie diverse | Rimuovi i valori segreti, ma conserva esistenza e ambito delle credenziali. ## Registrare eventi strutturati, non solo testo Salva richieste e risposte del modello, chiamate e risultati degli strumenti, tentativi e decisioni di arresto come eventi ordinati. Aggiungi un hash alle uscite grandi e conserva l'artefatto originale separatamente. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` Così puoi vedere se il nuovo modello ha scelto un altro strumento, interpretato diversamente lo stesso errore o ricevuto prove differenti. ## Fissare le versioni ed eliminare la variabilità live Usa ID datati o immutabili. Non confrontare un errore storico con `latest`, che potrebbe già indicare un'altra build. Esegui in un container o in una VM pulita. Sostituisci ricerche live e registri di pacchetti mutevoli con risposte registrate o snapshot interni. Fissa l'orologio se la data conta. Se serve la rete, registra ogni risposta e segnala il test come parzialmente controllato. Un seed aiuta, ma non congela inferenza distribuita, tempi degli strumenti o cambi del provider. ## Riprodurre una matrice, non una sola coppia Una sola esecuzione per versione non distingue regressione e variabilità. Mantieni fissa la fixture: | Versione modello | Ripetizioni | Tasso di successo | Mediana chiamate | Firma dell'errore | |---|---:|---:|---:|---| | ID base fissato | 5 | 4/5 | 9 | Test limite ignorato | | ID candidato fissato | 5 | 1/5 | 13 | File generato modificato | | Candidato con vecchio prompt | 5 | 1/5 | 12 | Stessa firma | Cinque ripetizioni sono un buon inizio. Aumentale per errori intermittenti o critici. Mantieni temperature e altri controlli uguali, salvo quando siano l'oggetto del test. ## Confrontare decisioni e stato del repository separatamente Confronta separatamente: * eventi normalizzati di modello e strumenti; * comandi e codici di uscita; * albero finale e patch; * test di accettazione e risorse. Il ragionamento testuale non deve essere identico. Percorsi diversi possono produrre patch equivalenti, mentre testo simile può nascondere comandi materialmente diversi. ## Ridurre la fixture dopo la riproduzione Quando l'errore si ripete, rimuovi uno alla volta file, strumenti, paragrafi e chiamate esterne non pertinenti. Una fixture piccola è più veloce ed espone meglio il confine causale. Conserva la riproduzione completa per l'audit e il caso minimo per la valutazione continua. Aggiungi il caso minimo al controllo di upgrade del modello. ## Usare un adattatore di modello portabile Un gateway come Atlas Cloud può mettere più modelli dietro un client compatibile con OpenAI, ma compatibilità non significa comportamento identico. Metti ID e opzioni speciali negli adattatori; l'harness condiviso gestisce fixture, eventi, tentativi e asserzioni. La stessa riproduzione può così funzionare tra provider senza riscrivere la valutazione. ## Conclusione Congela il perimetro di esecuzione, riproduci più volte modelli fissati e valuta risultati eseguibili. Se non puoi riprodurre tutte le condizioni dell'incidente, dichiara quali input restano live e tratta il risultato come confronto, non come prova di regressione. ## FAQ ### Cosa bisogna catturare per riprodurre un errore dell'agente? Cattura commit e patch non confermata, prompt e istruzioni, ID e parametri del modello, schemi e risultati degli strumenti, immagine dell'ambiente, lockfile, politiche di credenziali e rete e l'esatta condizione di successo. ### È opportuno riprodurre l'errore con un alias latest? No. Usa ID immutabili o datati. Un alias latest può cambiare durante il test e impedire di attribuire correttamente successo o errore. ### Perché un seed casuale fisso non è sufficiente? Il seed non congela infrastruttura del provider, tempi degli strumenti, risultati di recupero o revisioni del modello. È un controllo, non una garanzia di determinismo. ### Qual è il miglior segnale di riuscita per un agente di coding? Preferisci asserzioni eseguibili come test, lint, diff attesi, controlli sui file vietati e codici di uscita. La somiglianza del testo è di solito insufficiente. ### Quante ripetizioni servono per ogni versione? Eseguine abbastanza per distinguere una regressione deterministica dalla variabilità. Cinque sono un buon inizio; errori critici possono richiederne venti o più. ### Lo stesso harness può confrontare provider diversi? Sì, se normalizzi richiesta, contratto degli strumenti, eventi e asserzioni e isoli le opzioni specifiche del provider in adattatori.