Context engine: da 2,5 ore a 25 minuti per i coding agent

2,5 ore e 21 milioni di token per completare un task. Oppure 25 minuti e 10 milioni di token per lo stesso task. La differenza? Un context engine attivo.

Questo dato arriva da un benchmark presentato da Peter Werry di Unblocked alla conferenza AI Engineer 2026. Non è un caso isolato: è il pattern che osservo ogni giorno con i coding agent che implementiamo per i clienti. Più un agente AI parte da zero, più brucia token esplorando la codebase alla cieca. Più contesto organizzativo ha già digerito, più va dritto al punto.

Un context engine per AI coding agent è un layer infrastrutturale che sintetizza la conoscenza di un’organizzazione, codice, documenti, conversazioni, decisioni passate, e la serve all’agente nel formato giusto al momento giusto. Non è un RAG glorificato. Non è un database vettoriale con una query sopra. È il sistema che risponde alla domanda: perché il codice è scritto così, chi ne sa di più, e cosa è già stato provato e ha fallito.

Perché collegare MCP non basta per i coding agent

Il primo istinto di chi lavora con agenti AI nel 2026 è collegare server MCP a tutto: Slack, Jira, GitHub, Confluence, Notion. Accesso universale. Il problema è che accesso non significa comprensione.

Peter Werry lo chiama satisfaction of search, un termine che viene dalla radiologia. Quando un tecnico trova la prima anomalia su una radiografia, tende a fermarsi. Lo stesso fanno gli agenti: trovano la prima risposta plausibile in un documento Notion e procedono, ignorando che la vera risposta sta in una conversazione Slack di tre mesi fa o in un incident report che nessuno ha mai linkato al codice.

Il risultato è codice che compila ma non rispetta le convenzioni del team, che ripete errori già fatti, che ignora decisioni architetturali prese mesi prima. Il modello ha le capacità tecniche. Quello che gli manca è il contesto organizzativo che un ingegnere umano accumula in mesi di lavoro.

Tre miti sul context engineering da sfatare nel 2026

Mito 1: basta collegare più tool. Wiring up Slack, GitHub, Confluence via MCP dà accesso ai dati grezzi. Ma senza un layer che costruisca relazioni tra queste fonti, l’agente non capisce perché una decisione è stata presa. Un context engine distilla i pattern ripetuti dai code review, identifica gli esperti per area di codice, e collega le conversazioni alle modifiche che hanno generato.

Mito 2: una context window più grande risolverà tutto. Anche con 10 milioni di token disponibili, infilare tutto nel contesto non funziona. I modelli soffrono ancora nel ragionare attraverso fonti eterogenee e nel distinguere cosa è attuale da cosa è obsoleto. Più contesto non significa contesto migliore.

Mito 3: il contesto non ha bisogno di personalizzazione. Un agente che lavora sulla parte frontend di una codebase non ha bisogno dello stesso contesto di chi lavora sul backend. Un context engine efficace pesa i repository su cui la persona lavora di più, fa un deep retrieval su quelli, e un retrieval più ampio sul resto. Senza personalizzazione, il contesto diventa rumore.

Come funziona un context engine: i componenti chiave

Un context engine non è un singolo algoritmo. È un’architettura composta da più layer che lavorano insieme. I componenti fondamentali emersi dal talk e dalla nostra esperienza con i clienti sono quattro.

Social graph e mappa degli esperti: analizzando chi fa review a chi, chi contribuisce a quale parte del codice, e con quale frequenza, il context engine costruisce una mappa delle competenze. Quando l’agente lavora su un’area specifica, sa chi sono gli esperti e può usare le loro decisioni passate come guida.

Conflict resolution: la documentazione dice una cosa, il codice un’altra, una conversazione Slack suggerisce una terza via. Un context engine deve gestire queste contraddizioni, non nasconderle. La lezione più importante: quando il sistema non riesce a risolvere un conflitto, deve dirlo esplicitamente all’agente, che a sua volta coinvolge l’umano.

Data governance: in un’organizzazione reale esistono canali Slack privati, repository con accesso limitato, documenti HR riservati. Il context engine deve rispettare i permessi di ogni utente. Le risposte che fornisce all’agente di un junior developer non possono includere informazioni a cui quel developer non ha accesso.

Distillazione di best practice: analizzando centinaia di code review nel tempo, il sistema estrae i pattern ripetuti e li trasforma in memorie persistenti. Quando un agente lavora su codice simile, queste memorie vengono caricate nel contesto. È il meccanismo che replica l’esperienza organizzativa che un ingegnere accumula in mesi.

Tre errori da evitare costruendo un context engine

Peter Werry ha condiviso le lezioni apprese costruendo Unblocked. Tre sono particolarmente rilevanti per chi sta costruendo o valutando soluzioni simili.

Ottimizzare per l’accesso, non per la comprensione: il primo approccio del team Unblocked è stato collegare tutti i tool e fornire un knowledge graph traversabile. Non ha funzionato. L’agente aveva accesso a tutto ma non capiva nulla. Il salto di qualità è arrivato quando hanno iniziato a distillare e sintetizzare, non solo a recuperare.

Nascondere i conflitti invece di esporli: inizialmente risolvevano i conflitti tra fonti con strategie naive, privilegiando la fonte più recente o il codice sul branch principale. Ma la recenza non è sempre verità: a volte quello che conta di più è la direzione futura, non lo stato attuale. La soluzione è esporre il conflitto all’agente e lasciare che coinvolga l’umano quando serve.

Cachare le risposte precedenti: riutilizzare una risposta passata per domande simili sembra efficiente, ma in un contesto che cambia continuamente (codice, documenti, conversazioni) porta a risposte obsolete. Peggio ancora: se il modello ha dato una risposta sbagliata e quella viene usata come contesto futuro, si crea una regressione verso la mediocrità.

Context engine a confronto: Unblocked, Augment Code e Glean

Nel 2026 esistono tre approcci principali al problema del contesto per coding agent. Nessuno è universale: la scelta dipende da cosa serve alla tua organizzazione.

Aspetto	Unblocked	Augment Code	Glean
Focus primario	Contesto organizzativo cross-source	Indexing semantico codebase	Document discovery aziendale
Integrazione agenti	MCP server + CLI	IDE nativo + MCP	API + plugin
Risponde a	Perché il codice è così	Dove e come modificare	Dove trovo il documento
Social graph	Sì, con esperti per area	No	Parziale
Conflict resolution	Sì, con feedback loop	No	No
Deploy	Cloud + on-prem	Cloud	Cloud + on-prem

Per team di sviluppo che vogliono capire il perché dietro le decisioni architetturali, Unblocked è la scelta più completa. Per chi ha bisogno di un copilot che conosca profondamente la struttura del codice, Augment Code è più diretto. Glean funziona meglio come layer di ricerca documentale che affianca, ma non sostituisce, un context engine per il codice.

I limiti che nessuno menziona: quando il context engine non basta

Un context engine non è una bacchetta magica. Ci sono problemi aperti che vale la pena conoscere prima di investire.

Privacy e data governance in Europa: far transitare conversazioni Slack, documenti interni e codice proprietario attraverso un servizio cloud terzo è un problema reale per molte aziende europee. Le soluzioni on-prem esistono ma sono più costose da mantenere, come ammette lo stesso Werry. Per una banca con network isolation, amministrare la piattaforma richiede risorse dedicate.

Il cold start organizzativo: un context engine funziona bene quando ha mesi di storia da analizzare. Per un’organizzazione nuova o un team appena formato, il social graph è sottile e le best practice distillate sono poche. In questi casi, il valore aggiunto rispetto a un buon file CLAUDE.md o AGENTS.md è marginale.

Il rischio di over-engineering: per un team di 5 persone che lavora su un monorepo, un context engine enterprise è probabilmente eccessivo. Un file di contesto ben scritto, aggiornato con disciplina, e un paio di server MCP mirati possono coprire l’80% del valore al 5% del costo.

Dove il context engine crea più valore oggi

Dall’esperienza di Unblocked e da quella che osservo con i nostri clienti, i casi d’uso con il ROI più immediato sono tre.

Fase di planning: qui il context engine ha il massimo impatto. Quando l’agente pianifica un task, avere già il contesto decisionale (cosa è stato provato, cosa ha fallito, quali sono le convenzioni) evita cicli di rework. È la differenza tra un agente che propone la soluzione giusta al primo tentativo e uno che ne prova tre.

Code review automatizzata: senza contesto organizzativo, un agente reviewer guarda solo la correttezza tecnica. Con un context engine, capisce anche la motivazione del codice e può valutare se una modifica è allineata con la direzione architetturale del progetto.

Triage e incident management: quando un errore appare in produzione, il context engine collega il segnale alle conversazioni passate su problemi simili, agli esperti dell’area coinvolta, e alla storia delle modifiche recenti. Il mean time to resolution si comprime drasticamente.

Il context engineering nel 2026 non è più un concetto teorico. È infrastruttura, come documenta Martin Fowler e come Anthropic stessa ha formalizzato nelle sue linee guida per agenti. La domanda per chi costruisce con agenti AI non è se il contesto serve, ma quanta infrastruttura dedicargli. E la risposta, come quasi sempre in ingegneria, è: dipende dalla scala del problema che stai risolvendo.