Claude Opus 5.5 in Claude Code: run lunghe, regole di stop, subagenti

Con Claude Opus 5.5 il lavoro in Claude Code cambia di natura: il modello porta avanti compiti lunghi, in più passaggi, con poca supervisione — Anthropic parla di run di ore con supervisione minima nei test dei primi utilizzatori. Il tuo lavoro non è più guidarlo un passo alla volta: è scrivere le regole dentro cui può andare avanti da solo, e leggere bene il risultato quando torna.

Questa guida traduce i consigli della guida ufficiale del lancio in tre cose concrete: cosa scrivere in CLAUDE.md, come usare una checklist su file, come dividere il lavoro fra subagenti. Dati verificati il 23 settembre 2026.

La regola di stop in CLAUDE.md

È il pezzo che decide tutto. Senza, il modello si ferma a chiederti conferma a ogni passo e il vantaggio delle run lunghe sparisce. Con una regola troppo larga, fa cose che non vuoi. La formulazione consigliata da Anthropic, tradotta:

"Quando un passo non richiede il mio intervento, continua. Metti le note di stato nello stesso messaggio della prossima azione. Fermati e chiedi solo quando non puoi continuare senza di me, o prima di qualcosa di distruttivo: cancellare dati, forzare un push, o modificare qualcosa fuori da questo repository."

Tre dettagli che contano:

1. "Note di stato nello stesso messaggio della prossima azione": così il modello non si ferma per raccontarti cosa ha fatto. Racconta e prosegue.
2. L'elenco esplicito delle azioni distruttive: cancellare, forzare, uscire dal repository. Non "fai attenzione", ma i casi precisi.
3. I permessi restano attivi. La guida è chiara: tieni le richieste di permesso sulle azioni distruttive. La regola dice al modello quando chiedere, non gli dà carta bianca.

Se invece stai facendo pair programming — lavori insieme, passo per passo — la regola è l'opposto: chiedi un piano di una riga prima di iniziare e un riepilogo breve alla fine. Le due modalità non convivono nello stesso file: scegli in base a come lavori quel giorno.

Il compito intero, con la linea di arrivo

Vale quanto in chat, ma in Claude Code pesa di più perché il modello agisce su file veri. L'esempio ufficiale:

"Migra gli endpoint dei pagamenti dal vecchio client al nuovo. Finito vuol dire: ogni endpoint usa il nuovo client, il vecchio client è cancellato, e la suite di test passa. Fermati e chiedimi qualcosa solo se un test fallisce per un motivo che non riesci a spiegare."

Puoi aggiungere istruzioni in corsa — "tieni anche i vecchi nomi come alias" — senza far ripartire la run. E vanno tolte dai prompt tutte le righe sul ragionamento: Opus 5.5 pensa sempre prima di agire. Il dettaglio è in prompt per Claude Opus 5.5.

La checklist in TASKS.md

Nelle run lunghe il contesto viene riassunto, e quello che stava solo in memoria si perde. La soluzione della guida è una checklist su file:

"Tieni una checklist in TASKS.md. Spunta ogni voce quando è fatta, e aggiungi tutto quello che trovi di nuovo."

Il file sopravvive al riassunto, e a fine run è anche il resoconto: cosa era previsto, cosa è stato fatto, cosa è emerso. Per i lavori che attraversano più sessioni è l'unica memoria affidabile.

Subagenti per i lavori grandi

Per audit, migrazioni e revisioni su codebase grandi, un modello solo non basta: il contesto si riempie. La guida propone di dividere il lavoro fra subagenti, ciascuno con la sua parte, e di far verificare le prove al modello principale. L'esempio ufficiale, tradotto:

"Controlla ogni servizio in services/ per il bug sui retry descritto nell'issue collegata. Assegna ogni servizio a un suo subagente. Quando un subagente riporta, verifica le sue prove prima di accettarle. Chiudi con una sola tabella: servizio, affetto sì o no, e la prova."

Il costo di una run con subagenti è più alto di una run semplice: usali quando il lavoro è davvero grande, non per abitudine. E ricorda che Opus 5.5 costa il 40% in meno di Opus 5 in esercizio, come spiegato in Claude Opus 5.5: cos'è: i conti di sei mesi fa vanno rifatti.

Leggere il risultato: prima i blocchi

Quando una run lunga finisce, la tentazione è leggere dall'inizio. La guida dice l'opposto: cerca prima le cose per cui Claude ti sta aspettando — decisioni aperte, approvazioni richieste. Per renderlo sistematico, in CLAUDE.md:

"Chiudi ogni run con tre titoli: Bloccato su di me, Cambiato, Trovato."

Il primo titolo è quello che sblocca il lavoro. Il secondo è il diff spiegato. Il terzo è quello che il modello ha notato strada facendo e che non era nel compito: spesso è la parte più preziosa.

Per la revisione del codice prima del merge — con il prompt esatto e il dato sorprendente sul livello di sforzo — vedi revisione del codice con Opus 5.5.

Fast mode e messaggi segnalati

Due cose specifiche di Claude Code da conoscere.

Fast mode (/fast): stesso modello, testo che arriva prima, costo per token più alto, richiede l'utilizzo extra abilitato, in anteprima. Serve per il lavoro a botta e risposta, non per le run lunghe dove nessuno aspetta davanti allo schermo. Quando conviene davvero è in Fast mode di Opus 5.5.

Messaggi segnalati: Opus 5.5 ha filtri più severi, e quando un messaggio viene segnalato Claude Code passa a un modello precedente con un avviso. /model riporta indietro, Esc due volte modifica il messaggio, /config gestisce il cambio automatico, /feedback segnala i falsi positivi. La guida completa è in Claude è passato a un modello precedente.

Esempi pratici

Software house, 12 sviluppatori, Padova. Migrazione di un servizio da una libreria HTTP a un'altra, 40 endpoint. Prima: una sessione per endpoint, con conferma a ogni file. Con Opus 5.5 e la regola di stop in CLAUDE.md: un compito solo, "finito vuol dire: ogni endpoint usa il nuovo client, il vecchio è rimosso, i test passano", TASKS.md per la checklist. Il modello si è fermato due volte: entrambe su test che fallivano per motivi che non sapeva spiegare — esattamente la regola.

Team di due persone, agenzia web, Firenze. Audit di sicurezza su 9 siti con lo stesso plugin. Un subagente per sito, tabella finale con sito, vulnerabile sì/no, prova. Tre siti risultati vulnerabili; le prove erano i file e le righe, verificabili a mano in dieci minuti. Senza la colonna "prova" sarebbe stato un elenco di opinioni.

Errori da evitare

• Togliere i permessi sulle azioni distruttive per "andare più veloce". La regola di stop serve a chiedere, non a saltare.
• Dare il primo passo invece del compito intero. Il modello si ferma a ogni bivio.
• Definire "finito" in modo non verificabile. "Quando funziona" non è una linea di arrivo; "i test passano" sì.
• Tenere la checklist solo in chat. Il riassunto del contesto la cancella.
• Accettare i risultati dei subagenti senza prove. Il principale deve verificare.
• Usare Fast mode sulle run lunghe. Costa di più e nessuno sta guardando.

Come applicarlo in azienda

Per un team che adotta Opus 5.5 in Claude Code, quattro file e regole condivise:

1. CLAUDE.md con la regola di stop e l'elenco esplicito delle azioni distruttive del vostro contesto: quali cartelle, quali comandi, quali branch.
2. I tre titoli di fine run, così ogni sviluppatore legge i risultati nello stesso modo.
3. TASKS.md per ogni lavoro che dura più di una sessione.
4. Un prompt condiviso per la revisione pre-merge, da usare prima di ogni pull request.

Se il team lavora anche con altri strumenti, il confronto è in Claude per il codice.

Conclusione

Opus 5.5 in Claude Code non è "più veloce a scrivere codice": è capace di andare avanti da solo dentro regole che scrivi tu. La differenza fra una run che finisce il lavoro e una che ti interrompe venti volte sta in tre file: la regola di stop, la checklist, il formato del resoconto. Il modello fa la sua parte se tu hai fatto la tua.

Se vuoi passare dai test con ChatGPT a un sistema AI integrato nei processi aziendali, Giallo Studio progetta agenti e automazioni su misura.