Mantenere un contesto agentico ricco senza impazzire 🧠
Se hai usato un LLM per più di cinque minuti, hai già visto entrambe le facce della medaglia: da un lato ti legge mezza Internet in una pausa caffè ☕, dall’altro si dimentica cosa gli hai detto tre messaggi fa (o peggio: “ricorda” cose che non avete mai detto).
Non è (solo) colpa tua, né (solo) colpa del modello. È che stiamo chiedendo a un collega appena assunto di fare il lavoro di uno staff engineer… senza onboarding, senza ticket, e con una lavagna che si cancella da sola.
Trattalo come un nuovo assunto 👶
Ogni interazione con un LLM andrebbe concepita come se stessi dialogando con una persona appena entrata in azienda.
Non ti conosce. Non sa come ragionate nel team. Non ha il contesto storico (“quella decisione del 2021 che nessuno osa più toccare”). Non sa nemmeno quali sono le tue priorità reali, a meno che tu non gliele dica.
Ecco la parte ironica: spesso con i nuovi assunti siamo bravissimi.
Spieghiamo il dominio, definiamo cosa significa “fatto”, diamo esempi di input/output, indichiamo i vincoli e diciamo dove trovare la documentazione. Poi con l’LLM facciamo: “sistemami il progetto” e ci aspettiamo precisione chirurgica. Spoiler: non funziona.
Memoria breve, lettura veloce 🧾
Gli LLM sono straordinari nel macinare grandi quantità di documentazione in poco tempo. In questo senso sono più simili a un collega che sa fare skimming ad altissima velocità e sa anche riassumere bene.
Ma hanno un limite strutturale: la memoria utile in conversazione è finita. E quella finestra limitata non può essere usata solo per “ricordare il pregresso”, perché nella stessa finestra devono stare anche:
- l’obiettivo corrente,
- i vincoli,
- lo stato del lavoro,
- le decisioni prese,
- la definizione di done.
Quando chiedi al modello di “tenere tutto a mente”, stai pagando in qualità: il contesto si gonfia, si sporca, e diventa rumore.
La soluzione non è “più token”. È progettare la memoria come si progetta un sistema: cosa serve sempre, cosa serve solo ora, cosa va sintetizzato, cosa va archiviato.
Task piccoli, precisione grande 🔬
Gli LLM, come (quasi) tutti gli sviluppatori, lavorano meglio su task specifici.
Un task grande e vago (“migliora l’architettura”) è un invito alla narrativa: ti risponderà bene, con tono sicuro, e con abbastanza generalità da sembrare sempre plausibile.
Un task piccolo e verificabile (“riduci le responsabilità di questa funzione, mantenendo gli stessi input/output e aggiungendo un test di regressione”) invece è un invito alla precisione.
Questo non è “prompt engineering da smanettoni”. È semplicemente project management applicato a un collaboratore che:
- non si stanca,
- non si offende,
- ma non può intuire ciò che non gli dici.
Per i task lunghi serve un piano 🗺️
Se vuoi far lavorare un LLM su un task lungo, non chiedergli di “fare tutto” e poi sperare.
Chiedigli un piano di lavoro.
Non un elenco di buone intenzioni, ma una sequenza con obiettivi concreti e verificabili. Per esempio:
- capire lo stato attuale,
- definire l’obiettivo e i vincoli,
- proporre modifiche minime e incrementalmente testabili,
- eseguire,
- validare.
Il punto chiave: il piano può (e spesso dovrebbe) essere redatto dall’LLM stesso, dopo un’analisi della codebase e con obiettivi specifici.
E qui arriva il vantaggio vero.
Un piano serve per revisionare prima, non per decorare 📌
L’utilità del piano, fatto bene, è che ti permette di revisionare il risultato previsto prima che venga implementato.
È una forma di “design review” anticipata:
- si riducono le sorprese,
- si esplicitano i trade-off,
- si individuano rischi e dipendenze,
- si concorda cosa NON verrà toccato.
In pratica: invece di fare code review su 800 righe “generate con fiducia”, fai review su 8 punti di un piano. È più umano. Ed è anche più economico.
E sì: a volte l’LLM, mentre scrive il piano, ti butta lì anche un’anteprima di codice (snippet, pseudocodice, file che “potrebbe creare”). Non è necessariamente un male: può aiutarti a visualizzare la direzione.
Ma il trucco è non farti ipnotizzare dall’anteprima. Trattala come un mock: utile per capire l’idea, non come verità rivelata. Prima approvi la rotta, poi si scrive il codice.
Non tutti i modelli sono uguali (e si vede) 🧪
Ci sono LLM più bravi a creare piani dettagliati, e altri più bravi a eseguirli.
Ci sono modelli veloci e un po’ superficiali, e modelli più lenti ma più precisi e metodici.
E no: non è solo una questione di numero di token in input o output. Si vede chiaramente il diverso training: alcuni modelli sono ottimi nel ragionamento procedurale e nel “tenere la rotta”, altri sono fenomenali nel produrre una soluzione rapidamente (ma tendono a lasciare buchi nei dettagli).
Un’osservazione pratica (e volutamente un po’ brutale):
- spesso Claude arriva all’obiettivo con più iterazioni, ma con un’attenzione al dettaglio più costante;
- spesso GPT prova a chiudere subito, ma nei contesti grandi rischia di tralasciare dettagli importanti.
Non è un giudizio morale. È un promemoria operativo: scegli il modello in base al tipo di lavoro, oppure separa i ruoli: uno “planner”, uno “executor”.
Istruzioni precise: il vero moltiplicatore ✍️
Se vuoi precisione, le istruzioni devono essere precise.
“Sistema il progetto” è una richiesta emotiva. “Modifica solo X, non toccare Y, mantieni compatibilità Z, e dimmi come validare” è una richiesta ingegneristica.
La cosa interessante è che l’LLM può aiutarti a scrivere istruzioni migliori. Nel mio caso, ad esempio, un file come copilot-instructions.md diventa una specie di manuale operativo: stile, vincoli, regole, aspettative. Non perché l’LLM “obbedisca”, ma perché riduci ambiguità.
E c’è un pattern che funziona molto bene: il file di istruzioni principale non deve contenere tutto. Può fare riferimento a file esterni più approfonditi, ognuno dedicato a un uso diverso (stile di scrittura, convenzioni di progetto, regole di refactoring, linee guida per i test, “come si scrive un post”, ecc.).
In questo modo l’LLM ha un entrypoint chiaro, ma può anche “espandere” il contesto solo quando serve, senza appesantire ogni singola conversazione.
Un’altra cosa sorprendentemente utile è indicare esplicitamente nelle istruzioni una directory in cui l’LLM può lavorare in autonomia, creando file di contesto, note e log di esecuzione. Serve sia a mantenere traccia tra iterazioni, sia a dare a te (umano) una visione del “perché” di certe scelte.
Io, ad esempio, uso questa directory come se fosse un piccolo ufficio amministrativo dell’agente, con tre tipi di “registri”:
- dettagli su integrazioni specifiche (cose che non vuoi rispiegare ogni volta),
- file Markdown con analisi e piani di sviluppo per obiettivi specifici,
- un file Markdown con la data come prefisso, per tenere un log delle modifiche e integrazioni eseguite dall’agente.
E ridurre ambiguità è metà del lavoro (l’altra metà è ammettere che l’ambiguità esiste).
Il futuro: skill modulari e processi ripetibili 🧩
Qui entra in gioco un’idea che trovo promettente: trattare certe capacità come skill riusabili.
Un approccio a “SKILLS” ben fatto può dare un boost notevole, perché sposta il focus da “scrivere prompt” a costruire procedure ripetibili, versionabili e migliorabili nel tempo.
In pratica, una skill è un pezzo di processo “impacchettato”:
- definisce obiettivo, input attesi e output desiderati,
- chiarisce vincoli e criteri di accettazione,
- suggerisce una sequenza di passi (che puoi revisionare),
- standardizza come si documenta il risultato.
Il vantaggio non è solo tecnico, è organizzativo: trasformi l’interazione con l’LLM da conversazione creativa a procedura controllata, dove puoi misurare cosa funziona, fare versioning e riusare ciò che dà risultati.
Quando poi inizi a collezionare skill (e non solo prompt), succede una cosa bella: puoi separare i ruoli e ridurre gli errori. Una skill può essere ottima per pianificare, un’altra per eseguire, un’altra ancora per fare review o scrivere documentazione.
- Sito: agentskills.io
- Repo di skill: skills.sh
L’idea, detta senza poesia: meno improvvisazione, più standard operativi.
Conclusione: meno magia, più onboarding 😉
Un LLM non è un genio intrappolato in un terminale. È un collega estremamente capace, ma con un limite chiaro: senza contesto e senza task definiti, produce testo più che lavoro.
Se vuoi “precisione chirurgica”, trattalo come tratteresti un nuovo assunto:
- contesto essenziale ma completo,
- task piccoli e verificabili,
- piano di lavoro da approvare,
- istruzioni chiare e non generiche.
Il resto è rumore. E il rumore, come sempre, lo paghi tu in debugging. 🧯