Lo stack Claude Code di un PHP senior nel 2026: i pacchetti che tratto come standard

Quando apro una sessione di Claude Code dentro una codebase PHP legacy da qualche centinaio di migliaia di righe, la prima tentazione, anche per chi lavora con questi strumenti tutto il giorno, è riempire la configurazione: un plugin per i test, uno per il database, tre MCP server per il browser, sei skill scaricate da un marketplace, una manciata di subagent trovati su GitHub. È la versione 2026 di quello che facevamo con le estensioni dell'IDE dieci anni fa, e ha lo stesso esito: un ambiente che sulla carta "fa tutto" e nella pratica è più lento, più confuso e meno prevedibile. La differenza è che qui il costo non è cosmetico. Ogni tool dichiarato, ogni descrizione di skill, ogni riga di istruzioni occupa la context window del modello, e quella finestra (oggi va dai 200.000 token di base al milione dei modelli di frontiera) non è attenzione uniforme: è un budget che si degrada man mano che si riempie, un fenomeno che la documentazione dei vendor chiama ormai apertamente context rot. Nella mia pipeline personale gestisco oltre cinquanta codebase con orchestrazione LLM, e il criterio con cui decido cosa installare non somiglia a "quante stelle ha su GitHub". Somiglia a come scelgo una dipendenza in composer.json: cosa risolve, quanto costa mantenerla, e cosa succede quando l'ambiente sotto cambia.

Questo è il mio inventario ragionato: i pacchetti di Claude Code che tratto come standard nel 2026, organizzati per il layer dell'harness a cui appartengono, con per ciascuno il criterio che mi fa dire sì e, soprattutto, i casi in cui la risposta onesta è no.

Cosa intendo per pacchetto, e perché il layer di appartenenza decide tutto

In Claude Code non esiste un solo tipo di estensione. Esistono almeno cinque layer, e confonderli è la prima causa di configurazioni gonfie: le regole in CLAUDE.md, gli hook, le skill, i plugin, gli MCP server, a cui si aggiungono il language server per i simboli e i subagent per la delega. Il team che sviluppa Claude Code è esplicito su un punto che la maggior parte dei tutorial salta, e lo mette nero su bianco nella guida ufficiale al lavoro sulle grandi codebase: l'ordine in cui costruisci questi layer conta, perché ognuno paga un prezzo diverso in context e offre una garanzia diversa. Una regola in CLAUDE.md è testo sempre presente; un hook è codice deterministico che gira fuori dal modello; una skill è conoscenza che viene caricata solo quando serve; un MCP server è una porta verso un sistema esterno. Trattarli come se fossero la stessa cosa, "roba da installare", è l'errore che porta dritto al context bloat.

Il modo in cui ragiono è banale ma rigoroso: prima di aggiungere qualcosa mi chiedo a quale layer appartiene e se quel layer è il posto giusto per il problema che ho. Una convenzione di progetto va in CLAUDE.md, non in una skill. Un divieto assoluto (non toccare i file .env) va in un hook, non in una frase gentile dentro il prompt, perché il modello una frase gentile la può ignorare e un hook no. La conoscenza specialistica che serve una volta su venti va in una skill con progressive disclosure, non incollata nel contesto di ogni sessione. Sbagliare layer non è un dettaglio stilistico: è la differenza tra un ambiente che resta leggibile e uno che affoga.

Le tre domande che mi pongo prima di installare qualsiasi cosa

Il criterio di selezione, quello che mi distingue da chi accumula, sta in tre domande secche. La prima: questo pacchetto si ripaga il costo in context che mi impone? Ogni tool registrato porta in finestra il suo nome, la sua descrizione e il suo schema; venti tool che uso una volta al mese mi costano attenzione su ogni singolo turno. La seconda: codifica conoscenza che il modello non ha già? Una skill che spiega a Claude come funziona git è inutile, lo sa meglio di me; una skill che incapsula la procedura interna di deploy di un mio cliente, con i suoi vincoli e le sue trappole, vale oro. La terza, la più trascurata: sopravvive a un cambio di modello?

Le istruzioni scritte per un modello diventano zavorra per il successivo. La stessa best practice ufficiale del team prescrive di rivedere la configurazione dell'agente ogni tre-sei mesi, perché un harness che non si pota invecchia più in fretta del codice che dovrebbe aiutarti a scrivere.

Chi installa per accumulo salta tutte e tre le domande. Chi lavora con questi strumenti in produzione le applica come applicherebbe una code review: con il pregiudizio che il default giusto sia "no, a meno che".

Layer uno: le regole in CLAUDE.md, il pacchetto a costo quasi zero

Il pacchetto più sottovalutato è anche il più economico. Un CLAUDE.md scritto bene è la leva con il miglior rapporto tra valore e costo in context di tutto l'ecosistema, perché sostituisce decine di correzioni ripetute con poche righe di convenzione. Il punto è che "scritto bene" ha un significato preciso: root snello, regole stratificate per sottodirectory (un CLAUDE.md locale nella cartella dei test che parla solo di test), zero prosa decorativa. È la stessa impostazione che descrivo nella mia guida al setup di Claude Code in produzione per uno sviluppatore PHP senior, dove i layer si costruiscono in ordine invece che ammucchiarsi. Su una codebase grande tengo le regole vicine al codice che governano, esattamente come tengo la documentazione di un modulo dentro il modulo.

Quando non serve: quando la regola è in realtà un divieto di sicurezza. "Non eseguire migrazioni distruttive" in CLAUDE.md è una buona intenzione che il modello, sotto pressione di un task complesso, può scavalcare. Quella stessa regola, espressa come hook che intercetta il comando e lo blocca, è una garanzia. La discriminante è se posso permettermi che la regola venga ignorata una volta su cento.

Se vuoi vedere come imposto un ambiente Claude Code production-grade per il lavoro PHP quotidiano, dalla struttura dei layer alla scelta dei guardrail, nel mio hub dedicato all'AI per lo sviluppo raccolgo gli articoli con la metodologia che applico sul campo, sempre dal lato di chi questi strumenti li usa in produzione e non solo in demo.

Le skill: conoscenza on-demand, non un manuale sempre aperto

Le skill sono il layer che più ha cambiato il mio modo di lavorare, e anche quello dove vedo più errori. Una skill è una cartella con un file di istruzioni che il modello carica solo quando la sua descrizione fa match con il task: è progressive disclosure via filesystem, l'opposto di incollare tutto nel contesto. La conseguenza pratica è che il valore di una skill sta quasi tutto nella sua descrizione, che non è un riassunto ma un trigger: deve dire al modello quando invocarla, non cosa contiene. Le guide del team che costruisce Claude Code insistono su un dettaglio che confermo dall'esperienza: la sezione più preziosa di una skill è quella dei gotchas, le trappole non ovvie, perché è esattamente la conoscenza che il modello non può dedurre da solo.

Nel mio lavoro tratto come standard le skill che incapsulano procedure ripetibili e error-prone: una pipeline di pubblicazione verso un CMS, la generazione di un tipo specifico di test, l'interazione con un'API interna dalle convenzioni bizzarre. Quello che non trasformo mai in skill è la conoscenza generale: framework noti, comandi standard, pattern che qualunque modello recente padroneggia. Una skill che duplica il training del modello è peso morto che si attiva a sproposito e sporca le sessioni. Il test che applico prima di scriverne una è semplice: se un nuovo collega senior la leggerebbe e direbbe "questo lo sapevo già", non è una skill, è rumore.

Gli hook: i guardrail deterministici che il modello non può aggirare

Gli hook sono il layer che un senior con background di sicurezza ama di più, perché sono l'unico punto dell'harness dove il comportamento non è probabilistico. Un PreToolUse hook può ispezionare un comando prima che venga eseguito e rifiutarlo; uno Stop hook può bloccare la chiusura di un turno se la test suite è rossa. Non è una preferenza espressa al modello: è codice che gira, con un esito binario. Tutta la mia disciplina sui comandi distruttivi vive qui, non nel prompt.

Questo è anche il terreno del mio strumento open source gash, un framework Bash pensato con un contratto first-class per gli agenti LLM: i comandi di sola lettura passano, quelli distruttivi sono bloccati by design, e l'agente lavora dentro un perimetro che non può negoziare. È l'applicazione diretta di un principio che le guide di sicurezza per agenti ripetono da mesi: un agente va governato come un'identità con credenziali, non come un tool fidato. Quando l'agente legge contenuto non fidato (un log, una issue, l'output di un comando esterno) ma deve compiere azioni privilegiate, la separazione la garantisce l'hook, non la buona volontà del modello. Quando non serve un hook: per le preferenze morbide, lo stile del codice, le convenzioni di naming. Lì un hook che blocca diventa attrito; basta CLAUDE.md.

Gli MCP server: pochi, su misura, e con il lazy-loading acceso

Gli MCP server sono la porta verso i sistemi esterni, ed è il layer dove il context bloat fa i danni peggiori. Esistono oltre diecimila server pubblici censiti nel registro ufficiale del protocollo, ormai governato da una fondazione neutrale sotto la Linux Foundation, e la tentazione è collegarne una dozzina. Io ne tengo accesi pochissimi, e quasi sempre custom: un server che parla con il CRM o con il gestionale di un cliente, scritto per esporre esattamente le operazioni che servono e nient'altro, secondo l'approccio che documento negli MCP server personalizzati per il workflow aziendale. Un server generico che espone cento tool mi costa cento descrizioni in finestra a ogni sessione, anche quando ne uso due, e quel costo si paga in token su ogni turno, come ho mostrato analizzando il prompt caching a livello di workspace.

La leva tecnica che rende sostenibile questo layer è il lazy-loading dei tool: invece di dichiarare tutto al boot, si carica lo schema di un tool solo quando serve. Anthropic ha introdotto Tool Search e il Programmatic Tool Calling proprio per gli scenari con migliaia di tool, dove caricare tutto significherebbe saturare il contesto e degradare la latenza. Sul piano della configurazione, il defer_loading sui tool MCP è oggi parte della mia impostazione di default su qualunque agente che superi la decina di strumenti collegati.

Quanti pacchetti può reggere davvero un agente prima di peggiorare?

Non esiste un numero magico, ma esiste una risposta operativa: un agente peggiora molto prima di saturare la finestra dichiarata. La qualità di recupero e di ragionamento cala progressivamente man mano che il contesto si riempie di tool, descrizioni e istruzioni che non servono al task corrente, ed è per questo che la metrica giusta non è "quanti token entrano" ma "quanti tool sono rilevanti adesso". In pratica, su una sessione tipica tengo attivo solo l'insieme minimo che serve a quel compito, e demando tutto il resto al lazy-loading o a un subagent a contesto isolato. La finestra da un milione di token serve a leggere una codebase intera in un colpo, non a parcheggiarci dentro quaranta strumenti che userò forse una volta.

Questo è il principio che separa un setup da senior da uno da collezionista: il primo ottimizza l'attenzione, il secondo ottimizza la dotazione. E l'attenzione, in un modello, è la risorsa scarsa.

I subagent e il tooling che il pacchetto giusto lo scrivi tu

L'ultimo layer è la delega. Un subagent è un'istanza con il proprio contesto isolato a cui affido un sotto-compito: una ricerca pesante su molti file, una verifica indipendente, un task parallelo che non deve inquinare il thread principale. La regola che seguo coincide con quella documentata dal team Claude Code: si delega quando il lavoro è indipendente o richiede uno sguardo fresco, non quando è sequenziale e dipendente, né per micro-task dove l'overhead di coordinamento supera il beneficio. Un subagent ben usato è un modo per tenere pulita la finestra principale; usato male, è solo un altro consumo di token che moltiplica la spesa senza moltiplicare il valore.

C'è poi il caso in cui il pacchetto migliore semplicemente non esiste, e va costruito. Il mio TokToken, un indicizzatore di codebase in un singolo binario pensato per gli agenti, nasce da un problema concreto: dare a un modello una mappa di un repository enorme senza versargli dentro centinaia di migliaia di righe. Indicizza il kernel Linux in poco meno di tre minuti e abbatte il consumo di token di oltre il novanta per cento sulle operazioni di esplorazione. È la dimostrazione del criterio capovolto: quando nessun pacchetto esistente si ripaga il costo in context, lo strumento giusto è quello che riduce quel costo alla radice.

Un harness non è una collezione di plugin: è un sistema in cui ogni componente deve guadagnarsi il posto che occupa nell'attenzione del modello. La domanda non è "cosa posso aggiungere", è "cosa posso togliere senza perdere capacità".

La rassegna, messa in fila, racconta una disciplina più che una lista. I pacchetti che tratto come standard non sono quelli più popolari, sono quelli che superano le tre domande: si ripagano il context, codificano conoscenza che il modello non ha, e reggono il prossimo aggiornamento senza diventare zavorra. Sotto c'è una convinzione che porto da vent'anni di ingegneria, ben prima degli agenti: la potenza di un ambiente di lavoro non si misura da quanto ci hai messo dentro, ma da quanto poco ti serve per andare veloce. Con Claude Code questo principio è diventato misurabile in token, e chi lo ignora paga in attenzione del modello quello che credeva di guadagnare in funzionalità. Se stai mettendo in piedi o ripulendo l'ambiente con cui il tuo team usa gli agenti, e vuoi capire dove stai sprecando context e dove invece manca un guardrail che dovrebbe esserci, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ti dico se il tuo caso rientra nel mio perimetro o se ti conviene un'altra figura.