Programmazione agentica: come funziona, dove fallisce e come si verifica il lavoro di un agente

Nel 2026 non si discute più se un agente AI sappia scrivere codice: sui benchmark di riferimento i modelli di frontiera superano il 90% di task risolti, contro il 4% del 2023. Si discute di chi verifica quel codice. La frase che ricorre nel dibattito tecnico di questi mesi è che il collo di bottiglia è il verificatore, non il modello: la generazione è diventata economica, il controllo no.

Uso Claude Code quotidianamente da un anno, sia sul lavoro sia su progetti personali, con una batteria di server MCP collegati stabilmente — Google Ads, Google Analytics, Google Search Console, DataForSEO, Semrush, Google Calendar, Playwright — per un totale di centinaia di tool esposti all’agente. Buona parte degli articoli di questo blog passa dall’agente, con intensità che va dalla semplice correttura ortografica alla stesura completa di una bozza; tutti i miei script sono supervisionati dall’AI. Il bilancio, dopo un anno: sono più veloce e produco più output, ma passo molto più tempo ad analizzare, orchestrare e verificare di quanto ne passassi quando facevo tutto a mano.

Questa guida ricostruisce come funziona davvero la programmazione agentica — il loop, l’harness, il confine di contesto tra orchestratore e subagent — documenta quattro casi reali con gli errori che ho dovuto correggere, e mette in fila i dati di settore che i vendor non citano mai.

Cos’è la programmazione agentica

La programmazione agentica è l’uso di sistemi che ricevono un obiettivo anziché un’istruzione e lavorano in un ciclo autonomo finché non lo raggiungono, non esauriscono le risorse o non si arrendono. La differenza con l’interazione classica è strutturale: non è un turno domanda-risposta ripetuto più volte, è un processo che mantiene lo stato.

Il ciclo si articola in quattro momenti che si ripetono:

1. Osserva — legge lo stato reale del sistema: file, output di comandi, risposte di API, log.
2. Ragiona — confronta lo stato osservato con l’obiettivo e decide il prossimo passo.
3. Agisci — esegue un’azione che modifica lo stato del mondo: scrive un file, lancia un comando, chiama un’API.
4. Verifica — controlla il risultato dell’azione e decide se iterare o considerare chiuso il task.

Perché un sistema sia agentico servono tre condizioni simultanee.

1. Riceve un obiettivo, quindi decide da sé i passi intermedi.
2. Ha accesso a strumenti che modificano lo stato, non solo che leggono.
3. Ed è in grado di accorgersi di un proprio errore e riprovare con una strategia diversa.

Se manca anche una sola delle tre, si tratta di qualcos’altro.

Una nota terminologica: “agentico” è un calco dall’inglese agentic, criticato in ambito linguistico ma ormai standard nella letteratura tecnica. Lo uso come termine tecnico, non come sinonimo di “autonomo”.

Cosa non è: autocomplete, chatbot e agent washing

La confusione su questo punto non è innocua: alimenta aspettative sbagliate e, a livello aziendale, progetti destinati a morire. Facciamo tre distinzioni operative.

• L’autocomplete completa, non decide. Il completamento inline classico predice la continuazione di ciò che stai scrivendo. Non ha obiettivo, non osserva lo stato del progetto oltre il contesto immediato, non verifica nulla. È uno strumento eccellente e non è un agente.
• Il chatbot risponde, non agisce. Un’interfaccia conversazionale che produce testo — anche testo di codice perfetto — non modifica lo stato del mondo. Il passaggio dal codice suggerito al codice applicato lo fai tu, e con esso ti prendi la verifica.
• Uno script con un prompt dentro resta uno script. Una pipeline deterministica che a un certo punto chiama un LLM per classificare o riassumere non diventa agentica: il flusso di controllo è fissato a priori dal programmatore, non deciso a runtime dal modello.

Il fenomeno per cui prodotti esistenti vengono rietichettati come agentici ha un nome, agent washing, ed è tra le cause citate per il tasso di fallimento dei progetti aziendali: Gartner prevede che oltre il 40% delle iniziative agentiche verrà cancellato entro il 2027, non per limiti dei modelli ma per incapacità di portarle in produzione.

Il test per classificare qualunque sistema si riduce a tre domande. Il sistema decide da solo qual è il prossimo passo? Può usare strumenti che modificano lo stato del mondo? Può accorgersi di aver sbagliato e riprovare diversamente? Tre sì: è un agente. Anche un solo no: è automazione, ed è bene chiamarla così.

Cos’è e come funziona un agente

Un agente non è un modello. È un modello dentro un’impalcatura, e nel 2026 l’impalcatura conta più del modello.

Il modello

Il motore di ragionamento. È il componente meno differenziante di tutto lo stack: fra i modelli di frontiera le differenze pratiche sul lavoro quotidiano si sono assottigliate al punto che la scelta pesa meno della configurazione. Vale la pena capire come funzionano internamente — ne ho scritto in come funzionano gli LLM, dai Transformer ai modelli 2026 — ma è un errore ottimizzare la scelta del modello quando l’harness è configurato male.

L’harness

L’harness è tutto ciò che sta intorno al modello: chi gestisce il loop, chi mantiene lo stato fra un’iterazione e l’altra, chi decide quali tool sono disponibili, chi applica i permessi, chi salva la memoria su disco. La traiettoria del settore negli ultimi quattro anni si riassume in tre fasi: prompt engineering (2022-2023, come formulare la richiesta), context engineering (2024-2025, cosa mettere nella finestra di contesto e cosa no), harness engineering (2026, come progettare l’ambiente in cui l’agente opera).

Il punto pratico: due persone che usano lo stesso modello con harness diversi ottengono risultati incomparabili. È qui che si gioca la differenza fra chi trova gli agenti inutili e chi ci lavora ogni giorno.

I tool e il protocollo MCP

I tool sono le mani dell’agente: filesystem, terminale, git, API esterne. Senza tool il modello può solo produrre testo; con i tool può leggere dati reali invece di ricostruirli a memoria.

Il Model Context Protocol è lo standard che ha uniformato il collegamento fra agenti e fonti dati esterne. Nel mio setup i server MCP collegati stabilmente sono Google Ads, Google Analytics, Google Search Console, DataForSEO, Semrush, Google Calendar e Playwright: l’agente interroga i dati veri con le mie credenziali, invece di produrre stime plausibili. È la differenza fra un’analisi e una narrazione.

Non ripeto qui l’implementazione: l’ho documentata in MCP Server, l’architettura silente del web intelligente per la parte architetturale e in Server MCP con Claude Code: guida pratica per la configurazione passo passo, gotcha inclusi.

Contesto e memoria

La finestra di contesto è una risorsa da amministrare, non un contenitore da riempire. Un contesto saturo di materiale irrilevante degrada la qualità del ragionamento tanto quanto un contesto vuoto.

I due meccanismi che contano sono le istruzioni persistenti di progetto — un file letto a ogni avvio, che contiene comandi, convenzioni e divieti — e la memoria su filesystem, che permette allo stato di sopravvivere alla singola sessione. Il file di istruzioni è il singolo intervento con il miglior rapporto fra sforzo e resa: scritto una volta, elimina la ripetizione di contesto a ogni sessione.

Un esempio minimale, deliberatamente scarno:

# Progetto — pipeline analisi SEO

## Ambiente
- Virtual env: `venv/` — attivarlo sempre prima di eseguire Python
- Mai installare pacchetti nel Python di sistema

## Comandi
- Test: `venv/Scripts/python.exe -m pytest`
- Validazione HTML: `venv/Scripts/python.exe skills/_html_validate.py --file <path>`

## Convenzioni
- Output temporanei solo in `output/`
- Nessun file fuori dalle cartelle di progetto

## Divieti
- MAI eseguire comandi git di iniziativa (add, commit, push, reset)
- MAI modificare i file in `credenziali/`

L’ultima sezione è la più importante e la più trascurata: un agente senza divieti espliciti applica il proprio criterio, e il suo criterio non è il tuo. Su dove risiedono fisicamente questi file e come si gestiscono ho scritto una guida dedicata: dove Claude Code salva memoria e configurazione.

I permessi

I permessi definiscono cosa l’agente può fare senza chiedere. È la superficie di rischio del sistema, e va progettata prima del primo prompt, non dopo il primo incidente.

Il principio è il minimo privilegio applicato per categorie di azione: lettura ampia, scrittura ristretta, esecuzione controllata, rete solo dove serve.

{
  "permissions": {
    "allow": [
      "Read(./**)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(venv/Scripts/python.exe -m pytest:*)"
    ],
    "deny": [
      "Read(./credenziali/**)",
      "Read(./.env)",
      "Bash(git push:*)",
      "Bash(rm:*)"
    ]
  }
}

Una regola che vale la pena adottare: le credenziali non devono stare nel contesto dell’agente. Non perché l’agente sia malintenzionato, ma perché tutto ciò che entra nel contesto può essere esfiltrato da un input ostile, per i motivi che vedremo nella sezione sulla sicurezza.

Orchestratore e subagent: il confine del contesto

Questa è la parte che nella documentazione viene liquidata in due righe e che nella pratica determina la qualità del risultato.

Quando un task è troppo grande per una sessione sola, l’agente principale può delegare porzioni di lavoro a subagent: istanze separate, ciascuna con la propria finestra di contesto, che eseguono un compito e restituiscono un risultato. Il pattern è quello orchestratore-worker ed è la base di tutti gli strumenti di esecuzione parallela usciti nel 2026.

Il punto che va capito prima di usarli: il subagent è un agente cieco.

L’orchestratore ha tutto — la cronologia della sessione, le direttive di progetto, le decisioni prese nei messaggi precedenti, il quadro complessivo dell’obiettivo. Il subagent riceve solo ciò che l’orchestratore decide di comprimere nel prompt di delega, e in più opera spesso con un set ridotto di skill e tool. Non sa cosa hai deciso dieci minuti fa. Non conosce le convenzioni del progetto se non gliele hai passate. Non ha letto il file di istruzioni con la stessa profondità.

La conseguenza pratica è che il parallelismo scambia contesto per throughput, e non è sempre uno scambio conveniente. Il caso in cui l’ho verificato con più chiarezza è la generazione di contenuti. Un agente principale che ha in contesto la knowledge base completa — briefing, tono, materiale di ricerca, vincoli editoriali — scrive bene. Lanciare dieci subagent in parallelo per produrre dieci contenuti dà un risultato di qualità sensibilmente inferiore: ognuno lavora sulla fetta di contesto che l’orchestratore ha saputo selezionare e comprimere, e se l’orchestratore sbaglia quella selezione — o semplicemente la tronca per stare nei limiti — il subagent produce un testo coerente ma povero, senza avere alcun modo di accorgersene.

Il criterio di delega che ne deriva è semplice: il subagent è adatto ai task che consumano molto contesto e ne restituiscono poco. Esplorare, cercare, leggere venti file e tornare con una sintesi di dieci righe è il caso d’uso ideale, perché il valore sta nella riduzione e il contesto necessario è tutto locale al task. Produrre qualcosa la cui qualità dipende dalla ricchezza del contesto è il caso d’uso peggiore.

Delegabile a subagent	Da tenere sull’agente primario
Esplorare, cercare, leggere molti file e restituire una sintesi	Generazione di contenuti che dipende da una knowledge base ampia
Verifiche meccaniche ripetute su molti oggetti omogenei	Decisioni che richiedono convenzioni e direttive di progetto
Lavoro divergente e indipendente, senza stato condiviso	Lavoro che si appoggia a quanto deciso nei messaggi precedenti
Task con criterio di successo verificabile e locale	Giudizio editoriale, tono, coerenza con il resto del progetto
Analisi di file voluminosi che saturerebbero il contesto principale	Task in cui l’errore di un pezzo invalida tutti gli altri

Esiste un pattern di mitigazione che (raramente) uso quando la delega parallela è necessaria: la doppia validazione dell’orchestratore. I subagent producono output in un formato fisso e prestabilito, e l’orchestratore, che il contesto completo ce l’ha, ricontrolla ogni risultato prima di consolidarlo. Costa un passaggio in più e recupera (a volte) buona parte della qualità persa nella delega.

Quattro casi reali

Per ogni caso: obiettivo, strumenti collegati, cosa ha fatto l’agente da solo, e soprattutto cosa ho dovuto correggere. L’ultimo punto è quello che non trovi negli articoli promozionali sul tema.

Audit dei dati strutturati con un server MCP

Obiettivo: validare i dati strutturati di un sito template per template, individuando gli errori semantici che i validatori tradizionali non intercettano — date hardcoded, tipi di dato sbagliati, nomi autore rimasti a placeholder, valute incoerenti.

Strumenti: Claude Code con il server MCP di Schema.org, HTML statici salvati manualmente dal browser per catturare il markup generato in JavaScript, subagent paralleli per l’analisi dei singoli template.

Cosa ha fatto da solo: ha generato il manifesto dei file in input, analizzato ogni template in parallelo producendo un output in formato fisso con priorità P0/P1/P2, riverificato il JSON-LD proposto contro l’MCP e prodotto le tabelle di mappatura delle variabili per CMS.

Cosa ho dovuto correggere: il limite più serio è che l’agente non distingue fra “valido secondo Schema.org” e “supportato da Google per i rich result”. Sono due insiemi che si sovrappongono solo in parte. Ogni JSON-LD proposto va testato con il Rich Results Test prima di andare in produzione. In più lo snapshot HTML fotografa uno stato solo: con test A/B o personalizzazione geografica l’analisi rischia di non essere rappresentativa, e la mappatura delle variabili va confermata con chi conosce il CMS di destinazione. La pipeline completa è documentata in audit dei dati strutturati con Claude Code e server MCP Schema.org.

Analisi di traffico con Search Console e DataForSEO

Obiettivo: interrogare conversazionalmente i dati reali di traffico e di SERP senza scrivere uno script per ogni domanda.

Strumenti: server MCP di DataForSEO per SERP, keyword e backlink, più un server custom in Python per GA4 e la connessione a Search Console.

Cosa ha fatto da solo: ha orchestrato catene multi-step senza che io scrivessi codice per estrarre le SERP italiane per una query, recuperare le keyword posizionate e gli URL, incrociare i dati ed esportare in CSV.

Cosa ho dovuto correggere: i problemi non sono stati di ragionamento ma di infrastruttura e di interpretazione. I dati di Google Analytics 4 hanno circa 24 ore di latenza e quelli di Search Console tre giorni: se non lo dici all’agente, ti costruisce un’analisi su un buco. Le API lente vanno paginate perché il timeout tipico è intorno ai 60 secondi. Tutti i dettagli, gotcha di Windows compresi, sono in Server MCP con Claude Code: guida pratica.

Scrittura e revisione dei contenuti del blog

Obiettivo: portare un articolo dalla bozza alla pubblicazione mantenendo tono, struttura e correttezza tecnica.

Strumenti: istruzioni di progetto con il briefing editoriale, accesso in scrittura alla REST API di WordPress, completa conoscenza del tema e dei blocchi Gutenberg, validatore HTML eseguito come passaggio obbligatorio.

Cosa ha fatto da solo: stesura, conversione in blocchi, applicazione delle convenzioni di anchor e struttura.

Cosa ho dovuto correggere: qui si trova il fallimento più istruttivo di tutti, ed è silenzioso. Un singolo tag non chiuso nell’HTML non genera alcun errore: l’API lo accetta, l’editor non protesta, il contenuto sembra salvato correttamente. Ma il parser HTML5 del browser, applicando il foster parenting, annida tutto il resto dell’articolo dentro l’elemento rimasto aperto e il rendering si rompe. Peggio: se chiedi all’agente di rileggere il contenuto per verificarlo, il parser permissivo che userebbe gli mostra una struttura piatta e corretta. L’agente conferma che è tutto a posto, in buona fede, e sbaglia. L’unica soluzione è un validatore esterno che confronti gli elementi root attesi con quelli reali usando lo stesso parser del browser. È il caso da manuale del principio generale: la verifica non può stare dentro il sistema che deve verificare.

Come sbagliano gli agenti: una tassonomia della pigrizia

Dopo un anno di uso quotidiano, l’osservazione che mi sento di difendere è questa: gli agenti raramente sbagliano perché non sanno. Sbagliano perché prendono la scorciatoia. Il loro criterio interno di “fatto” non coincide con il nostro, e ottimizzano per chiudere il task, non per chiuderlo bene.

Vediamo cinque modalità ricorrenti, in ordine crescente di insidiosità.

1. Skill disponibile, non invocata. Lo strumento è collegato, funzionante, documentato e l’agente risponde senza usarlo. Il caso tipico è lo skill o il tool di verifica che esiste apposta per quel task e che viene saltato perché il modello “sa già” la risposta.
2. Direttiva ignorata. La regola è scritta nelle istruzioni di progetto, l’agente la legge e procede diversamente perché la sua soluzione gli sembra migliore. È il motivo per cui le direttive vanno formulate come divieti espliciti e non come preferenze.
3. Memoria al posto della fonte. L’agente ha accesso alla fonte autorevole, ad esempio l’API, il file, la documentazione, etc e risponde invece dalla memoria parametrica. È il fallimento più insidioso perché il risultato è plausibile: numeri verosimili, URL ben formati, nomi di funzione che suonano giusti. Non sembra un errore, sembra una risposta.
4. Distruzione di dati. Cancella o sovrascrive ciò che non doveva, tipicamente durante operazioni di riordino o pulizia in cui il criterio di “superfluo” è stato lasciato implicito.
5. “Fatto” dichiarato su lavoro incompleto. La dichiarazione di completamento non è una prova di completamento. Un task chiuso a metà con un riepilogo sicuro di sé è indistinguibile, nel testo, da un task chiuso davvero.

Questa non è una peculiarità del mio setup: è il modo in cui i sistemi ottimizzati su un criterio di successo si comportano quando il criterio è più debole dell’obiettivo reale. Lo dimostra il dato più imbarazzante del 2026 sui benchmark, che vediamo tra poco.

Le regole che ne ho ricavato e che applico senza eccezioni sono:

• verificare sempre, soprattutto quando sembra tutto corretto;
• fare un backup prima di partire;
• versionare tutto il codice su git.

I numeri che i vendor non citano

I dati che seguono sono tutti pubblici e tutti citati raramente nelle presentazioni commerciali. Li riporto con le fonti e con i limiti che le fonti stesse dichiarano.

Lo studio METR: 19% più lenti, convinti di essere più veloci. Nel 2025 METR ha condotto un esperimento controllato randomizzato, il disegno sperimentale più solido disponibile, su 16 sviluppatori open source esperti impegnati su 246 task reali in repository di cui erano manutentori. Risultato: con gli strumenti AI hanno impiegato il 19% di tempo in più. Prima dello studio prevedevano un’accelerazione del 24%; dopo averlo completato, e dopo essere stati più lenti, credevano ancora di essere andati il 20% più veloci. Gli autori dichiarano esplicitamente i limiti: campione di 16 persone, strumento dell’epoca (Cursor Pro con Claude 3.5/3.7 Sonnet), partecipanti con circa 50 ore di esperienza sullo strumento, e repository che conoscevano a fondo da anni. Lo studio non dimostra che l’AI rallenti la maggior parte degli sviluppatori. Dimostra qualcosa di più utile: che la percezione della propria produttività, in questo campo, non è una misura affidabile.

Il delegation gap. Secondo il 2026 Agentic Coding Trends Report di Anthropic, gli sviluppatori usano ormai l’AI in circa il 60% del proprio lavoro, ma dichiarano di poter delegare completamente solo tra lo 0 e il 20% dei task: l’80-100% di ciò che delegano resta sotto supervisione attiva. Nello stesso report, circa il 27% del lavoro AI-assistito consiste in attività che prima semplicemente non venivano svolte (il che significa che gli agenti allargano il backlog invece di svuotarlo) e la media di azioni autonome consecutive prima che serva un intervento umano è di circa 20, raddoppiata in sei mesi.

GitClear: il codice funziona e invecchia peggio. L’analisi di 623 milioni di modifiche fra il 2023 e il 2026 mostra segnali coerenti di degrado della manutenibilità. La duplicazione di blocchi è passata da 40,3 a 73,0 per milione di righe modificate (+81% sul 2023, massimo storico). Il copia-incolla è salito dal 9,4% (2022) al 15,7% del primo semestre 2026, mentre il codice spostato o riusato (la firma del refactoring) è crollato dal 21% (2022) al 3,8%. Le chiamate fra metodi per mille righe sono scese del 35%, e le modifiche che toccano codice più vecchio di dodici mesi sono passate dall’1,7% allo 0,46%: il codice legacy viene sempre meno manutenuto e sempre più aggirato.

DORA: la J-curve e le due tasse. Il report DORA sul ROI dello sviluppo AI-assistito descrive un andamento a J: prima del guadagno c’è un calo di produttività, che gli autori attribuiscono a due voci esplicite. La verification tax, cioè il costo di revisione del codice generato, e la instability tax, cioè il rischio che una maggiore velocità di produzione saturi le pipeline di rilascio e faccia salire il tasso di fallimento dei cambiamenti. La conclusione del report è che il ritorno dipende dal sistema organizzativo (qualità della piattaforma interna, pratiche di versionamento, test automatici, governance) molto più che dallo strumento scelto. Le stime economiche, precisano gli autori, sono ad alta incertezza e servono ad avviare una discussione, non a fare un business plan.

I benchmark misurano la cosa sbagliata. È il dato che chiude il cerchio con la tassonomia della sezione precedente. Lo studio SWE-ABS del 2026 ha rafforzato le suite di test di SWE-bench Verified e ha scoperto che il 19,78% delle patch considerate risolte dagli agenti in cima alla classifica è semanticamente sbagliato: passava solo perché i test erano troppo deboli per accorgersene. Applicando la valutazione rafforzata, il punteggio del miglior agente scende dal 78,80% al 62,20%, con un rimescolamento sostanziale della leaderboard. Il benchmark misura “i test passano”. Non misura “il codice è giusto”. E un agente ottimizzato per far passare i test impara esattamente quello.

Gartner [citato ad inizio post]: oltre il 40% dei progetti agentici cancellati entro il 2027, per problemi di governance, valore di business non definito e disciplina operativa insufficiente — non per limiti dei modelli.

Cosa dicono questi dati? Dicono che il lavoro non sparisce, si sposta. Diminuisce il tempo di produzione, aumenta quello di specifica e verifica. Se quel secondo tempo non viene organizzato, se non hai validatori, test, backup, diff da leggere, si mangia il guadagno e in più lascia dietro di sé il debito che GitClear misura. È esattamente la J-curve di DORA vista dall’interno.

Sicurezza: il perimetro dell’agente

Il rischio dominante dei sistemi agentici nel 2026 è la prompt injection indiretta, e l’edizione 2026 del report OWASP sulle applicazioni agentiche la documenta ormai con CVE e advisory reali.

Il problema è architetturale, non un bug da correggere: per un LLM istruzioni e dati arrivano nello stesso flusso di token. Non esiste un canale separato che marchi “questo è un comando dell’utente” e “questo è contenuto da leggere”. Un’istruzione ostile nascosta in una pagina web, in un documento o in una risposta API ha, dal punto di vista del modello, la stessa natura della tua richiesta.

Il framework più utile per valutare il proprio setup è la lethal trifecta descritta da Simon Willison nel 2025. Un sistema è vulnerabile quando ha simultaneamente tre proprietà:

1. Accesso a dati privati — può leggere file, email, database, credenziali.
2. Esposizione a contenuti non fidati — legge testo che qualcun altro può controllare.
3. Un canale di uscita — può fare richieste di rete, chiamare API, generare link.

Con tutte e tre presenti, un’istruzione ostile può farsi leggere i dati privati e farli uscire. La mitigazione più solida disponibile oggi è la Rule of Two pubblicata da Meta nell’ottobre 2025: mai più di due delle tre proprietà nello stesso contesto operativo. Non è un filtro sugli input né un classificatore, è un vincolo architetturale — e questo è precisamente il motivo per cui funziona, visto che non esiste una difesa affidabile a livello di prompt.

Due implicazioni che riguardano direttamente chi fa questo lavoro.

Se il tuo agente naviga il web, sei già nella condizione 2. Un agente con Playwright collegato, o con un crawler, o che legge le SERP, ingerisce contenuto di terzi per definizione. È la configurazione più comune nel lavoro SEO ed è quella in cui il rischio viene percepito meno, perché il contenuto sembra “solo dati”.

I dati sensibili vanno tenuti fuori dal perimetro. Usi agenti anche per l’archiviazione documentale domestica, referti medici inclusi? È esattamente il tipo di dato che non deve mai coesistere con navigazione web e canale di uscita nella stessa sessione: dati privati, contenuto non fidato e rete insieme sono la trifecta al completo, in casa propria. La soluzione non è rinunciare all’automazione, è separare i contesti, sessioni diverse, permessi diversi, nessuna rete dove ci sono i dati.

Va aggiunto un dettaglio spesso ignorato: anche le descrizioni dei tool di un server MCP entrano nel contesto del modello. Un server MCP di terze parti installato senza guardarne il sorgente è una superficie di attacco, non solo una dipendenza.

Metodo operativo: come si lavora con un agente senza farsi male

Il metodo che segue è il residuo di un anno di uso quotidiano, errori compresi. È ordinato per importanza, non per sequenza temporale.

1. Backup prima di partire. Non negoziabile, e vale il doppio per le operazioni di riordino, pulizia e rinomina di massa.
2. Tutto versionato su git. Branch dedicato, commit frequenti, mai lavorare direttamente sul ramo principale. Il diff è l’unità di revisione: se non leggi il diff non stai delegando, stai sperando.
3. Verificare sempre, soprattutto quando sembra tutto corretto. L’output plausibile è più pericoloso dell’output palesemente rotto, perché non attiva il sospetto.
4. Scegliere task verificabili, non task facili. La variabile che predice il successo non è la difficoltà, è l’esistenza di un criterio di successo controllabile: test che passano, validatore che dà OK, valore che torna con la fonte.
5. Scrivere il file di istruzioni prima del primo prompt, e formulare le regole critiche come divieti espliciti.
6. Chiudere il perimetro: allowlist esplicita, credenziali fuori dal contesto, nessun accesso di rete dove non serve.
7. Far produrre il piano prima dell’esecuzione e leggerlo. Un piano sbagliato si corregge in trenta secondi; un’esecuzione sbagliata richiede di ricostruire cosa è successo.
8. Usare un verificatore esterno all’agente. Un sistema non può essere l’unico giudice del proprio operato: è il principio che rende inutile chiedere all’agente “hai controllato?”.

Una sessione tipo, ridotta all’osso:

# 1. Rete di sicurezza prima di qualsiasi cosa
git checkout -b agent/refactor-parser
git status                      # deve essere pulito

# 2. Backup dei dati non versionati su cui si lavora
cp -r data/ data.bak/

# 3. Sessione con l'agente: prima il piano, poi l'esecuzione
#    (leggere il piano, correggerlo, solo dopo autorizzare)

# 4. Verifica esterna, non dichiarata dall'agente
venv/Scripts/python.exe -m pytest -q
venv/Scripts/python.exe skills/_html_validate.py --file output/draft.html

# 5. Revisione del diff, riga per riga
git diff --stat
git diff

Chi lavora abitualmente da terminale trova questo flusso naturale: ne ho scritto in fare SEO da terminale.

Quanto costa davvero

Sul costo diretto, gli ordini di grandezza per un uso professionale intensivo sono quelli di un abbonamento da 200€ al mese per persona (confrontabile con una singola licenza di un tool SEO di fascia media, e trascurabile rispetto al costo orario di chi lo usa).

Il costo che conta è un altro, e non compare in nessun listino: il tempo umano di verifica. È la verification tax di DORA, ed è la voce che decide se il bilancio è positivo. Un’organizzazione che triplica l’output senza toccare la capacità di revisione non ha triplicato la produttività: ha spostato il collo di bottiglia più a valle, dove costa di più: in code review, in bug, in incidenti di produzione.

Prima di calcolare il ROI di uno strumento agentico conviene calcolare quanto tempo di revisione qualificata si ha effettivamente a disposizione, perché è quello il fattore limitante.

Cosa cambia nel lavoro

Non faccio previsioni su quali mestieri esisteranno fra tre anni: sarebbero affermazioni non verificabili, ed è esattamente il genere di contenuto che non ha valore. Quello che si può osservare adesso, con i dati in mano, è dove si sposta il lavoro.

Il baricentro passa dal produrre allo specificare e verificare. Le competenze che acquistano valore in questo assetto sono tre, e nessuna è nuova:

• saper definire un criterio di verifica prima di iniziare,
• saper leggere un diff senza saltare le parti noiose,
• saper progettare permessi e perimetri.

Sono tutte competenze da revisore, non da esecutore.

Chi fa SEO tecnica parte avvantaggiato, perché è un mestiere che consiste già nel verificare che un sistema complesso faccia ciò che dichiara di fare. È la stessa disciplina applicata a un oggetto diverso.