Il codice sorgente di Claude Code conferma il problema: Anthropic usa prompt interni diversi per i suoi ingegneri

Qualcuno in Anthropic ha fatto un errore. La scorsa notte è stata pubblicata una build con .npmignore configurato male, e il codice TypeScript che costruisce i system prompt di Claude Code è finito nel pacchetto npm pubblico. Ora possiamo vedere esattamente cosa succede dietro le quinte.

E conferma quello che sospettavamo: gli ingegneri interni di Anthropic usano una versione materialmente diversa dello stesso tool che vendono a noi.

Il flag nascosto

Nel codice c’è un check: process.env.USER_TYPE === 'ant'. Questo flag viene risolto a compile-time, il che significa che la versione che scarichi tu non può fisicamente raggiungere i percorsi di codice interni. Non è una configurazione runtime. Sono letteralmente due prodotti diversi compilati dallo stesso albero sorgente.

Cosa cambia tra le due versioni

Ogni differenza qui sotto è controllata da quel flag. Vediamo cosa ottieni tu vs cosa ottengono loro:

Output e ragionamento

Versione esterna (quella che paghi):

  • “IMPORTANTE: Vai dritto al punto. Prova l’approccio più semplice senza girarti intorno. Non esagerare. Sii estremamente conciso.”
  • “Mantieni il tuo output testuale breve e diretto. Inizia con la risposta o l’azione, non con il ragionamento.”
  • “Se puoi dirlo in una frase, non usarne tre.”

Versione interna (quella degli ingegneri Anthropic):

  • “Prima della tua prima chiamata a tool, dichiara brevemente cosa stai per fare.”
  • “Sbaglia verso più spiegazione.”
  • “Ciò che conta di più è che il lettore capisca il tuo output senza overhead mentale o domande successive, non quanto sei conciso.”
  • “Scrivi testo user-facing in prosa fluida evitando frammenti.”

Stesso modello. Stessi pesi. Istruzioni opposte.

Tono

La versione esterna include: “Le tue risposte dovrebbero essere brevi e concise.”

Nella versione interna questa riga è completamente rimossa — settata a null quando il flag è attivo.

Collaborazione vs esecuzione

Gli utenti esterni non ottengono questa direttiva. Quelli interni sì:

“Se noti che la richiesta dell’utente è basata su un equivoco, o individui un bug adiacente a quello che hanno chiesto, dillo. Sei un collaboratore, non solo un esecutore — gli utenti beneficiano del tuo giudizio, non solo della tua compliance.”

Il commento inline nel codice la etichetta come “capy v8 assertiveness counterweight” con la nota: “un-gate once validated on external via A/B”. Sanno che migliora il comportamento. Stanno scegliendo di trattenerlo in attesa di sperimentazione.

Disciplina sui commenti

Gli utenti interni ottengono guidance dettagliata su quando scrivere commenti al codice (solo quando il PERCHÉ non è ovvio), quando non farlo (non spiegare COSA fa il codice), e quando preservare commenti esistenti. Gli utenti esterni non ottengono niente di tutto questo.

Cosa significa tutto questo

Ogni una di queste feature ha un commento interno tipo “un-gate once validated on external via A/B.” Questo ci dice che:

  • Anthropic sa che sono miglioramenti
  • Li stanno usando attivamente internamente
  • Li stanno trattenendo dai clienti paganti mentre conducono esperimenti

L’A/B testing prima di un rollout generale è standard. Ma nel contesto — dove gli utenti paganti stanno segnalando da mesi che Claude Code si sente rotto, che si affretta attraverso i task, che dichiara successo quando le cose stanno fallendo, che non spiega il suo ragionamento — il quadro sembra diverso.

I fix esistono. Sono nel codice sorgente. Hanno solo un flag davanti che tu non puoi raggiungere.

Confronto fianco a fianco

AreaVersione esternaVersione interna (ant)
Output framing“Vai dritto al punto. Sii estremamente conciso.”“Ciò che conta è che il lettore capisca senza overhead mentale.”
Ragionamento“Inizia con la risposta, non con il ragionamento.”“Prima del tool call, dichiara cosa stai per fare.”
Spiegazione“Se puoi dirlo in una frase, non usarne tre.”“Sbaglia verso più spiegazione.”
Tono“Risposte brevi e concise.”(riga rimossa)
Collaborazione(non presente)“Sei un collaboratore, non solo un esecutore.”
Verifica(non presente)“Prima di dichiarare un task completo, verifica che funzioni.”

Lo stesso modello, gli stessi pesi, la stessa context window. Istruzioni diverse su se pensare prima di agire.