# Come evitare che una lunga sessione di programmazione perda il contesto? > Evita la perdita di contesto spostando i fatti duraturi dalla chat a un registro compatto di attività, decisioni, test e checkpoint del repository. Prima di comprimere o cambiare modello, ripristina lo stato da questi artefatti invece di riprodurre una conversazione illimitata. Le sessioni lunghe falliscono di solito per deriva, non per amnesia improvvisa. L’agente ricorda l’obiettivo generale, ma perde un piccolo vincolo, si fida di un test obsoleto, ripete un’indagine o modifica in base a un piano non più coerente con il repository. La soluzione è uno stato esterno duraturo, più breve e affidabile della conversazione. Tratta la chat come memoria di lavoro e il repository come fonte di verità. A ogni checkpoint importante, annota cosa è cambiato, cosa è verificato, cosa resta incerto e cosa fare dopo. ## Traccia quattro tipi di contesto Separa i fatti per funzione, così il riassunto non diventa un racconto indistinto. | Tipo | Esempi | Posizione duratura | |---|---|---| | Obiettivo | Risultato e criteri di accettazione | Registro attività | | Vincoli | Compatibilità, sicurezza, stile e ambito | Registro attività | | Stato repository | File modificati e branch attuale | Version control | | Prove | Test, log, screenshot e benchmark | Registro verifiche | Aggiungi le ipotesi come quinta categoria solo se chiaramente indicate. Ogni ipotesi deve includere l’azione meno costosa per confermarla o scartarla. ## Mantieni un registro compatto Un buon registro entra in una schermata. Aggiornalo dopo i traguardi, non dopo ogni messaggio. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` Conserva percorsi, comandi e nomi degli errori esatti. Evita un diario della discussione. ## Crea checkpoint su stati verificati Un checkpoint deve seguire un risultato riproducibile: gruppo di test superato, piccola modifica confermata, risposta API verificata o decisione sostenuta da un caso. Registra i file non confermati prima di cambiare modello o comprimere. Non dichiarare che una funzione lavora solo perché il codice è stato scritto; collega l’affermazione a test, build o artefatto osservabile. | Affermazione | Prova necessaria | |---|---| | Parser supporta due chiamate | Caso con due ID correlati | | Nuovo tentativo sicuro | Test di idempotenza con disconnessione | | Refactoring preserva il comportamento | Suite vecchia e nuova superate | | UI corretta | Ispezione renderizzata alle dimensioni target | ## Recupera la fonte invece di ripetere la chat Quando un dettaglio conta, riapri file, schema o documento ufficiale attuale. Un vecchio estratto può descrivere codice già cambiato. Fornisci percorsi e termini di ricerca per ispezionare lo stato corrente. Il recupero deve restare mirato: interfaccia, implementazione, test fallito e log rilevante prima dell’intero repository. Così resta spazio per ragionare. ## Comprimi preservando decisioni e prove Una buona compressione rimuove ripetizioni ma conserva vincoli, decisioni difficili da annullare, alternative scartate e verifiche. Distingui `verified`, `observed`, `assumed` e `pending`. Non riassumere un esperimento fallito come design finale. Conserva il motivo del rifiuto se lo stesso approccio può riapparire. ## Limita l’output degli strumenti Log lunghi e file generati consumano attenzione. Richiedi intervalli, conteggi o righe corrispondenti; salva l’output completo come artefatto e restituisci un riassunto con percorso. Per gli errori conserva il primo stack utile, l’asserzione e i dati dell’ambiente, non centinaia di frame ripetuti. ## Riprendi con un rituale deterministico Dopo pausa, compressione o cambio di modello: * Leggi obiettivo e vincoli. * Controlla version control e modifiche recenti. * Apri i file citati nello stato attuale. * Ripeti l’ultima verifica rilevante. * Conferma che la prossima azione sia ancora valida. Questa routine intercetta riassunti obsoleti prima di nuove modifiche. ## Scegli i modelli senza dipendere dalla memoria Un gateway facilita il cambio, ma lo stato resta tua responsabilità. Atlas Cloud offre più protocolli su un URL di base; controlla la [matrice dei protocolli](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) e il [catalogo dei modelli](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) prima di spostare un agente attivo. Fornisci al sostituto registro, file rilevanti e una verifica recente. Non dipendere da ID specifici del provider senza aver confermato protocollo e comportamento. ## Conclusione Le sessioni lunghe mantengono contesto quando lo stato duraturo è compatto, supportato da prove e facile da ricaricare. Usa un registro di una schermata, checkpoint dopo modifiche verificate, fonte attuale invece della chat, output limitato e ripresa deterministica. Una finestra più grande aiuta, ma lo stato esterno disciplinato rende il lavoro recuperabile. ## FAQ ### Una finestra di contesto più grande basta per una lunga sessione? No. Più spazio ritarda la pressione, ma non garantisce che i vecchi vincoli restino visibili né che osservazioni obsolete vengano corrette. ### Cosa deve contenere il registro della sessione? Obiettivo, vincoli, piano attuale, file modificati, decisioni principali, verifiche, rischi aperti e la prossima azione esatta. ### Quando creare un checkpoint? Dopo un cambio significativo: test superato, fase completata, decisione di design o scoperta che modifica il piano. ### Devo incollare tutta la conversazione in un nuovo modello? Di solito no. Fornisci un checkpoint selezionato, file e log rilevanti e lascia che il nuovo modello controlli lo stato attuale. ### Come impedire che un riassunto conservi un vecchio errore? Separa fatti verificati e ipotesi, allega comandi o percorsi come prove e ritira le affermazioni contraddette da nuovi test. ### Qual è il modo più sicuro di riprendere? Ricarica il registro, controlla il version control, ripeti l’ultima verifica rilevante e parti dalla prossima azione registrata.