Executive summary
Quando un sistema di intelligenza artificiale genera codice per un progetto software, la qualità del risultato dipende in larga misura dalle informazioni che riceve come contesto: convenzioni di stile, vincoli architetturali, regole di sicurezza, documentazione interna. Se queste informazioni mancano o sono disorganizzate, il codice generato tende a essere funzionalmente corretto ma incoerente con il progetto in cui deve inserirsi, un problema che si aggrava con la scala del team e la complessità del sistema. Questo articolo analizza la disciplina emergente che si occupa di progettare e strutturare queste informazioni in modo sistematico, trasformando la conoscenza implicita di un team in istruzioni esplicite consumabili dalle macchine. Dall'analisi emerge che l'investimento nella progettazione del contesto produce miglioramenti misurabili nella qualità del codice generato, ma che la disciplina è ancora giovane e presenta limiti significativi legati alla capacità dei modelli di utilizzare efficacemente contesti molto lunghi.
Background
Il termine "context engineering" è emerso nel 2025 come evoluzione del più consolidato "prompt engineering", segnando un cambiamento di prospettiva: dal singolo prompt ottimizzato artigianalmente alla progettazione sistematica dell'intero pacchetto informativo che un modello di linguaggio riceve prima di generare una risposta. Anthropic ha formalizzato questa transizione definendo il context engineering come "the art and science of curating what will go into the limited context window" [1], non un'ottimizzazione testuale, ma una disciplina architetturale che tratta la finestra di contesto come un budget finito di attenzione da allocare strategicamente.
La distinzione è sostanziale. Il prompt engineering opera sul singolo turno di conversazione: formulazione della domanda, scelta degli esempi few-shot, istruzioni di formato. Il context engineering opera a livello di sistema: quali informazioni vengono caricate prima che l'utente formuli la propria richiesta, come vengono organizzate, aggiornate e compattate nel tempo, e quali strumenti vengono resi disponibili all'agente per acquisire informazioni aggiuntive durante l'esecuzione [1, 2]. In un sistema agentico, dove il modello compie decine o centinaia di passi decisionali in sequenza, la qualità del contesto iniziale e la capacità di gestirlo nel tempo determinano la differenza tra un agente efficace e uno che diverge progressivamente dal compito assegnato.
Il fondamento teorico risiede nella proprietà di in-context learning dimostrata da Brown et al. [3]: i modelli di linguaggio di grandi dimensioni modificano il proprio comportamento in funzione del contesto fornito nel prompt, senza aggiornamento dei pesi. Questa proprietà implica che il contesto non è un accessorio ma un parametro di controllo del sistema, ciò che il modello "vede" determina ciò che il modello "fa". Liu et al. [4] hanno dimostrato che questa sensibilità al contesto ha una struttura spaziale non uniforme: le informazioni collocate all'inizio e alla fine della finestra di contesto vengono utilizzate con maggiore efficacia rispetto a quelle nella zona centrale, con cali di performance superiori al 30% su compiti di question answering multi-documento. Questo risultato ha implicazioni dirette sulla progettazione: l'ordine e la posizione degli artefatti di contesto non sono neutri.
Nel dominio specifico dello sviluppo software, il context engineering risponde a un problema documentato empiricamente. Liu et al. [5] hanno analizzato 304.362 commit generati da AI su 6.275 repository GitHub, identificando 484.606 problemi distinti di cui il 24,2% persiste nella revisione più recente del codice. Il benchmark SWE-bench [6] ha mostrato che i tassi di risoluzione di issue reali su repository GitHub sono passati dall'1,96% con Claude 2 in configurazione minimale a oltre il 70% con sistemi agentici dotati di context engineering strutturato, un miglioramento di 35 volte attribuibile non al cambio di modello ma alla qualità del contesto fornito. La prima survey accademica completa sulla disciplina, pubblicata da Mei et al. [2] nel 2025, ha analizzato oltre 1.400 articoli e proposto una tassonomia formale che distingue context retrieval, context generation, context processing e context management come le quattro dimensioni operative della disciplina.
Tassonomia degli artefatti di contesto
Il context engineering per lo sviluppo software si concretizza in una serie di artefatti, file, configurazioni, protocolli, che codificano la conoscenza del team in formati consumabili dagli agenti AI. Questi artefatti si organizzano in quattro categorie funzionali, ciascuna con un ruolo distinto nella catena di generazione.
File di istruzioni a livello di progetto
Il primo livello di contesto strutturato è costituito da file di configurazione che definiscono le regole globali del progetto. La convenzione CLAUDE.md, introdotta da Anthropic per Claude Code [7], è un file Markdown collocato nella root del progetto che viene caricato automaticamente nel contesto dell'agente ad ogni sessione. Contiene comandi di build e test, preferenze di stile, note sulla struttura del codebase, e vincoli architetturali. Convenzioni analoghe esistono per altri strumenti: .github/copilot-instructions.md per GitHub Copilot [8], i file .mdc nella directory .cursor/rules/ per Cursor [9], e AGENTS.md per i Codex agent di OpenAI. La proposta llms.txt di Jeremy Howard [10] estende questo principio alla documentazione web, definendo un formato Markdown standardizzato, analogo a robots.txt per i motori di ricerca, che fornisce agli agenti un punto di ingresso ottimizzato per il consumo automatizzato della documentazione di un progetto.
La differenza tra un file di istruzioni efficace e uno inefficace non risiede nella quantità di informazioni ma nella loro struttura. Garg, in un articolo pubblicato su martinfowler.com [11], identifica quattro elementi di un'istruzione efficace: definizione del ruolo (che stabilisce il baseline comportamentale dell'agente), requisiti di contesto (quali informazioni l'agente deve acquisire prima di agire), standard categorizzati per priorità (regole critiche separate da preferenze), e formati di output strutturati. L'atto stesso di creare queste istruzioni costringe il team a rendere esplicita la conoscenza tacita, un beneficio che precede e trascende l'uso dell'AI.
Skill e workflow strutturati
Il secondo livello introduce artefatti più complessi: le skill, definite come unità di contesto auto-contenute che guidano l'agente attraverso workflow multi-step specifici. Nel sistema Claude Code, una skill è una directory contenente un file SKILL.md con frontmatter YAML (nome, descrizione, trigger di attivazione) e istruzioni dettagliate, corredata opzionalmente da file di riferimento, script eseguibili e template [12]. Il meccanismo opera per progressive disclosure: la skill viene caricata nel contesto solo quando attivata da un trigger specifico, evitando di consumare il budget di contesto quando non necessaria.
Le skill si distinguono dalle istruzioni di progetto per granularità e scopo. Dove le istruzioni di progetto definiscono vincoli globali ("usa TypeScript strict", "segui il pattern repository per l'accesso ai dati"), le skill codificano procedure operative complete: come generare un componente UI conforme al design system del progetto, come eseguire una migrazione di schema nel rispetto dei vincoli di backward compatibility, come creare test di integrazione che verificano non solo la correttezza funzionale ma anche la coerenza architetturale. La composizione di istruzioni globali e skill specializzate crea un sistema stratificato in cui il contesto generale è sempre presente e il contesto specifico viene attivato on-demand.
Tool e protocolli di interazione
Il terzo livello riguarda la capacità dell'agente di acquisire informazioni e compiere azioni durante l'esecuzione, attraverso tool esterni. Il Model Context Protocol (MCP) [13] standardizza questa interazione definendo un protocollo aperto per la connessione tra agenti AI e risorse esterne: database, API, file system, pipeline CI/CD, issue tracker. Ogni tool è descritto da uno schema JSON che specifica nome, descrizione semantica, parametri tipizzati e formato della risposta, un contratto machine-readable che consente all'agente di selezionare e invocare il tool appropriato senza ambiguità.
L'analisi accademica di Hou et al. [14] ha mappato l'ecosistema MCP identificando un ciclo di vita in quattro fasi (sviluppo, distribuzione, operazione, manutenzione) con 16 attività chiave, e ha costruito una tassonomia delle minacce che copre 16 scenari di attacco distinti da quattro categorie di attaccanti. Questo livello di analisi evidenzia che i tool non sono solo un'interfaccia funzionale ma un'infrastruttura di sicurezza: la qualità delle descrizioni semantiche, la validazione dei parametri e il controllo degli accessi determinano non solo l'efficacia dell'agente ma anche la superficie di attacco del sistema.
La ricerca su Gorilla [15] ha dimostrato quantitativamente l'impatto della qualità della documentazione dei tool: un modello LLaMA fine-tuned con documentazione API strutturata supera GPT-4 nella generazione di chiamate API corrette su 1.600 API, e quando combinato con retrieval documentale riduce sostanzialmente le hallucination. Questo risultato conferma che la struttura e la precisione delle definizioni dei tool sono un fattore di qualità di primo ordine nel context engineering.
Il protocollo A2A (Agent-to-Agent) [16], originato da Google e ora governato dalla Linux Foundation, complementa MCP estendendo l'interoperabilità dalla relazione agente-tool alla relazione agente-agente, con supporto per agent discovery tramite "Agent Card", comunicazione sincrona e asincrona, e negoziazione delle capability.
Convenzioni architetturali e decision record
Il quarto livello opera a un grado di astrazione superiore: non istruzioni esplicite per l'agente, ma decisioni architetturali che rendono il codebase stesso più comprensibile per un modello di linguaggio. L'organizzazione in vertical slice, dove ogni feature è un'unità verticale autonoma che include tutti i layer, riduce la quantità di contesto necessario per comprendere e modificare una feature, aumentando la probabilità che l'intera unità logica rientri nella finestra di contesto del modello. I contratti espliciti tra moduli (interfacce tipizzate, API interne documentate) limitano il raggio d'azione dell'agente e riducono gli effetti collaterali.
Gli Architecture Decision Record (ADR), documenti strutturati che registrano decisioni architetturali con contesto, motivazione e alternative considerate, forniscono all'agente il "perché" oltre al "cosa", consentendogli di valutare se una modifica proposta è coerente con le motivazioni originali della decisione. L'insieme di queste convenzioni non è contesto iniettato nel prompt: è contesto embedded nella struttura stessa del codice, che l'agente assorbe implicitamente navigando il repository.
Architettura del contesto: principi di progettazione
La progettazione del contesto per agenti di sviluppo software non è un'attività di scrittura ma un problema di ingegneria dell'informazione, soggetto a vincoli fisici (dimensione della finestra di contesto), cognitivi (capacità del modello di utilizzare efficacemente il contesto disponibile) e operativi (costo in token, latenza, manutenibilità).
Il contesto come budget finito
La finestra di contesto di un LLM è una risorsa finita. Anche modelli con finestre da 200.000 token non utilizzano il contesto in modo uniforme: Liu et al. [4] hanno dimostrato che la performance segue una curva a U rispetto alla posizione dell'informazione nel contesto, con degradi superiori al 30% per informazioni collocate nella zona centrale. Questo vincolo impone scelte di progettazione concrete: le istruzioni critiche (vincoli di sicurezza, convenzioni architetturali inviolabili) devono essere posizionate all'inizio del contesto; le informazioni di dettaglio possono essere delegate a tool che l'agente invoca on-demand; il contesto deve essere compattato progressivamente nelle sessioni lunghe per evitare che informazioni recenti vengano posizionate nella zona a bassa attenzione [1].
Anthropic [1] propone tre strategie operative per la gestione del budget di contesto in agenti long-horizon: la compaction periodica (sintetizzare il contesto accumulato preservando le informazioni critiche), il note-taking strutturato (l'agente mantiene note persistenti che sopravvivono alla compaction), e la strategia di retrieval ibrida (combinare contesto pre-caricato con esplorazione just-in-time tramite tool). Queste strategie riflettono un principio generale: il contesto ottimale non è il contesto massimale, ma il contesto rilevante al momento giusto.
Stratificazione e progressive disclosure
Un'architettura di contesto efficace opera per strati. Il primo strato, istruzioni di progetto, è sempre presente e definisce i vincoli globali. Il secondo strato, skill, viene attivato condizionalmente quando il task lo richiede. Il terzo strato, risultati di tool, viene acquisito dinamicamente durante l'esecuzione. Questa stratificazione segue il principio di progressive disclosure: l'agente riceve inizialmente solo il contesto necessario per orientarsi, e acquisisce contesto aggiuntivo man mano che il task si specifica.
Il framework ACE (Agentic Context Engineering) proposto da Zhang et al. [17] formalizza questo approccio trattando il contesto come un "playbook" che evolve nel tempo attraverso processi modulari di generazione, riflessione e curatela. A differenza di un contesto statico, il playbook si arricchisce incrementalmente preservando le strategie validate e scartando quelle inefficaci. Questo meccanismo previene il "context collapse", il degrado progressivo della qualità delle risposte quando il contesto accumulato diventa troppo lungo e disorganizzato per essere utilizzato efficacemente dal modello.
Qualità del contesto e impatto sulla generazione
Il legame tra qualità del contesto e qualità del codice generato è documentato empiricamente. Wang et al. [18] hanno dimostrato su CodeRAG-Bench che contesto recuperato di alta qualità migliora la generazione, ma che contesto recuperato di bassa qualità può degradare le prestazioni al di sotto della baseline senza retrieval, un risultato che evidenzia i rischi di un context engineering superficiale. La qualità del contesto non è solo una questione di informazione corretta: è una questione di informazione pertinente, strutturata e posizionata appropriatamente.
L'evidenza dal benchmark SWE-bench [6] rafforza questa conclusione su scala più ampia. I sistemi agentici che raggiungono i tassi di risoluzione più elevati non sono necessariamente quelli con i modelli più potenti, ma quelli con il context engineering più sofisticato: navigazione intelligente del repository, selezione mirata dei file rilevanti, e costruzione dinamica del contesto in funzione del problema specifico. L'architettura multi-agente descritta in [19] per code assistant dimostra che la coordinazione del contesto tra agenti specializzati (planning, editing, testing) produce tassi di successo superiori a quelli di un singolo agente monolitico operante sullo stesso modello, confermando che la struttura del contesto è un moltiplicatore di capacità indipendente dalla capacità del modello sottostante.
Context engineering nella pratica dello sviluppo software
Dall'intuizione individuale allo standard condiviso
La transizione dal prompt engineering individuale al context engineering di team è un cambio di paradigma organizzativo, non solo tecnico. Quando un singolo sviluppatore usa strumenti AI con i propri prompt personali, il risultato è proporzionale alla sua esperienza e alla sua comprensione del progetto. Quando un team di dieci sviluppatori fa lo stesso, il risultato è incoerenza scalata: naming diversi, pattern strutturali contraddittori, livelli di qualità variabili tra le sezioni del codebase. Il ThoughtWorks Technology Radar [20] identifica questa transizione come uno dei trend definenti del 2025, descrivendo "a step change in how the industry thinks about AI, with a shift from vibe coding to a concerted effort to think through problems of context, infrastructure, and security."
Il passaggio operativo consiste nel trattare il contesto AI come infrastruttura condivisa, analoga alle regole di linting, alle pipeline CI/CD, o ai coding standard. Garg [11] propone un processo in quattro fasi: intervistare gli sviluppatori senior per estrarre le pratiche implicite del team; organizzare questa conoscenza in standard categorizzati per priorità; codificare gli standard in file di istruzioni versionati nel repository; e verificare l'efficacia tramite code review delle generazioni AI. L'aspetto cruciale è che gli standard codificati eliminano la varianza di qualità tra sviluppatori senior e junior che utilizzano l'agente: il contesto condiviso diventa il livellatore.
Bockeler, in un secondo articolo pubblicato su martinfowler.com [21], contestualizza questa pratica nel framework più ampio del context engineering per coding agent, documentando come la combinazione di rules file, skill e server MCP trasformi il workflow di sviluppo. L'analisi evidenzia una cautela importante: la configurazione del contesto non può garantire risultati deterministici con i LLM, e il team deve mantenere aspettative calibrate sulla variabilità intrinseca delle generazioni.
Encoding del contesto nel ciclo di sviluppo
L'integrazione del context engineering nel ciclo di sviluppo segue un pattern a tre livelli. Al livello base, il file di istruzioni di progetto viene incluso nel repository e aggiornato come qualsiasi altro artefatto versionato, con review, approvazione e changelog. Al livello intermedio, le skill vengono sviluppate per i workflow ricorrenti del team e testate empiricamente: una skill per la generazione di componenti viene validata confrontando l'output con le convenzioni attese, iterata fino a raggiungere un tasso di conformità accettabile, e poi distribuita al team. Al livello avanzato, i tool MCP vengono configurati per connettere l'agente ai sistemi interni, database di staging per verificare le migrazioni, pipeline CI per eseguire test, issue tracker per recuperare il contesto di un bug, creando un ambiente in cui l'agente opera con lo stesso accesso informativo di uno sviluppatore umano.
Il vision paper "Towards AI-Native Software Engineering (SE 3.0)" di Hassan et al. [22] proietta questa evoluzione nel medio termine: un paradigma in cui lo sviluppo software è intent-centric e conversation-oriented, e in cui l'AI non assiste lo sviluppatore ma collabora come un "AI teammate" autonomo. Lo studio di caso riportato in [23] offre un'anteprima concreta: tra il 30 maggio e il 3 giugno 2025, un singolo sviluppatore ha sottomesso 164 pull request assistite da agenti AI, un volume paragonabile alle 176 PR umane prodotte nei tre anni e mezzo precedenti. Questo livello di produttività è sostenibile solo con un context engineering maturo: senza convenzioni strutturate, 164 PR in cinque giorni genererebbero un debito tecnico insostenibile.
Limiti, problemi aperti e direzioni future
Nonostante i risultati promettenti, il context engineering come disciplina presenta limiti strutturali e problemi aperti che ne condizionano l'adozione e l'efficacia.
Il paradosso del contesto lungo
I modelli con finestre di contesto sempre più ampie (128K, 200K, 1M token) suggerirebbero che il problema della gestione del contesto si risolve aumentando la capacità. I risultati empirici contraddicono questa ipotesi. Liu et al. [4] hanno dimostrato che l'efficacia di utilizzo del contesto non scala linearmente con la dimensione della finestra: anche modelli progettati per contesti estesi mostrano degradi significativi nella zona centrale. Mei et al. [2] identificano un'asimmetria critica nella survey di oltre 1.400 articoli: i modelli attuali eccellono nella comprensione di contesti complessi ma faticano a generare output altrettanto sofisticati, una limitazione che nessuna quantità di contesto può compensare se il modello non è in grado di utilizzarlo efficacemente nella fase generativa.
Manutenibilità e drift
Gli artefatti di contesto sono soggetti allo stesso problema di qualsiasi documentazione: il drift rispetto al codice reale. Un file di istruzioni che descrive convenzioni non più rispettate, una skill che codifica un workflow obsoleto, o una definizione MCP tool con parametri non aggiornati non solo sono inutili ma sono attivamente dannosi, l'agente genera codice coerente con istruzioni obsolete, introducendo inconsistenze che richiedono debugging. Il costo di manutenzione del contesto è un costo ricorrente che le organizzazioni devono pianificare esplicitamente. Il framework ACE [17] propone un meccanismo di evoluzione automatizzata del contesto tramite cicli di generazione-riflessione-curatela, ma l'applicabilità di questo approccio a contesti di sviluppo software reali rimane da validare su scala.
Sicurezza e superficie di attacco
L'apertura del contesto a tool esterni introduce una superficie di attacco non trascurabile. Hou et al. [14] hanno identificato 16 scenari di minaccia nel ciclo di vita MCP, inclusi attacchi di prompt injection attraverso risposte di tool manipolate, esfiltrazione di dati attraverso tool con permessi eccessivi, e denial-of-service attraverso tool che generano output volumetricamente ingestibile. La sicurezza del context engineering non è un problema di configurazione ma un problema architetturale: il principio del minimo privilegio deve essere applicato sistematicamente a ogni tool, e i risultati dei tool devono essere validati prima dell'iniezione nel contesto dell'agente.
Misurabilità e standardizzazione
La disciplina manca di metriche condivise per valutare la qualità del contesto. "Il codice generato rispetta le convenzioni del progetto" è un obiettivo intuitivo ma difficile da quantificare in modo automatizzato, a differenza di metriche come la copertura dei test o la complessità ciclomatica, non esiste uno strumento standard per misurare la "conformità architetturale" di una generazione AI. Analogamente, non esiste uno standard condiviso per la struttura degli artefatti di contesto: CLAUDE.md, .cursorrules, copilot-instructions.md e AGENTS.md risolvono lo stesso problema con formati diversi e incompatibili. L'adozione di MCP come standard per i tool, e di llms.txt per la documentazione web [10], sono segnali di convergenza, ma la standardizzazione degli artefatti di istruzione e delle skill resta un problema aperto.
Direzioni future
L'evoluzione del context engineering come disciplina si articola lungo tre direttrici principali. La prima è la formalizzazione: la survey di Mei et al. [2] rappresenta un primo passo verso una tassonomia condivisa, ma servono framework valutativi che consentano di confrontare sistematicamente strategie di context engineering diverse. La seconda è l'automazione: l'estrazione automatizzata di convenzioni da codebase esistenti, la generazione di istruzioni a partire da code review storiche, e l'evoluzione adattiva del contesto in funzione dei risultati osservati sono aree di ricerca attiva. La terza è l'interoperabilità: in un ecosistema dove sviluppatori utilizzano simultaneamente più agenti AI (coding assistant nell'IDE, agenti CI/CD, agenti di review), la capacità di condividere e sincronizzare il contesto tra agenti diversi, supportata da protocolli come A2A [16], diventa un requisito architetturale.
Riferimenti
[1] Anthropic (P. Rajasekaran, E. Dixon, C. Ryan, J. Hadfield), "Effective Context Engineering for AI Agents," Anthropic Engineering Blog, September 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[2] L. Mei et al., "A Survey of Context Engineering for Large Language Models," arXiv:2507.13334, 2025. https://arxiv.org/abs/2507.13334
[3] T. B. Brown et al., "Language Models are Few-Shot Learners," in Proc. NeurIPS, 2020. https://arxiv.org/abs/2005.14165
[4] N. F. Liu et al., "Lost in the Middle: How Language Models Use Long Contexts," Transactions of the Association for Computational Linguistics (TACL), 2024. https://arxiv.org/abs/2307.03172
[5] Y. Liu et al., "Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild," arXiv:2603.28592, 2026. https://arxiv.org/abs/2603.28592
[6] C. E. Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?," in Proc. ICLR, 2024. https://arxiv.org/abs/2310.06770
[7] Anthropic, "Claude Code Best Practices," 2025. https://www.anthropic.com/engineering/claude-code-best-practices
[8] GitHub, "Adding Custom Instructions for GitHub Copilot," GitHub Documentation, 2025. https://docs.github.com/copilot/customizing-copilot/adding-custom-instructions-for-github-copilot
[9] Anysphere, "Cursor Rules Documentation," 2025. https://docs.cursor.com/context/rules
[10] J. Howard, "llms.txt — A Proposal to Standardise an LLM-friendly File," Answer.AI, 2024. https://llmstxt.org/
[11] R. Garg, "Encoding Team Standards," martinfowler.com (ThoughtWorks), March 2026. https://martinfowler.com/articles/reduce-friction-ai/encoding-team-standards.html
[12] Anthropic, "Equipping Agents for the Real World with Agent Skills," Claude Blog, October 2025. https://claude.com/blog/equipping-agents-for-the-real-world-with-agent-skills
[13] Model Context Protocol, "MCP Specification (2025-11-25)," 2025. https://modelcontextprotocol.io/specification/2025-11-25
[14] X. Hou et al., "Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions," arXiv:2503.23278, 2025. https://arxiv.org/abs/2503.23278
[15] S. G. Patil et al., "Gorilla: Large Language Model Connected with Massive APIs," in Proc. NeurIPS, 2024. https://arxiv.org/abs/2305.15334
[16] Google, "Agent-to-Agent (A2A) Protocol," GitHub repository, 2025. https://github.com/a2aproject/A2A
[17] "Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models," arXiv:2510.04618, 2025. https://arxiv.org/abs/2510.04618
[18] Z. Z. Wang et al., "CodeRAG-Bench: Can Retrieval Augment Code Generation?," arXiv:2406.14497, 2024. https://arxiv.org/abs/2406.14497
[19] "Context Engineering for Multi-Agent LLM Code Assistants," arXiv:2508.08322, 2025. https://arxiv.org/pdf/2508.08322
[20] ThoughtWorks, "Technology Radar Volume 33," 2025. https://www.thoughtworks.com/about-us/news/2025/thoughtworks-tech-radar-33-rapid-ai
[21] B. Bockeler, "Context Engineering for Coding Agents," martinfowler.com (ThoughtWorks), February 2026. https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html
[22] A. E. Hassan et al., "Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap," arXiv:2410.06107, 2024. https://arxiv.org/abs/2410.06107
[23] "The Rise of AI Teammates in Software Engineering (SE) 3.0," arXiv:2507.15003, 2025. https://arxiv.org/abs/2507.15003