Anthropic Claude ha ridotto dell'80% il system prompt di Claude Code, sfidando il paradigma delle regole in più

Anthropic Claude ha rimosso oltre l'80% del system prompt di Claude Code per i suoi modelli più recenti, senza riportare perdite misurabili nelle valutazioni interne sul coding. La modifica del 24 luglio riguarda modelli avanzati, tra cui Claude Opus 5 e Claude Fable 5. Ribalta un assunto noto sugli agenti AI: istruzioni più dettagliate non producono sempre comportamenti più affidabili.

Anthropic afferma che le versioni precedenti di Claude Code necessitavano di regole esplicite per evitare commenti scadenti, documenti indesiderati e operazioni sui file non sicure. Queste protezioni si sono accumulate nel system prompt, nelle istruzioni di progetto, nelle skill, nelle descrizioni degli strumenti, nella memoria e nelle singole richieste degli utenti. Il contesto risultante poteva contenere direttive duplicate o contraddittorie.

Il context engineering di Claude 5 parte ora da una premessa diversa. Anthropic vuole che i team lascino spazio al giudizio dei modelli capaci, progettino interfacce più chiare e carichino istruzioni specialistiche solo quando servono. La sfida principale non è più Anthropic contro un altro fornitore di modelli. È il prompting prescrittivo contro il contesto selettivo.

Questa distinzione conta anche oltre Claude Code. Gli sviluppatori stanno creando agenti che leggono repository, chiamano strumenti, modificano file, revisionano codice e mantengono lo stato durante sessioni lunghe. Ogni istruzione permanente compete per l'attenzione con l'attività, i file correnti, i risultati degli strumenti e l'intento dell'utente.

Le prove dell'azienda restano tuttavia limitate. Anthropic non ha pubblicato la suite di valutazione, i punteggi di riferimento, la distribuzione delle attività o i risultati modello per modello alla base della sua affermazione di “nessuna perdita misurabile”. La riduzione dell'80% è significativa, ma la sua portata pratica necessita ancora di test indipendenti.

Anthropic Claude ha rimosso regole che un tempo sembravano essenziali

Il cambiamento immediato non è una finestra di contesto più ampia. È uno strato di istruzioni permanenti molto più piccolo.

Anthropic descrive il context engineering come l'assemblaggio di tutto ciò che un modello riceve oltre al prompt immediato dell'utente. Questo materiale include istruzioni di sistema, file di progetto, skill, memoria, definizioni degli strumenti, cronologia della conversazione e riferimenti recuperati.

Un system prompt è l'insieme iniziale di istruzioni che guida un agente durante una conversazione. Può definire comportamento, uso degli strumenti, stile delle risposte, confini di sicurezza e assunzioni sull'ambiente operativo.

Secondo le linee guida di Anthropic sul context engineering, l'azienda ha eliminato oltre l'80% del system prompt di Claude Code per Opus 5 e Fable 5. Afferma che le valutazioni sul coding non hanno mostrato perdite misurabili in seguito.

L'annuncio non afferma che le istruzioni siano diventate superflue. Distingue invece tra regole permanenti e informazioni che appartengono altrove. Confini di sicurezza, autorizzazioni, contratti degli strumenti e requisiti espliciti dell'utente richiedono ancora una rappresentazione chiara.

Ciò che è cambiato è la collocazione predefinita di tali indicazioni. Anthropic in precedenza inseriva nel prompt principale comportamenti dettagliati per coding, revisione, documentazione e verifica. Queste istruzioni accompagnavano il modello anche quando una determinata attività non ne aveva bisogno.

Alcune vecchie regole cercavano anche di controllare modalità di errore ristrette. Anthropic cita una precedente istruzione che diceva a Claude di evitare docstring e documenti di pianificazione su più paragrafi, salvo richiesta. La regola riduceva l'output indesiderato, ma scoraggiava anche una documentazione utile nel codice complesso.

La sostituzione è più breve e più contestuale. Claude dovrebbe adeguarsi alla densità dei commenti, alle convenzioni di naming e allo stile idiomatico del codice circostante. Invece di prescrivere un unico modello di output universale, l'istruzione indica al modello dove trovare lo standard pertinente.

Questo cambiamento crea la tensione centrale dell'articolo. Una regola dettagliata può sembrare più sicura perché il suo comportamento è visibile e verificabile. Eppure ogni istruzione rigida può rivelarsi errata quando il repository, la richiesta dell'utente o l'attività richiedono un'eccezione.

Claude Code riceve inoltre istruzioni attraverso vari canali sovrapposti. Un utente potrebbe richiedere documentazione appropriata mentre una regola globale scoraggia i commenti. Una skill potrebbe imporre la verifica, mentre un altro file dice all'agente di ridurre al minimo il lavoro aggiuntivo.

Il modello deve risolvere questi conflitti prima di poter affrontare il problema ingegneristico effettivo. Più testo crea quindi un ulteriore compito di ragionamento, anziché aggiungere semplicemente conoscenza utile.

Anthropic ha aggiunto una risposta diagnostica a questo problema. L'azienda afferma che il comando /doctor può aiutare gli utenti a dimensionare correttamente le proprie skill e i file CLAUDE.md. Questi file forniscono contesto persistente del progetto, comprese le convenzioni del repository e le istruzioni ricorrenti.

Il messaggio pratico è più circoscritto di “eliminate i vostri prompt”. I team dovrebbero identificare quali informazioni si applicano davvero a ogni richiesta. Tutto il resto necessita di un'attivazione, una collocazione o un meccanismo di distribuzione più preciso.

Perché il context engineering di Claude 5 privilegia il contesto selettivo

Anthropic scommette che un migliore giudizio del modello riduca il valore della micromanagement comportamentale permanente.

Il vecchio approccio è nato per una ragione. I modelli di coding precedenti producevano spesso commenti eccessivi, creavano file di pianificazione non necessari, gestivano male gli strumenti o seguivano gli esempi troppo letteralmente. Istruzioni dettagliate restringevano i comportamenti disponibili.

Questa limitazione comportava un compromesso. Prevenire un errore comune poteva bloccare la risposta corretta a un'attività insolita. Un divieto di commenti lunghi poteva migliorare le modifiche di routine, ma danneggiare il lavoro su algoritmi complessi o codice sensibile alla sicurezza.

Il context engineering di Claude 5 avvicina questa decisione all'attività. Il modello riceve la richiesta dell'utente, esamina il codice vicino e applica le convenzioni locali. Anthropic definisce questo processo “unhobbling” Claude, perché il sistema rimuove vincoli che hanno superato il loro scopo originario.

La parola non va scambiata per autonomia senza restrizioni. Claude Code opera ancora all'interno di un harness, ovvero il software circostante che gestisce strumenti, autorizzazioni, contesto ed esecuzione. Anthropic sta semplificando uno strato all'interno di tale harness.

L'azienda illustra diversi cambiamenti “prima e ora”. Le regole lasciano il posto al giudizio. Gli esempi degli strumenti lasciano il posto a interfacce espressive. Le istruzioni iniziali lasciano il posto alla divulgazione progressiva. La ripetizione lascia il posto a descrizioni concise degli strumenti.

La divulgazione progressiva consiste nel caricare informazioni dettagliate quando l'attività le richiede, anziché inserire tutto nel contesto iniziale. Claude Code ora utilizza skill dedicate per aree quali la revisione del codice e la verifica.

Questo approccio preserva l'accesso senza imporre costi di attenzione costanti. Una procedura di revisione può restare dettagliata, ma Claude la carica quando esegue una revisione. Una modifica ordinaria a un file non deve portarsi dietro l'intera procedura.

Claude Code applica lo stesso principio agli strumenti. Alcuni strumenti utilizzano il caricamento differito, che inizialmente espone una descrizione leggera. Lo schema completo appare solo dopo che l'agente seleziona quello strumento tramite ricerca.

La guida alla finestra di contesto di Anthropic mostra perché la distinzione è importante. Istruzioni di progetto, memoria, descrizioni delle skill, file, risposte e contenuti runtime nascosti occupano tutti lo stesso contesto di lavoro.

Una grande capacità di contesto non elimina il problema della selezione. Un modello può accettare più token continuando a ricevere materiale irrilevante, obsoleto o contraddittorio. La capacità risponde a quanto può entrare, non a cosa merita attenzione.

Il contesto selettivo cambia anche il modo in cui i team dovrebbero organizzare la conoscenza del repository. Un singolo file CLAUDE.md non dovrebbe diventare un'enciclopedia di ogni preferenza ingegneristica. Anthropic raccomanda un albero di riferimenti che l'agente possa caricare quando opportuno.

Questo design ricorda una buona architettura software. Le interfacce stabili restano piccole, mentre il comportamento specializzato vive dietro confini espliciti. L'agente apprende ciò che esiste senza ricevere ogni dettaglio di implementazione all'avvio.

Le definizioni degli strumenti diventano particolarmente importanti in questo modello. Anthropic sostiene che gli esempi possano limitare l'esplorazione, indirizzando il modello verso schemi dimostrati in precedenza. Parametri chiari e definizioni dello stato possono comunicare l'intento senza prescrivere un unico percorso.

Il suo esempio Todo utilizza stati enumerati come in attesa, in corso e completato. Un vincolo che consente un solo elemento attivo descrive uno stato di sistema valido. Il modello può quindi scegliere le azioni all'interno di tale interfaccia.

Si tratta di un cambiamento significativo nel punto in cui risiede l'affidabilità degli agenti. Gli autori dei prompt cercavano un tempo di codificare l'affidabilità principalmente attraverso la prosa. Anthropic ora attribuisce maggiore responsabilità alla progettazione delle interfacce, al routing del contesto, alle autorizzazioni e al giudizio del modello.

La vera sfida è tra prompting prescrittivo e giudizio del modello

Il taglio dell'80% mette in discussione la convinzione che ogni errore osservato di un agente meriti un'altra istruzione permanente.

I team che lavorano sugli agenti AI spesso rispondono agli errori aggiungendo regole. Se un agente salta i test, il prompt acquisisce un requisito di testing. Se modifica file non correlati, un altro paragrafo restringe l'ambito. Se spiega troppo, segue una limitazione sulla verbosità.

Questo processo crea un meccanismo a cricchetto. Le istruzioni si accumulano perché le aggiunte sembrano più sicure delle eliminazioni. Pochi team verificano regolarmente se una vecchia regola migliori ancora modelli, strumenti e flussi di lavoro attuali.

Anthropic Claude sostiene ora che questo meccanismo possa abbassare la qualità. Il problema non è solo il consumo di token. Istruzioni in conflitto costringono il modello a dedurre le priorità, interpretare le eccezioni e conciliare protezioni obsolete con l'intento attuale dell'utente.

Il prompting prescrittivo resta attraente perché i team possono sottoporlo ad audit. Un revisore della sicurezza può individuare un divieto esplicito. Un product manager può indicare una regola di formattazione. Uno sviluppatore può riprodurre il testo incluso in una richiesta.

Il giudizio del modello offre flessibilità, ma è più difficile da prevedere. Consente a Claude di riconoscere che una funzione complessa necessita di documentazione nonostante una preferenza generale per commenti minimi. La stessa discrezionalità può produrre scelte incoerenti tra attività diverse.

La versione più forte della tesi di Anthropic dipende quindi dalla capacità del modello. Un modello meno capace potrebbe ancora necessitare di esempi dettagliati, avvertimenti ripetuti e regole ristrette. Un'implementazione con modelli misti non può presumere che ogni agente interpreti indicazioni concise con la stessa efficacia.

Questo crea pressione sui team che supportano più generazioni di modelli. Le istruzioni ottimizzate per Opus 5 o Fable 5 potrebbero specificare in modo insufficiente il comportamento per modelli più vecchi o più piccoli. I prompt scritti per modelli precedenti potrebbero vincolare eccessivamente quelli più recenti.

Il contesto versionato diventa un requisito operativo. I team devono sapere quali regole si applicano a ciascun modello, come sono cambiate le valutazioni e quando un'istruzione condivisa ha smesso di aggiungere valore. Altrimenti, la semplificazione diventa un'altra convenzione non testata.

Il cambiamento mette inoltre sotto pressione le aziende che vendono template di prompt come risorse durevoli. Un template lungo può codificare competenze utili, ma la lunghezza non è più un indicatore credibile di completezza. Il suo valore dipende da pertinenza, routing e risultati misurabili.

Gli sviluppatori che creano agenti personalizzati affrontano una decisione simile. La documentazione sui system prompt di Anthropic distingue tra il preset completo di Claude Code, un'impostazione predefinita minimale e istruzioni completamente personalizzate.

La configurazione completa è adatta agli agenti di coding con una persona che osserva e guida il lavoro. Un prompt personalizzato è più adatto ad agenti con identità, interfacce o modelli di autorizzazione diversi. Anthropic avverte che chi crea configurazioni personalizzate deve sostituire ogni indicazione di sicurezza rimossa.

Questo avvertimento mette in luce il confine del nuovo approccio. Eliminare il superfluo comportamentale non equivale a indebolire le autorizzazioni. Un agente conciso necessita comunque di limiti espliciti per operazioni distruttive, dati sensibili, comunicazioni esterne ed esecuzione non supervisionata.

I team dovrebbero classificare le istruzioni prima di eliminarle. Una preferenza di stile può spesso deferire alle convenzioni del repository. Un flusso di verifica può diventare una skill. Un confine di autorizzazione appartiene a un software applicabile, non soltanto a una frase cortese.

Questa divisione spinge il settore verso l'architettura del contesto. Il lavoro chiave diventa decidere cosa resta globale, cosa viene caricato per percorso, cosa si attiva per attività e cosa il software impone indipendentemente dal modello.

Per i gruppi di ingegneria, questa architettura diventa anche memoria organizzativa. Convenzioni del repository, decisioni e riferimenti tecnici richiedono una proprietà chiara e percorsi di recupero definiti. Una base di conoscenza ingegneristica ricercabile può aiutare i team a separare i fatti durevoli dalle istruzioni transitorie per gli agenti.

Il lato vincente della competizione non sarà costituito da “prompt brevi” in ogni caso. Sarà il sistema che fornisce il minimo contesto sufficiente preservando al contempo sicurezza, fedeltà al compito e prestazioni riproducibili.

I risultati del system prompt di Claude Code richiedono ancora test indipendenti

Il risultato di punta di Anthropic è rilevante, ma le prove pubbliche non dimostrano che ogni team possa rimuovere lo stesso 80%.

L'azienda afferma che la riduzione del system prompt di Claude Code non ha causato perdite misurabili nelle valutazioni di coding. Questa formulazione lascia senza risposta diverse domande importanti.

Anthropic non ha divulgato le attività di valutazione usate per questo confronto. I lettori non possono vedere se la suite abbia privilegiato generazione di codice, debugging, navigazione del repository, test, documentazione, uso degli strumenti o lavoro autonomo di lunga durata.

L'azienda non ha inoltre pubblicato punteggi di riferimento né intervalli di confidenza. “Nessuna perdita misurabile” può significare risultati identici, una differenza statisticamente non significativa o una variazione troppo piccola perché il benchmark scelto la rilevi.

L'affermazione riguarda la configurazione interna di Claude Code di Anthropic per modelli avanzati. Non dimostra che gli utenti possano eliminare l'80% dei propri file CLAUDE.md, delle skill o dei prompt personalizzati degli agenti senza conseguenze.

Questi file spesso contengono requisiti specifici dell'organizzazione. Gli esempi includono comandi di build, flussi di lavoro regolamentati, standard di revisione, policy sulle dipendenze, restrizioni di distribuzione e convenzioni che il modello di base non può dedurre dal codice circostante.

Un repository può anche contenere schemi incoerenti. Chiedere a Claude di adeguarsi al codice circostante funziona quando il contesto rappresenta lo standard desiderato. Può riprodurre debito tecnico quando convenzioni vecchie e nuove convivono.

La divulgazione progressiva introduce una propria modalità di fallimento. L'agente deve riconoscere quando è necessaria una skill o un riferimento specializzato. Se il routing fallisce, l'informazione corretta esiste ma non raggiunge mai il contesto attivo.

Gli strumenti caricati in modo differito creano una dipendenza simile. Descrizioni leggere risparmiano contesto iniziale, ma devono essere abbastanza specifiche perché l'agente scopra la capacità giusta. Uno strumento con un nome poco chiaro può diventare praticamente invisibile.

La compattazione complica ulteriormente il quadro. Claude Code riassume le conversazioni lunghe quando il contesto si riempie. La documentazione di Anthropic afferma che alcune istruzioni di progetto e la memoria vengono ricaricate successivamente, mentre le regole con ambito basato sul percorso possono attendere un'altra lettura di file corrispondente.

Le informazioni importanti possono quindi spostarsi tra livelli persistenti e transitori durante una singola sessione. I team che testano modifiche al contesto dovrebbero includere attività lunghe che attraversano i confini di compattazione, non soltanto prompt di coding isolati.

Anche il caching dei prompt influenza l'architettura. Riutilizza un prefisso stabile della richiesta per ridurre l'elaborazione ripetuta. Anthropic afferma che Claude Code mantiene prima il contenuto statico e poi i messaggi dinamici per preservare le corrispondenze della cache.

Le lezioni sul prompt caching dell'azienda avvertono che cambiare strumenti o modelli a metà sessione può invalidare i prefissi memorizzati nella cache. Il contesto selettivo deve quindi bilanciare rilevanza e stabilità.

La strategia di caricamento differito di Claude Code affronta parte di questa tensione. Stub leggeri degli strumenti possono rimanere stabili mentre gli schemi completi vengono caricati in seguito. L'approccio risparmia contesto senza modificare costantemente il set di strumenti di base.

Tuttavia, un system prompt più piccolo non garantisce automaticamente un minore utilizzo complessivo del contesto. Un agente potrebbe compensare leggendo più riferimenti, invocando più skill o impiegando turni aggiuntivi per individuare le istruzioni.

La riduzione del prompt non garantisce neppure un comportamento coerente. Rimuovere indicazioni ripetute potrebbe far emergere errori rari che le ampie valutazioni di coding non rilevano. I team operanti in contesti regolamentati o sensibili alla sicurezza dovrebbero testare i rischi di coda, non soltanto i punteggi medi delle attività.

La risposta appropriata è una valutazione controllata. I team possono confrontare configurazioni vecchie e ridotte su repository rappresentativi, attività fisse, esecuzioni ripetute e categorie di fallimento chiaramente definite.

Misure utili includono completamento delle attività, modifiche involontarie ai file, copertura dei test, rilievi della revisione, errori degli strumenti, correzioni degli utenti e consumo totale di contesto. I team dovrebbero anche registrare quali istruzioni l'agente ha effettivamente caricato.

L'onere della prova aumenta con l'autonomia. Uno sviluppatore che supervisiona ogni modifica può individuare rapidamente un errore di giudizio. Un agente non supervisionato che apre pull request o modifica sistemi di produzione richiede controlli più rigorosi e una valutazione più approfondita.

Il risultato di Anthropic è meglio considerato come prova dell'esistenza di debito nei prompt. Non è un obiettivo universale di eliminazione e l'azienda non ha validato in modo indipendente il risultato al di fuori dei propri modelli e harness.

Prompt più piccoli spostano maggiori responsabilità nell'architettura degli agenti

La semplificazione del contesto non elimina la complessità. La trasferisce nel routing, negli strumenti, nella memoria, nella valutazione e nelle autorizzazioni.

Questo trasferimento è la conseguenza commerciale più importante dell'annuncio. I team che consideravano i prompt come il prodotto dell'agente devono ora esaminare l'intero sistema che circonda il modello.

Un agente affidabile necessita di un modo per identificare la conoscenza pertinente. Necessita di strumenti con nomi chiari, parametri espressivi e stati vincolati. Necessita di memoria che separi le preferenze durevoli dai dettagli temporanei della sessione.

Necessita inoltre di un'esecuzione osservabile. Gli sviluppatori devono poter vedere quali file l'agente ha letto, quali skill ha invocato, quali strumenti ha selezionato e quali istruzioni hanno influenzato una decisione.

Il context engineering di Claude 5 rende queste capacità più preziose perché il prompt principale contiene meno procedure esplicite. Se il livello di routing fallisce, il modello dispone di meno indicazioni ridondanti come ripiego.

La funzionalità di memoria automatica di Anthropic illustra il cambiamento. Claude Code può salvare informazioni che considera rilevanti tra diverse attività. Questo riduce la pressione a usare CLAUDE.md come archivio di memoria mantenuto manualmente.

La memoria automatizzata introduce tuttavia questioni di governance. I team devono sapere cosa è stato memorizzato, se rimane accurato e come vengono risolte le memorie in conflitto. Un contesto obsoleto può fuorviare un agente anche quando il prompt principale è conciso.

I riferimenti ricchi creano un altro cambiamento architetturale. Anthropic afferma che Claude può lavorare con artefatti più complessi invece di affidarsi soltanto a semplici piani Markdown. Ciò amplia ciò che gli agenti possono ispezionare durante progettazione e implementazione.

Il beneficio dipende dalla reperibilità. Un artefatto dettagliato aiuta soltanto quando l'agente sa che esiste e comprende quando consultarlo. Gli alberi di riferimenti richiedono nomi informativi, indici concisi e punti di ingresso specifici per l'attività.

La progettazione degli strumenti diventa una forma di prompting. Un'enumerazione comunica gli stati validi. Un parametro obbligatorio segnala le informazioni necessarie. I confini di autorizzazione impediscono azioni non valide indipendentemente da come il modello interpreta la prosa.

Questo approccio dovrebbe attrarre gli acquirenti enterprise perché i controlli software sono più facili da applicare rispetto agli avvertimenti in linguaggio naturale. Un sistema di autorizzazioni può bloccare un'operazione. Un prompt può soltanto chiedere al modello di non eseguirla.

Tuttavia, la progettazione dell'interfaccia richiede più lavoro ingegneristico rispetto all'aggiunta di un altro paragrafo. I team devono modellare i flussi di lavoro, gestire gli errori degli strumenti, esporre lo stato e mantenere la compatibilità mentre modelli e prodotti cambiano.

La riduzione dell'80% potrebbe quindi ampliare il divario tra demo semplici e agenti di produzione. Una demo può apparire migliore con meno vincoli. Un sistema di produzione deve sostituire il comportamento del prompt rimosso con un'architettura più solida, dove necessario.

L'effetto raggiunge anche i knowledge worker che usano l'IA al di fuori dello sviluppo software. Gli agenti per ricerca, operazioni e analisi affrontano lo stesso problema di contesto. Documenti di istruzioni estesi spesso mescolano obiettivi, preferenze, materiale di riferimento e procedure una tantum.

Separare queste categorie può migliorare recupero e manutenzione. Identità stabile e regole di sicurezza restano globali. I riferimenti di dominio si caricano quando pertinenti. Le procedure delle attività diventano flussi di lavoro richiamabili. I fatti temporanei rimangono nella sessione attiva.

Ciò non significa che ogni flusso di lavoro necessiti di una piattaforma elaborata. Il principio può iniziare con un breve indice di progetto, file di riferimento con ambito ristretto e un set di test basato sul lavoro ricorrente.

La chiave è smettere di trattare il contesto come un blocco di testo indifferenziato. Ogni elemento dovrebbe avere un motivo per essere caricato, un ambito definito, un responsabile e un metodo per testarne il valore.

La mossa di Anthropic esercita inoltre pressione indiretta sui fornitori rivali di agenti di coding. Gli utenti confronteranno sempre più non soltanto i punteggi dei benchmark, ma anche il modo in cui ciascun prodotto gestisce istruzioni, memoria, strumenti, compattazione e visibilità del contesto.

Un modello con elevate capacità grezze può comunque offrire prestazioni inferiori all'interno di un harness ingombrante. Un modello più piccolo può rimanere utile quando i suoi strumenti e i confini delle attività sono ristretti. La competizione tra agenti sta diventando una competizione tra sistemi.

Il vantaggio emergente appartiene ai prodotti che rendono il contesto ispezionabile. Gli utenti devono capire cosa è entrato nel modello, cosa è rimasto nascosto, cosa è sopravvissuto alla compattazione e cosa è cambiato tra le esecuzioni.

Anthropic ha chiarito la propria direzione. Modelli migliori dovrebbero contenere meno regole comportamentali universali, mentre il sistema circostante fornisce informazioni precise nel momento in cui servono.

Cosa osservare dopo il taglio dell'80%

Tre segnali mostreranno se la strategia di Anthropic basata su prompt più piccoli diventerà una regola del settore o resterà un'ottimizzazione specifica di Claude.

Il primo segnale è la valutazione indipendente. Gli sviluppatori dovrebbero cercare confronti controllati tra il precedente e il ridotto system prompt di Claude Code su repository reali ed esecuzioni ripetute.

Prove solide includerebbero punteggi a livello di attività, distribuzioni anziché medie e categorie esplicite per sicurezza e modifiche involontarie. Risultati comparabili rafforzerebbero l'affermazione di Anthropic secondo cui molte regole permanenti sono diventate debito nei prompt.

Un aumento del comportamento incoerente la indebolirebbe. I fallimenti rari ma costosi contano, soprattutto quando gli agenti operano senza revisione umana continua. Gli studi più utili testeranno sessioni lunghe, scoperta degli strumenti e compattazione.

Il secondo segnale è il modo in cui altre generazioni di modelli gestiscono lo stesso contesto. L'annuncio di Anthropic nomina specificamente Opus 5 e Fable 5. I team devono verificare se modelli di classe Sonnet, più piccoli o meno recenti tollerino istruzioni altrettanto concise.

Se le configurazioni ridotte funzionano su tutti i modelli, il contesto selettivo diventa un modello generale di progettazione degli agenti. Se le prestazioni variano nettamente, i team avranno bisogno di prompt versionati e policy di routing per ogni famiglia di modelli.

Quel risultato complicherebbe i prodotti multi-modello. Cambiare provider o dimensione del modello richiederebbe più che modificare un identificatore API. Ogni modello potrebbe richiedere un equilibrio diverso tra giudizio, esempi, ripetizione e vincoli.

Il terzo segnale riguarda il comportamento del prodotto attorno a /doctor, skills, memoria e strumenti differiti. Anthropic afferma che /doctor può individuare istruzioni e skills di progetto eccessivamente lunghe. Le sue raccomandazioni riveleranno quanto aggressivamente l’azienda si aspetti che gli utenti semplifichino.

Osservate se Claude Code segnala quali regole sono in conflitto, quali file vengono attivati raramente e quali istruzioni duplicano comportamenti già integrati. Queste diagnosi trasformerebbero la pulizia dei prompt da un’attività soggettiva a una manutenzione misurabile.

Osservate anche se Anthropic pubblicherà dettagli di valutazione più completi. L’affermazione attuale non include la composizione dei task, i punteggi grezzi né confronti specifici tra modelli. Una maggiore trasparenza aiuterebbe i team a stabilire se il risultato sia trasferibile ai loro ambienti.

Per gli sviluppatori, l’azione immediata non consiste in una cancellazione indiscriminata dell’80%. Verificate le istruzioni in base allo scopo. Mantenete i limiti di sicurezza applicabili, rimuovete i duplicati evidenti e spostate le procedure specializzate dietro trigger chiari.

Poi testate la configurazione ridotta sul lavoro che il vostro team svolge davvero. Includete modifiche di routine, richieste ambigue, attività di revisione, convenzioni del repository, errori degli strumenti e sessioni lunghe. Misurate i tassi di correzione insieme al completamento.

Gli acquirenti enterprise dovrebbero chiedere ai fornitori come viene assemblato e ispezionato il contesto. Un’ampia finestra di contesto non basta. Servono controlli su ambito, memoria, autorizzazioni, recupero delle informazioni, compattazione e comportamento specifico del modello.

I knowledge worker dovrebbero applicare la stessa disciplina alle istruzioni AI persistenti. Mantenete concise le preferenze stabili. Archiviate il materiale di riferimento dove possa essere recuperato. Evitate di costringere ogni richiesta futura a portarsi dietro ogni lezione passata.

Il risultato di Anthropic su Claude è importante perché ridefinisce la sofisticazione. L’agente più avanzato potrebbe non avere il prompt più lungo. Potrebbe avere il sistema più chiaro per decidere di cosa il modello ha bisogno in quel momento.

I test indipendenti riprodurranno il risultato di Anthropic, o riveleranno task in cui le regole eliminate continuano a essere importanti? Nei prossimi mesi, la risposta dovrebbe orientare ogni seria verifica del contesto di Claude Code.