Opus 5 non è così male come dice internet

Opus 5 non è così male come dice internet. Dopo oltre cinque settimane di programmazione quotidiana, continuo a vedere la prosa difficile da leggere, l’ampliamento dell’ambito, le ipotesi sbagliate e le regressioni descritte dagli utenti. Ma se gli affido un piano preparato dopo una ricerca accurata, un’attività ben delimitata e controlli indipendenti, è un ottimo sviluppatore software.

Perché ho cambiato idea: separo il piano dall’implementazione

Il mio giudizio è migliorato quando ho smesso di chiedere a Opus di scoprire l’architettura e implementare una funzionalità ampia nello stesso contesto. Nella mia valutazione della settimana di lancio lo descrivevo come un ottimo esecutore, ma difficile da supervisionare. Cinque settimane di uso quotidiano hanno reso più chiara questa divisione e mi hanno dato più fiducia nel ruolo di implementazione.

Leggere centinaia di resoconti negativi ha influenzato il mio giudizio più di quanto mi aspettassi. Mi ha insegnato che cosa controllare, ma ha anche trasformato ogni frase scomoda e ogni modifica superflua nella conferma di un verdetto che credevo già deciso. La differenza è emersa quando ho separato le attività definite male da quelle basate su un piano. Opus faticava soprattutto quando chiedevo a un’unica conversazione di comprendere una funzionalità ampia, scegliere l’architettura, rispettare ogni vincolo, implementare l’intera modifica e spiegarla con chiarezza. Sono diversi lavori nascosti in un solo prompt.

Quando ho affidato a Opus l’implementazione dopo aver definito architettura e confini, ha prodotto un lavoro di qualità. Ha seguito il codice pertinente nel repository, gestito modifiche difficili e notato conseguenze che un modello meno attento avrebbe potuto trascurare. In un’attività ben delimitata, quell’attenzione mi ha aiutato perché Opus ha trovato i file, i test e i casi limite legati al comportamento richiesto.

Aver cambiato idea non cancella gli errori di Opus 5. Mi indica il ruolo in cui è più facile contenerli.

Quali problemi di Opus 5 sono reali e che cosa aiuta?

Tutti e cinque i gruppi di critiche sono credibili, ma non li considero altrettanto gravi. Il problema della prosa resta evidente nell’uso normale. Gli altri quattro diventano molto meno dannosi quando Opus riceve un piano basato sulla ricerca, un perimetro di implementazione ristretto e una vera fase di verifica.

Critica	Che cosa la riduce	Che cosa rimane
Prosa difficile da leggere	Limiti alle risposte e regole per un linguaggio semplice	Nel mio uso Opus resta meno chiaro di Fable
Ampliamento dell'ambito	Esclusioni esplicite e ambito ristretto ai file	Le istruzioni possono comunque essere ignorate
Presupposti falsi	Ricerca prima delle modifiche e domande esplicite	Chi revisiona deve verificare il presupposto
Regressioni o falso completamento	Criteri di accettazione, test e revisione del diff	I controlli scelti possono comunque essere incompleti
Perdita del piano	Piano salvato, attività più piccole e contesto più pulito	Ogni parte richiede comunque una revisione

Ogni cambiamento può ridurre il problema a cui corrisponde, ma nessuno mi permette di saltare una revisione indipendente.

1. Prosa difficile: i limiti aiutano, ma Fable resta più chiaro

È la critica che riconosco più facilmente. Opus sa mettere insieme parole corrette in una frase che richiede più di una lettura, soprattutto nelle spiegazioni, nei riepiloghi e nei file Markdown più lunghi. Gli utenti di Reddit hanno descritto la stessa combinazione di frasi lunghe, struttura debole e testi che tecnicamente hanno senso, ma sono estenuanti da decifrare. [5] [6]

Che cosa aiuta: la guida di Anthropic ai prompt per Opus 5 dice che, per impostazione predefinita, le risposte rivolte agli utenti e i report tendono a essere più lunghi, quindi consiglia limiti espliciti per entrambi. [1] Un output più breve e una richiesta diretta di usare un linguaggio semplice aiutano, ma nessuno dei due mi dà con costanza la chiarezza colloquiale che ottengo con Fable 5. La differenza conta in una conversazione di pianificazione. Conta molto meno quando il risultato che mi interessa è una modifica al codice verificata dai test.

2. Ambito troppo ampio: esclusioni esplicite delimitano l’attività

Opus presta un’attenzione insolita ai problemi vicini, alle possibili astrazioni, alle validazioni mancanti e ai modi per rendere più completa una piccola modifica. Durante un audit può essere utile. In una correzione ben delimitata, invece, può trasformare una richiesta in un refactoring o creare un intero flusso di lavoro attorno a un controllo che avrebbe richiesto un solo comando. Anthropic avverte esplicitamente che Opus 5 può ampliare l’ambito di un’attività, verificare il proprio lavoro più del necessario e delegare con troppa facilità. [1]

Che cosa aiuta: descrivo ciò che non fa parte dell’obiettivo con la stessa chiarezza riservata all’obiettivo stesso. I problemi non correlati vanno segnalati, non corretti, e l’architettura esistente rimane invariata a meno che i criteri di accettazione non richiedano una modifica. Un autore su Reddit ha ottenuto un miglioramento simile dopo aver sostituito le vecchie istruzioni, che imponevano correzioni immediate, con una regola che chiedeva di segnalare i problemi estranei e lasciare all’utente la decisione sull’ambito. [7] Il resoconto mostra che la configurazione può cambiare il comportamento. Non significa che ogni errore sia colpa dell’utente.

3. Presupposti falsi: la ricerca fa emergere prima le ipotesi

Il resoconto più chiaro della raccolta su Reddit descrive Opus mentre inventa un ticket Linear, per poi citarlo nei commenti al codice, nei test e nei messaggi di commit. [8] Non ho osservato esattamente lo stesso errore, ma riconosco il rischio di fondo: una volta scelta un’interpretazione, Opus può produrre molto lavoro tecnicamente competente prima di fermarsi a mettere in dubbio il presupposto iniziale.

Che cosa aiuta: una fase di ricerca separata rende visibili le ipotesi prima che il codice cominci a dipendere da esse. Bisogna comunque dire chiaramente al modello di fare domande quando un dato mancante cambia il progetto. Chi esegue la revisione deve poi verificare che l’implementazione risponda alla richiesta originale, non a una richiesta simile ma diversa.

4. Regressioni: verifica il lavoro fuori da Opus

Diversi resoconti descrivono una correzione che introduce una regressione, seguita da un’altra correzione che riapre il bug iniziale. Una discussione su Reddit riassume il comportamento così: risolve il bug A, lo rompe mentre corregge il bug B e poi torna a risolvere A. [9] Sono testimonianze aneddotiche senza repository che io possa ispezionare, ma descrivono un problema tipico degli agenti: ogni correzione locale sembra utile mentre l’insieme dei criteri di accettazione si allontana sempre di più.

Che cosa aiuta: non accetto la dichiarazione del modello secondo cui l’attività è conclusa. A stabilire il completamento sono i controlli concordati: i test pertinenti, la build, una revisione mirata del diff e tutte le verifiche manuali richieste dalla funzionalità. La pianificazione aiuta Opus a scegliere il lavoro da svolgere. La verifica stabilisce se lo ha finito.

5. Perdita del piano: separa la ricerca dall’implementazione

Una funzionalità ampia concentra ricerca, architettura, implementazione, debug e revisione in un contesto che continua a crescere. Opus può consumare la parte utile di quel contesto durante l’esplorazione e poi implementare le decisioni basandosi su un ricordo parziale o compresso. Un resoconto ambivalente su Reddit è istruttivo: l’autore trovava Opus frustrante in un grande repository già esistente, ma ha dichiarato che il modello aveva costruito una nuova estensione per Chrome in una sola sessione, creato 17 commit e superato una revisione di Codex. [10] Il resoconto non permette di isolare la causa, ma mostra che lo stesso utente ha ottenuto risultati molto migliori su un progetto nuovo con meno contesto ereditato.

Che cosa aiuta: la guida di Anthropic a Claude Code spiega che le prestazioni possono calare man mano che la finestra di contesto si riempie, con il rischio di ignorare istruzioni e commettere più errori. Per le modifiche incerte o che riguardano più file, consiglia di separare ricerca e pianificazione dall’implementazione. [2] Il consiglio vale per ogni modello di sviluppo che uso. Con Opus, il costo di ignorarlo diventa soltanto più evidente.

Che cosa dimostrano davvero 1.008 estratti negativi su Opus 5?

La raccolta mostra che cinque tipi di critica compaiono più volte, quindi è utile per decidere da quali rischi proteggersi. Serve a riconoscere i problemi ricorrenti, non a misurare la soddisfazione o classificare i modelli.

Ho raccolto 1.008 estratti datati tra il 23 luglio e il 29 agosto 2026. Provengono da 229 post e 779 commenti, distribuiti in 294 discussioni distinte su Reddit. Un commento e il post a cui risponde non sono test indipendenti, e alcune discussioni molto attive hanno fornito numerose voci. Uno dei timestamp precede di un giorno l’annuncio pubblico di Anthropic del 24 luglio, perciò considero le date metadati di Reddit e non prove di un accesso anticipato. [14]

estratti negativi

1008

discussioni distinte

294

post

229

commenti

779

Un confronto corretto della popolarità richiederebbe campioni equivalenti per Fable, Sol, le versioni precedenti di Opus e altri modelli, corretti in base al numero di utenti e all’attività dei subreddit. Non ho questi campioni. Ho invece una raccolta dettagliata dei problemi descritti più volte dopo una sessione andata male con Opus 5.

Ho raggruppato gli estratti in base all’errore descritto, senza contare ogni etichetta libera come un problema a sé. Sono così emersi i cinque gruppi indicati sopra. Il mancato rispetto delle istruzioni e il consumo di token comparivano di solito all’interno di quei problemi, non come risultati separati. Da questi gruppi ho ricavato l’elenco pratico dei controlli che cercavo.

Che cosa possono correggere davvero istruzioni migliori per Opus 5?

Istruzioni migliori possono ridurre la verbosità, le verifiche superflue, l’eccesso di delega e l’ampliamento dell’ambito. Non garantiscono però che Opus segua il piano, ragioni correttamente, scriva bene o dichiari concluso il lavoro solo quando lo è davvero. Il vero miglioramento non è un prompt brillante, ma regole chiare per l’attività, affiancate da un processo e da verifiche.

Nel mio lavoro, quattro dettagli fanno la differenza maggiore. Indico il risultato richiesto, specifico ciò che non deve cambiare, segnalo l’architettura esistente da seguire e definisco le prove necessarie per considerare il lavoro completato. Quando la funzionalità è ampia, questi dettagli derivano dalla ricerca e da un piano architetturale, non da una versione più lunga della mia idea iniziale.

Le istruzioni persistenti sono utili per le regole che valgono in ogni attività. Claude Code carica CLAUDE.md come contesto del progetto, quindi è un posto ragionevole per specificare che i problemi non correlati vanno solo segnalati, che vanno riutilizzati i pattern già adottati e che il completamento richiede l’output effettivo dei test o della build. Anthropic avverte che il file costituisce contesto, non una configurazione applicata in modo vincolante, e che istruzioni brevi e specifiche funzionano meglio di una raccolta lunga di regole sovrapposte. [3]

Il limite conta perché anche gli utenti più attenti segnalano errori. Una discussione verificata su Reddit descrive un CLAUDE.md conciso che è stato ignorato. [12] Istruzioni migliori cambiano le probabilità, ma non trasferiscono all’utente la responsabilità per un errore del modello.

Per la stessa ragione, non direi a un utente frustrato di imparare a scrivere prompt per poi fermarmi lì. I resoconti positivi più convincenti hanno cambiato il flusso di lavoro attorno a Opus. Un utente di Reddit ha spostato requisiti e revisione su Fable, per poi affidare a Opus una specifica completa; gran parte del comportamento indesiderato è scomparsa. [11] Oggi gestisco le modifiche ampie separando i ruoli nello stesso modo.

Come uso Opus 5 per le funzionalità ampie

Mantengo una conversazione principale responsabile del risultato e dell’architettura. Questa conversazione studia il repository, chiede ad agenti mirati di cercare le informazioni mancanti, sceglie la soluzione e scrive un piano che comprende sistemi interessati, elementi esclusi, rischi e criteri di accettazione. Solo a quel punto l’implementazione passa agli agenti Opus, divisa in parti ben delimitate.

Gli agenti non ricevono un’istruzione vaga come “sviluppa la funzionalità”. Ognuno riceve la sezione pertinente del piano, i file o i sistemi compresi nell’ambito, il comportamento da conservare, i controlli da eseguire e un punto in cui fermarsi. La documentazione di Anthropic sui subagenti spiega che ogni agente lavora nel proprio contesto e restituisce un riepilogo alla conversazione principale. Questo protegge il contesto principale, ma significa anche che il messaggio di delega deve contenere i fatti che l’esecutore non può dedurre. [4]

Preferisco Fable 5 per la conversazione principale perché, nei miei progetti, comunica con maggiore chiarezza e conserva una visione architetturale migliore. Opus si occupa poi di gran parte dell’implementazione. È una mia preferenza, non una classifica generale, ed è possibile anche perché pago il piano Max 20x. Anthropic indica un prezzo di 200 dollari al mese e una capacità per sessione pari a 20 volte quella del piano Pro. [13] Un flusso di lavoro che usa un modello premium per la pianificazione e diversi agenti Opus per l’esecuzione non è accessibile allo stesso modo a tutti gli abbonati.

La stessa separazione aiuta anche se Opus è l’unico modello a tua disposizione. In quel caso, separo le fasi in conversazioni diverse invece di affidarle a modelli diversi.

Come usare Opus 5 da solo?

Usa Opus per l’intero processo, ma non chiedergli di svolgerlo tutto in un’unica sessione ininterrotta. Separa la pianificazione dalle modifiche, conserva il piano concordato, implementa una parte revisionabile alla volta e riparti da un contesto più pulito quando cambia il tipo di lavoro.

Per una funzionalità dall’approccio incerto, inizia in plan mode e chiedi a Opus di esaminare il repository senza modificarlo. Il piano deve indicare i file e i sistemi interessati, spiegare l’approccio scelto, annotare le questioni irrisolte e definire come verrà controllata ogni parte. Rivedi il documento prima dell’implementazione. Anthropic consiglia di separare ricerca e pianificazione dall’implementazione quando l’approccio non è chiaro o la modifica riguarda più file, pur precisando che una correzione piccola ed evidente potrebbe non richiedere un passaggio di pianificazione aggiuntivo. [2]

Poi assegna alla conversazione di implementazione soltanto il primo blocco di lavoro completo. Deve essere possibile revisionarlo e verificarlo senza aspettare l’intera funzionalità. Se una funzionalità richiede settimane di lavoro a uno sviluppatore, dividila in parti verificabili in modo indipendente. Segui le dipendenze e ciò che puoi verificare separatamente, non un numero arbitrario di prompt.

Conserva il piano fuori dalla conversazione, in modo che sopravviva a un reset del contesto. Usa /clear tra attività non correlate e invia la ricerca sul repository ai subagenti solo quando è abbastanza estesa da giustificare un contesto separato. Opus 5 tende già a delegare, quindi aggiungere agenti non migliora automaticamente il risultato. [1] L’obiettivo è mantenere il contesto principale concentrato sul compito, non avviare più agenti possibile.

Infine, controlla le prove invece di fidarti del tono sicuro del messaggio finale. Leggi il diff, esegui i controlli pertinenti e confronta il risultato con i criteri di accettazione salvati. Se una parte è sbagliata, correggila e verificala prima di aggiungere la successiva. In questo modo, un errore locale non si trasforma nella riscrittura dell’intera funzionalità.

Che cosa continua a sbagliare Opus 5

Alcuni problemi di Opus 5 rimangono anche con un buon flusso di lavoro. Nella mia esperienza, la sua prosa resta più difficile da leggere rispetto a quella di Fable, richiede ancora più supervisione di quanta ne vorrei e i confini espliciti non garantiscono che li rispetti.

Opus 5 fa ormai parte del mio normale flusso di implementazione. Non è il modello che preferisco per la conversazione architetturale principale e non lo sceglierei per scrivere un articolo senza un accurato passaggio di editing. Anche un’implementazione presentata con sicurezza può basarsi su un presupposto errato, quindi mantengo il piano e la revisione finale fuori dal contesto dell’agente esecutore.

Le critiche su Reddit mi hanno aiutato a individuare gli errori ricorrenti, ma non hanno stabilito se Opus potesse funzionare per me. Nella settimana del lancio ho commesso l’errore di considerare la qualità della supervisione e quella dell’implementazione come se fossero la stessa cosa. Non mi fido ancora di Opus per supervisionare una modifica ampia, ma quando Fable gestisce il piano e la revisione, spesso mi fido di Opus per scrivere il codice.