Tag: pipeline AI

Negli ultimi anni abbiamo assistito all’ascesa fulminea del prompt engineering, l’arte di “parlare bene” a un modello linguistico per fargli fare ciò che vogliamo. Per un periodo sembrava quasi una magia esoterica: bastava scrivere istruzioni creative in linguaggio naturale e l’AI avrebbe fatto il resto.

Col passare del tempo i limiti di questo approccio sono emersi chiaramente. Un singolo prompt, per quanto brillante, non può compensare la mancanza di una struttura solida attorno al modello.

Oggi, chi sviluppa applicazioni basate su LLM (Large Language Model) sa che il vero campo di gioco è un altro: il contesto.

Progettare (bene) il contesto è infatti l’unico modo per costruire prodotti AI robusti e scalabili. È qui che entra in scena il Context Engineering, una disciplina emergente che rappresenta la nuova frontiera nel design dei sistemi basati su AI.

Dal Prompt Engineering al Context Engineering

Solo due righe per ricordarci brevemente da dove siamo partiti. Nel 2023 il prompt engineering ha avuto il suo momento di gloria: erano di dominio pubblico annunci di lavoro per prompt engineer con stipendi da capogiro, e spopolavano corsi su come “parlare con ChatGPT”. Chiunque poteva improvvisarsi prompt engineer digitando richieste ingegnose in una chat e vantarsi delle risposte ottenute. Si parlava persino di vibe coding, un misto di intuito e tentativi ripetuti sul playground di ChatGPT, come se programmare si riducesse a trovare la “vibrazione” giusta con il modello. Questo approccio funzionava, ma solo finché i casi d’uso rimanevano esercizi da hackathon o demo poco più che giocattoli.

Quando però si è passati a costruire veri prodotti basati su LLM, in contesti reali e su scala enterprise, i limiti del semplice prompt engineering sono diventati evidenti. Le applicazioni AI complesse, come agenti autonomi che svolgono compiti nel mondo reale, o piattaforme aziendali che integrano modelli generativi, non possono basarsi sul copywriting creativo delle prompt. Non basta più scrivere istruzioni eleganti: serve un cambio di paradigma. È qui che nasce il concetto di context engineering, un’evoluzione che sposta l’attenzione dalla formulazione della domanda (prompt) alla progettazione di tutto ciò che il modello deve “sapere” e avere a disposizione per fornire risposte utili e affidabili.

In altre parole, il context engineering supera il prompt engineering perché non si limita a cosa chiedere al modello, ma governa come e con quali informazioni glielo si chiede. Un famoso esperto ha riassunto questa differenza così: “Prompt engineering è ciò che fai dentro la finestra di contesto; context engineering è decidere cosa riempie quella finestra”. Mentre il prompt engineer cerca di azzeccare la frase perfetta da inserire in un prompt box, il context engineer progetta l’intero “mondo” in cui il modello opera. Se il prompt engineering è l’arte di scrivere un’istruzione brillante, il context engineering è l’ingegneria che stabilisce cosa succede prima e dopo quell’istruzione,  cosa il modello dovrà ricordare, quali dati recuperare, quali strumenti utilizzare e come incastonare il tutto nel flusso logico dell’applicazione.

Da questa prospettiva, il prompt engineering diventa un sottoinsieme del context engineering. Non sono due pratiche in competizione, ma livelli diversi dello stesso gioco: il prompt giusto è importante, ma da solo conta poco se viene “annegato” in mezzo a migliaia di token di contesto irrilevante o mal strutturato. Ecco perché oggi le competenze richieste vanno oltre la semplice capacità di promptare: servono figure in grado di curare, gestire e ottimizzare tutto il contesto fornito ai modelli AI.

Cosa si intende per Context Engineering?

Il termine Context Engineering definisce la disciplina di progettare e costruire sistemi dinamici che forniscono al modello AI le informazioni giuste, nel formato giusto, al momento giusto, in modo che possa svolgere un compito nel modo migliore possibile. Per comprendere appieno questo concetto, dobbiamo ampliare la nozione di “contesto”.

Non parliamo più di un singolo prompt statico, ma di tutto ciò che il modello vede prima di generare una risposta. Il contesto è un ecosistema informativo completo, che può includere vari elementi tra cui:

• Istruzioni di sistema (o system prompt): regole e linee guida iniziali che definiscono il comportamento dell’AI (es. stile di risposta, persona da impersonare, vincoli da rispettare).
• Prompt utente: la domanda o richiesta immediata posta dall’utente.
• Stato e memoria a breve termine: lo storico della conversazione corrente (prompt e risposte recenti) che l’AI ricorda durante l’interazione.
• Memoria a lungo termine: conoscenza persistente accumulata in sessioni precedenti, ad esempio preferenze dell’utente, dati contestuali importanti o riassunti di conversazioni passate.
• Informazioni esterne recuperate: dati aggiuntivi ottenuti al volo da fonti esterne (Retrieval-Augmented Generation), come documenti aziendali, database, risultati di ricerche o API, rilevanti per la richiesta corrente.
• Strumenti disponibili: funzionalità che l’AI può invocare (ad esempio chiamate a calcolatori, servizi esterni, funzioni specifiche) per eseguire compiti o reperire informazioni.
• Formato di output atteso: indicazioni sul formato con cui il modello deve restituire la risposta (ad esempio uno schema JSON, un elenco puntato, un tono formale vs informale, ecc.).

Come si vede, il contesto è molto più di un semplice prompt: è l’insieme di tutti i fattori che influenzano le decisioni del modello. Fare context engineering significa dunque costruire e gestire attivamente questo ecosistema informativo, anziché lasciare il modello da solo con una breve istruzione sperando che “indovini” ciò che deve fare. Non basta “mettere più roba nel prompt” indiscriminatamente; occorre fornire all’AI esattamente i dati e gli strumenti di cui ha bisogno, eliminando il superfluo.

Un “context engineer” (ammesso che abbia senso un etichetta del genere) svolge diversi compiti chiave:

• Curare le informazioni: decidere quali documenti, dati o conoscenze fornire al modello per uno specifico task, selezionando solo quelle rilevanti (garbage in, garbage out!).
• Strutturare il flusso: organizzare il contesto in un ordine logico ottimale – ad esempio predisponendo prima le istruzioni di sistema, poi eventuali dati recuperati, quindi il prompt utente – così che l’AI riceva un input contestuale chiaro e prioritizzato.
• Comprimere e sintetizzare: riassumere o suddividere informazioni troppo estese per rientrare nei limiti di token della finestra di contesto, preservando però i dettagli cruciali. Ciò implica progettare memorie riassuntive e tecniche di chunking dei dati per non sforare i limiti senza perdere contenuto importante.
• Integrare strumenti: fornire al modello accesso a funzioni esterne (tool API) quando necessario, e far sì che i risultati di questi tool vengano riportati nel contesto in formati facilmente digeribili dall’AI. Ad esempio, se l’LLM deve fare calcoli o ricerche sul web, il context engineer predispone queste possibilità e inserisce le risposte ottenute nel contesto in forma sintetica.
• Definire protocolli chiari: stabilire formati di input/output strutturati (come risposte in JSON, markdown, DSL personalizzati) che il modello possa interpretare senza ambiguità. Questa “impalcatura” aiuta l’AI a capire esattamente come presentare i risultati.
• Monitorare ed ottimizzare: valutare le prestazioni dell’AI in base al contesto fornito, identificando problemi come context dilution (contesto irrilevante che distrae il modello) o informazioni mancanti, e iterare di conseguenza. In altre parole, il context engineer si assicura che l’AI non “perda il filo” e che i suoi output restino pertinenti man mano che le interazioni proseguono.

Tutto questo ha un unico scopo finale: mettere il modello nella condizione di generare l’output corretto in modo plausibile e affidabile. Il context engineering, dunque, è un approccio ingegneristico completo alla progettazione di sistemi AI: non si limita a come formulare le istruzioni, ma si occupa di costruire l’intera architettura informativa e funzionale che sostiene l’intelligenza artificiale.

Una metafora efficace è quella proposta da alcuni esperti: se il prompt engineering è come fare la domanda giusta a un esperto, il context engineering è come preparare la biblioteca perfetta per quell’esperto, scegliendo in anticipo i libri e gli strumenti che potrà consultare mentre risponde. Ecco perché viene definito la “nuova architettura invisibile” dei software AI-ready: lavora dietro le quinte, ma determina in larga parte il successo di un sistema AI.

Perché il Context Engineering è fondamentale (e il prompt da solo non basta)

Man mano che i modelli di AI diventano più capaci, il fattore determinante per ottenere risultati utili non è tanto “spremere” maggiore intelligenza dal modello stesso, quanto assicurarsi che il modello abbia tutto il necessario per funzionare al meglio. In altri termini, la qualità del risultato dipende in gran parte dalla qualità del contesto fornito. Lo si è visto chiaramente con i nuovi agenti AI: nella maggior parte dei casi in cui un agente basato su LLM fallisce o produce output scadenti, la colpa non è di un’improvvisa stupidità del modello, ma di un contesto inadeguato o mal costruito.

Pensiamoci: un LLM non può “leggere nel pensiero”. Se omettiamo dal contesto informazioni cruciali per il task, il modello semplicemente non saprà ciò che non gli abbiamo detto. Allo stesso modo, se gli passiamo informazioni superflue o disorganizzate, rischiamo di confonderlo: prompt eccellenti sepolti sotto montagne di dettagli irrilevanti non daranno comunque buoni risultati. Formato e pertinenza contano quanto il contenuto: inviare dati non strutturati o errori di formattazione nel contesto può portare l’AI a fraintendere la richiesta o a ignorare istruzioni importanti.

Le risposte sbagliate o allucinazioni di un modello sono spesso sintomi di questi problemi di contesto, non difetti intrinseci del motore di AI. Ad esempio, molte aziende che sperimentavano con chatbot interni hanno scoperto che gli insuccessi non dipendevano dal fatto che “il modello GPT non è abbastanza smart”, bensì dal fatto che non avevano progettato bene il contesto attorno al modello. Magari fornivano troppe informazioni non rilevanti (diluzione del contesto), oppure troppo poche informazioni (lacune contestuali), oppure ancora presentavano i dati in modo confuso e poco machine-friendly.

Alcune domande utili da porsi in caso di output insoddisfacenti sono proprio: Abbiamo passato al modello tutte le informazioni necessarie, senza lasciarne indietro di fondamentali? Oppure lo abbiamo sommerso di testo inutile che ne ha “annacquato” la concentrazione? Abbiamo formattato i dati in modo chiaro e strutturato, o solo in prosa libera difficile da interpretare? Stiamo gestendo correttamente la memoria delle interazioni precedenti?. Spesso, analizzando questi aspetti, ci si accorge che l’errore è a monte: non è l’AI a non funzionare, ma il sistema intorno ad essa che non le ha fornito il giusto contesto.

Ecco perché il context engineering è così importante: sposta l’attenzione dal modello al sistema. Invece di chiedersi “come aggiustiamo il modello perché risponda meglio?”, ci si chiede “come possiamo arricchire e ottimizzare il contesto perché il modello abbia tutte le carte in regola per rispondere bene?”. Questa mentalità data-driven fa sì che la responsabilità della qualità dell’output ricada in larga misura sul progettista del sistema, non sul modello in sé. Del resto, quando un LLM ben addestrato sbaglia, nella maggior parte dei casi è perché gli mancava un’informazione o un chiarimento che avremmo potuto dargli. Fornire “le informazioni giuste, nel momento giusto” all’AI non è più facoltativo: è diventato il requisito base per passare dalle demo giocattolo a applicazioni AI realmente funzionanti.

Un nuovo paradigma tecnico e architetturale

Il passaggio dal prompt engineering al context engineering non è solo un cambio di tecnica, ma un’evoluzione dell’architettura dei sistemi AI. Nel paradigma tradizionale immaginavamo una pipeline semplice: input dell’utente (frontend) → prompt elaborato → modello (backend) → output. Ora questa linearità si rompe: tra l’input iniziale e la chiamata al modello entra in gioco un sistema articolato di recupero, trasformazione e orchestrazione dei dati. Invece di un prompt fisso, abbiamo un processo dinamico che costruisce il contesto ad hoc per ogni richiesta.

Possiamo riassumere così le caratteristiche di questo nuovo paradigma architetturale:

• Si supera la rigida divisione frontend/prompt/backend: il contesto diventa una sorta di livello applicativo intermedio che amalgama componenti di front-end (es. input utente, interfaccia) e di back-end (modello AI, database) in un flusso unico.
• La qualità dell’output viene elevata a responsabilità di sistema: non confidiamo più ciecamente che “il modello farà bene”, ma predisponiamo l’architettura in modo da minimizzare le possibilità di errore del modello. In pratica, l’enfasi passa dal migliorare il cervello dell’AI al migliorare il suo “ambiente cognitivo”.
• Cambia la mentalità di progettazione per sviluppatori e leader tecnologici: anziché sperare in qualche magia generativa o prompt perfetto, si ragiona in termini di orchestrazione, di flussi di informazioni e step logici che assicurino robustezza. Ad esempio, un CTO o un AI Lead oggi deve chiedersi come strutturare i dati aziendali perché alimentino efficacemente il modello, come mantenere lo stato di conversazione, quali strumenti integrare, ecc., costruendo un vero sistema cognitivo e non solo un’interfaccia domande-e-risposte.

Dal punto di vista pratico, questa evoluzione ha portato allo sviluppo di nuovi framework e tool specifici per implementare il context engineering. Librerie come LangChain, e più di recente framework come LangGraph, forniscono astrazioni per gestire memorie conversazionali, richiamare strumenti esterni, concatenare chiamate a modelli e controllare con precisione cosa viene passato nella finestra di contesto.

Questi strumenti aiutano i team a costruire agenti LLM più affidabili, dando la possibilità di possedere (cioè determinare esattamente) ogni parte del contesto e del flusso prima che l’LLM produca una risposta. Si tratta di un cambio di prospettiva radicale: l’obiettivo non è più ottenere una singola risposta sensazionale dal modello in condizioni ideali, ma garantire performance consistenti, ripetibili e governabilidel sistema AI nel suo complesso. In altre parole, non basta che l’AI sappia generare testo, deve farlo in produzionesotto vincoli di affidabilità, sicurezza e coerenza. Per riuscirci, ogni componente del contesto dev’essere progettato con rigore ingegneristico.

Va sottolineato che questo nuovo paradigma è multidisciplinare per natura. Il context engineering attinge all’ingegneria del software classica (architettura di sistemi, API, gestione dello stato), ma anche al knowledge management (organizzare informazioni e conoscenza aziendale) e alla UX writing (per modellare il tono e lo stile delle interazioni). Richiede cioè di connettere mondi diversi: quello dei dati e della tecnologia con quello dei processi aziendali e dei contenuti. Nel prossimo paragrafo vedremo come ciò impatta le organizzazioni e la cultura aziendale.

Implicazioni strategiche, organizzative e culturali

Il context engineering non è solo un’evoluzione tecnica: rappresenta anche un cambiamento culturale nel modo in cui le aziende e i team approcciano i progetti di intelligenza artificiale. Tradizionalmente, lo sviluppo di software vedeva ruoli ben distinti – sviluppatori che scrivono codice, analisti che definiscono requisiti, esperti di dominio separati dai tecnici.

Con i sistemi AI basati su LLM, questi confini iniziano a sfumare. Progettare il contesto di un’applicazione AI significa infatti, come osserva il professor Ethan Mollick della Wharton, dover: tradurre processi aziendali in flussi di dati strutturati; riflettere la cultura interna (il tono, il linguaggio, le aspettative) nel contesto fornito al modello; codificare la conoscenza tacita e il know-how operativo dell’organizzazione in forma fruibile dall’AI.

In altre parole, fare context engineering in un’azienda equivale in parte a fare knowledge management avanzato. Occorre mappare il sapere dell’organizzazione (documenti, policy, procedure, FAQ, ecc.), capire cosa serve davvero al modello nei vari scenari d’uso, e strutturare queste conoscenze in modo che l’AI possa utilizzarle efficacemente. Ciò può significare creare nuove basi di conoscenza, ontologie, database di vettori per il semantic search, pipeline di retrievaldedicate. Significa anche farsi domande sulla cultura aziendale: ad esempio, vogliamo che il nostro assistente AI interno adotti un tono informale e creativo, oppure formale e conservativo? Quali valori e best practice interne vanno integrate come istruzioni comportamentali nel contesto? Tutto questo va deciso e codificato a monte, affinché il modello operi in linea con l’identità dell’azienda.

Le implicazioni organizzative sono dunque profonde. I team di sviluppo AI devono diventare interfunzionali: coinvolgere non solo ingegneri del machine learning, ma anche esperti del dominio specifico, data engineer, magari linguisti computazionali e figure di knowledge curator. È una sfida che richiede collaborazione stretta tra chi conosce la tecnologia LLM e chi conosce il contesto di business. Inoltre, la leadership aziendale (CTO, CPO, responsabili innovazione) deve sposare questa visione: investire nella preparazione dei dati e dei contesti prima ancora che nel modello in sé. Non a caso, si sente dire che “nel mondo degli LLM, il contesto è la nuova interfaccia utente”. Progettare queste nuove interfacce – invisibili all’utente finale ma cruciali dietro le quinte – vuol dire in ultima analisi disegnare l’identità operativa dell’azienda nell’era dell’AI.

Dal punto di vista strategico, le aziende che sapranno eccellere nel context engineering avranno un chiaro vantaggio competitivo. Significa poter costruire assistenti virtuali che non allucinano risposte, perché hanno sempre i dati aggiornati e verificati a portata di mano. Significa offrire ai clienti esperienze AI personalizzate e coerenti con il brand, perché il modello “respira” la cultura aziendale che è stata immessa nel suo contesto. E significa poter scalare soluzioni AI in nuovi ambiti in modo più rapido, perché una volta creata l’architettura di contesto, quella diventa un asset riutilizzabile e adattabile a diversi casi d’uso. Non è un caso che alcuni commentatori sostengano che il context engineering sarà la competenza più importante per gli AI engineer d’ora in avanti. È un nuovo campo su cui costruire metodologie, strumenti e best practice, un po’ come lo è stato il DevOps per il software tradizionale. Sta già emergendo una comunità di pratica attorno a questi temi, segno di una trasformazione culturale in atto nel settore tecnologico.

Dal playground alla produzione: professionalizzare l’AI

Un effetto tangibile di questa evoluzione è il passaggio da un approccio ludico-sperimentale con l’AI (tipico dei primi tempi di ChatGPT) a un approccio ingegneristico e strategico. Quello che inizialmente era quasi un gioco di intuito – provare prompt su prompt finché “sembra funzionare” – oggi non è più sufficiente né appropriato per applicazioni in produzione. Il cosiddetto “vibe coding”, ormai usato in tono ironico, ha mostrato i suoi limiti: l’intuizione non scala, e sistemi basati su semplici prompt tweakati a mano risultano fragili, imprevedibili e difficili da manutenere.

Al contrario, il salto di qualità si ottiene spostandosi “dal prompt al contesto, dal tool carino al prodotto solido”. Ciò significa dedicare in fase di progettazione lo stesso rigore che si avrebbe per qualsiasi altra architettura software mission-critical. In un’app AI matura, ogni componente del contesto è pensato, implementato e testato: ad esempio, si verifica che il sistema di retrieval recuperi effettivamente i documenti più rilevanti; si affinano i prompt di sistema con policy chiare; si implementano controlli (guardrails) per evitare che errori si propaghino; si monitora la performance del modello su conversazioni lunghe per calibrare i meccanismi di sommario della memoria, e così via. Tutto questo lavoro non è “visibile” all’utente finale, ma fa la differenza tra un’AI che impressiona in una demo e una che genera valore reale e consistente quando usata ogni giorno da migliaia di utenti.

Per i decision maker, adottare il context engineering significa anche ragionare in termini di strategia dei dati. Bisogna chiedersi: di quali dati disponiamo e come li rendiamo fruibili al nostro AI? Come garantiamo che siano aggiornati e puliti? Quali conoscenze chiave (ad esempio, normative, linee guida interne, tone of voice) dobbiamo infondere nel sistema? Questo ragionamento avvicina il mondo dell’AI a quello della gestione della conoscenza e dei processi aziendali. Progettare il contesto diventa un’attività che precede e indirizza lo sviluppo stesso del modello AI, spesso chiamata AI blueprint o sprint zero: prima di scrivere una riga di codice o di scegliere quale algoritmo utilizzare, si disegna l’ecosistema informativo entro cui l’AI dovrà operare. È qui che molte iniziative AI falliscono o hanno successo – una sorta di “trincea invisibile” dove si vince o si perde la sfida dell’intelligenza artificiale in azienda.

Infine, spostare l’attenzione sul contesto aiuta a demistificare l’AI. Ci ricorda che un LLM, per potente che sia, resta una macchina statistica che funziona in base ai dati che riceve in input. Pensare in termini di context engineering significa vedere l’AI non più come una scatola magica, ma come un componente che va integrato in un sistema più ampio e controllabile.

Come ho scritto “l’era del prompt engineering ci ha insegnato a parlare con l’AI; l’era del context engineering ci sta insegnando a pensare insieme all’AI”. In questa nuova era context-first, le frasi furbe contano meno della capacità di architettare sistemi intelligenti con le informazioni giuste al momento giusto. È un cambiamento di prospettiva notevole: dall’ottimizzazione delle singole frasi all’ottimizzazione della conoscenza e dei processi.

Il contesto prima di tutto

Il context engineering si presenta come la naturale evoluzione – e superamento – del prompt engineering. Dove prima ci si concentrava sul come chiedere qualcosa all’AI, ora l’attenzione è su cosa l’AI conosce e ha a disposizione quando gli viene posta una domanda, e come ottiene queste informazioni. Il contesto diventa la nuova interfaccia su cui progettare l’esperienza AI. Chi riesce a padroneggiare questa interfaccia invisibile – strutturandola, orchestrandola e mantenendola con cura – costruisce di fatto il “cuore” del sistema AI e ne determina il successo o il fallimento operativo.

Questa disciplina richiede un mix di competenze tecniche, strategiche e di dominio, e sta trasformando il modo in cui pensiamo l’implementazione dell’AI nelle organizzazioni. Il messaggio chiave è chiaro: prima di scegliere il modello da usare, bisogna progettare il contesto. Solo così un’intelligenza artificiale può davvero “fare bene il proprio lavoro” in modo ripetibile e affidabile. In un mondo in cui i modelli linguistici sono sempre più potenti e disponibili, la differenza la farà chi saprà alimentarli con il contesto migliore.

Su Gumroad il PDF completo di 78 pagine, sul Context Engineering, da acquistare e scaricare.