Context Engineering
Disciplina ingegneristica formalizzata da Addy Osmani, Shubham Saboo e Sokratis Kartakis nel whitepaper Google The New SDLC With Vibe Coding (maggio 2026): la qualità del codice generato dall'AI dipende molto meno dall'astuzia dei prompt e molto più dalla qualità del contesto fornito all'agente — informazioni ricche e strutturate su codebase, architettura, convenzioni e intento — facendo del context engineering il ponte tra il vibe coding e l'agentic engineering (vedi Spettro Vibe Coding e Agentic Engineering e Harness Engineering). 1
I sei tipi primari di contesto
Per mettere un coding agent nelle condizioni di operare con precisione, gli sviluppatori devono progettare e combinare sei categorie fondamentali di contesto: 1
- Instructions: il ruolo centrale dell'agente, i suoi obiettivi e i confini operativi entro cui deve muoversi. 1
- Knowledge: documenti recuperati, diagrammi architetturali e dati specifici del dominio applicativo. 1
- Memory: sia i log di sessione a breve termine (cosa è appena successo), sia lo stato persistente a lungo termine (che cos'è il progetto). 1
- Examples: dimostrazioni comportamentali few-shot e pattern di riferimento estratti dal codebase. 1
- Tools: le definizioni precise delle API, degli script e dei servizi esterni che l'agente può invocare. 1
- Guardrails: vincoli rigidi (hard constraints), regole di formattazione e validazioni di sicurezza. 1
Contesto statico vs contesto dinamico: una decisione architetturale versionata
Nella generazione di codice assistita dall'AI, il context engineering consiste nel bilanciare con cura quali di questi sei elementi l'agente debba possedere fin dall'inizio e quali debba recuperare su richiesta (on demand), separando il contesto in due livelli: 1
- Contesto statico (Static context): è sempre caricato in memoria e comprende le system instructions, i file di regole (
AGENTS.md,CLAUDE.md,GEMINI.md), la memoria globale e le definizioni delle personas. Definisce chi è l'agente e come si comporta, ma è costoso perché ogni singolo token è presente in ogni interazione, a prescindere dalla sua rilevanza per il task corrente. 1 - Contesto dinamico (Dynamic context): viene caricato su richiesta e comprende le istruzioni delle skill attivate dal task matching, i risultati dei tool recuperati durante l'esecuzione, i documenti estratti da pipeline RAG e la storia di sessione finestrata (windowed session history). È efficiente perché l'agente paga il costo in token solo quando l'informazione serve davvero. 1
Stabilire cosa appartenga al contesto statico e cosa a quello dinamico è un vero trade-off ingegneristico: troppo contesto statico spreca token e diluisce i segnali importanti (vedi anche Cerimonia Proporzionata al Rischio); troppo poco fa sì che l'agente dimentichi regole critiche. I sistemi migliori trattano questo confine come una decisione architetturale di prima classe, sottoposta a code review e versionata esattamente come qualsiasi altra configurazione di sistema (tema approfondito anche nel companion paper Day-3 della serie Google, Context Engineering: Sessions, Skills & Memory). 1
Agent Skills e progressive disclosure: i quattro problemi risolti
Il pattern più potente per gestire il contesto dinamico su scala è rappresentato dalle Agent Skills: pacchetti strutturati e portabili di conoscenza procedurale che l'agente carica esclusivamente quando il compito lo richiede (vedi AI Skills e Grill-Me e Lifecycle delle Skill di Osmani). 1
Invece di incorporare ogni conoscenza specialistica nel system prompt, le skill permettono all'agente di restare un generalista leggero che si flette su richiesta in ruoli specialistici attraverso un meccanismo di progressive disclosure articolato su tre livelli: 1
- All'avvio (at startup): l'agente vede soltanto metadati leggeri. 1
- Al matching del task: quando l'attività corrisponde a una competenza, l'agente carica le istruzioni complete della skill. 1
- Su necessità esplicita: l'agente estrae il materiale di riferimento profondo (deep reference material) solo quando è strettamente richiesto. 1
In questo modo un agente può portare con sé decine di capacità specialistiche pagando il costo in token solo per quella che sta usando attivamente. La rapida adozione delle Agent Skills nei principali coding agent e nelle piattaforme enterprise deriva dal fatto che risolvono quattro problemi storici dello sviluppo di agenti AI: 1
- Context rot da prompt sovraccarichi (context rot from overloaded prompts, vedi anche Context Rot); 1
- Assenza di memoria procedurale per gli LLM (absence of procedural memory for LLMs); 1
- Overhead operativo delle architetture multi-agente (operational overhead of multi-agent architectures); 1
- Necessità di portabilità tra tool e vendor diversi (need for portability across tools and vendors). 1
Dal prompt engineering al context engineering: la domanda del nuovo membro del team
Il passaggio dal prompt engineering al context engineering riflette una verità profonda sul lavoro con i modelli linguistici: gli LLM non hanno bisogno di istruzioni formulate con furbizia quanto piuttosto dello stesso contesto di cui avrebbe bisogno uno sviluppatore umano competente per fare un buon lavoro. 1
La domanda guida per l'ingegnere cambia radicalmente: 1
Non più "come inganno l'AI per farle scrivere buon codice?", ma "che cosa dovrebbe sapere un nuovo membro del team per contribuire in modo efficace, e come codifico questa conoscenza in una forma che l'AI possa utilizzare?" (vedi anche Elephant-Goldfish Model). 1
Spostando il focus dalla scrittura della sintassi all'ingegnerizzazione del contesto (che diventa anche una leva finanziaria decisiva sull'OpEx; vedi Economia dello Sviluppo AI), cambiano i colli di bottiglia della creazione del software: non aspettiamo più che le mani umane digitino boilerplate, ma che le menti umane definiscano i confini e l'harness entro cui gli agenti operano. 1
Vedi anche: Harness Engineering, Spettro Vibe Coding e Agentic Engineering, AI Skills e Grill-Me, Cerimonia Proporzionata al Rischio, Economia dello Sviluppo AI, Addy Osmani