L’AI non è più un chatbot: ora il software agisce

AI / AGENTI / SOFTWARE

Per anni abbiamo discusso di intelligenza artificiale come se il problema fosse capire quanto bene sapesse rispondere. Nel 2026 la domanda utile è diventata un’altra: che cosa succede quando il software non si limita a rispondere, ma può agire, spendere risorse e modificare sistemi?

È il filo che attraversa il keynote con cui Simon Willison ha ricostruito il 2026 degli LLM. La sua lettura parte da un passaggio che molti sviluppatori hanno percepito direttamente: tra la fine del 2025 e l’inizio del 2026 i coding agent hanno superato, almeno per una parte dei lavori quotidiani, quella soglia invisibile che separa una demo interessante da uno strumento che vale la pena lasciare lavorare.

Il punto però non è celebrare l’ennesimo modello più bravo. Anzi. La cosa interessante è che, proprio quando generare codice diventa più facile, il lavoro di ingegneria si sposta verso ciò che non possiamo delegare alla cieca: obiettivi, confini, verifiche, costi e responsabilità.

La soglia importante non è l’intelligenza. È l’autonomia

Un chatbot sbaglia una risposta e, nella maggior parte dei casi, produce una risposta sbagliata. Un agente che dispone di shell, repository, browser, API o credenziali applicative può trasformare un errore di ragionamento in un cambiamento reale. È una differenza architetturale prima ancora che filosofica.

Willison descrive il salto dei coding agent da strumenti che «spesso fanno errori» a sistemi abbastanza affidabili da entrare nel lavoro di tutti i giorni. È una valutazione personale, non una misura universale: modelli, harness, task e ambienti cambiano troppo perché abbia senso trasformarla in una percentuale assoluta. Ma il segnale operativo è evidente. Sempre più lavoro software viene affidato a processi che leggono un obiettivo, esplorano un ambiente, modificano file, lanciano test e decidono il passo successivo.

Questa è anche la ragione per cui trovo poco interessante chiedermi se «l’AI sa programmare». È una domanda già vecchia. La domanda utile è: quale perimetro posso affidarle senza perdere il controllo del sistema?

Più capacità significa più superficie di errore

Nel software tradizionale cerchiamo di ridurre gli stati imprevisti. Con gli agenti introduciamo deliberatamente un componente capace di scegliere percorsi che non abbiamo enumerato in anticipo. È esattamente ciò che li rende utili ed è esattamente ciò che li rende difficili da governare.

Gli episodi di sicurezza emersi nel 2026 rendono il problema meno teorico. A settembre, Ars Technica ha documentato il caso di migliaia di agenti che, durante attività di test, avevano pubblicato messaggi su un wiki pubblico discutendo anche tecniche per aggirare restrizioni di sandbox. Pochi giorni dopo, altre indagini hanno continuato a mostrare quanto sia difficile osservare sistemi agentici che operano su scala e velocità superiori alla revisione umana.

Non serve trasformare questi casi in fantascienza. La lezione è più banale e quindi più utile: se concediamo a un processo autonomo capacità operative, dobbiamo progettare anche il modo in cui quelle capacità vengono limitate, osservate e revocate. Vale per un agente AI come vale per qualunque altro componente privilegiato.

Il nuovo stack: obiettivo, capacità, verifica

Per me un sistema agentico serio dovrebbe essere letto almeno su tre livelli.

• Obiettivo: che cosa gli stiamo chiedendo davvero e quali ambiguità gli stiamo lasciando risolvere da solo?
• Capacità: quali file, API, credenziali, reti e operazioni può raggiungere durante l’esecuzione?
• Verifica: quale evidenza deve produrre prima che il risultato venga considerato valido?

Il terzo punto è quello che rischia di essere sacrificato per primo. Quando un agente produce rapidamente qualcosa che sembra corretto, la tentazione è misurare il successo sulla presenza dell’output: il codice compila, la pagina esiste, il task è chiuso. Ma un output plausibile non è una verifica.

Nel mio lavoro preferisco trattare l’automazione come una catena di evidenze. Un task non è concluso perché l’agente dice di averlo concluso. È concluso quando il risultato può essere controllato con un test, un read-back, uno stato osservabile o un’altra condizione indipendente dall’affermazione dell’agente. È lo stesso principio che uso quando parlo di misurare e isolare il problema prima di automatizzare: l’automazione viene dopo l’osservabilità, non al posto dell’osservabilità.

Il costo diventa parte dell’architettura

C’è poi un vincolo meno spettacolare della sicurezza ma molto più quotidiano: il costo. Un chatbot consuma risorse mentre gli parliamo. Un agente può aprire sessioni lunghe, iterare, usare strumenti, generare e scartare tentativi, avviare altri processi. La sua unità economica non è più soltanto «una risposta».

Questo cambia il modo in cui va progettato il sistema. Se un agente può scegliere autonomamente quanto lavoro fare, il budget non può essere una sorpresa scoperta a fine mese. Servono limiti per task, politiche di retry, checkpoint, priorità, criteri di arresto e telemetria. In altre parole, servono le stesse cose noiose che rendono affidabile qualsiasi infrastruttura. Che peccato: anche l’AI rivoluzionaria alla fine incontra i contatori.

Dal software per persone al software per attori non umani

Questo passaggio modifica anche le interfacce. Ho già scritto, parlando della CLI cf di Cloudflare e del software progettato anche per utenti non umani, che un agente ha bisogno di contratti più espliciti: output prevedibili, errori leggibili, operazioni idempotenti, permessi chiari. Se il software viene usato da un processo automatico, le ambiguità che una persona risolve intuitivamente diventano debito operativo.

Willison estende questa traiettoria oltre lo sviluppo software, descrivendo la crescita dei personal agent: strumenti che prendono la logica dei coding agent e la applicano a compiti più generali. È qui che il tema diventa davvero interessante. Quando l’agente esce dall’IDE, incontra posta, documenti, acquisti, account, dati personali e servizi esterni. Aumenta il valore possibile, ma aumentano nello stesso momento le conseguenze di una decisione sbagliata.

Non serve meno controllo umano. Serve controllo umano migliore

Dire che «l’umano deve restare nel loop» è corretto ma insufficiente. Se un agente esegue cento azioni al minuto, mettere una persona davanti a cento finestre di conferma non è governance: è un CAPTCHA inflitto al dipendente.

Il controllo deve spostarsi a monte e a valle. A monte definiamo policy, capacità, budget e condizioni di stop. A valle verifichiamo risultati e invarianti. Nel mezzo lasciamo all’agente lo spazio necessario per essere utile. È molto più simile alla progettazione di un sistema distribuito che alla supervisione di uno stagista digitale.

Questa distinzione diventa ancora più importante quando aumentano parallelismo e durata. Un agente che lavora per trenta secondi può essere seguito quasi passo per passo. Dieci agenti che lavorano per ore richiedono un’altra architettura: lease, ownership, log, checkpoint, isolamento, limiti di concorrenza e verifiche automatiche. Non perché siano «intelligenti», ma perché sono processi autonomi che modificano stato.

Il paradosso del 2026: produrre è più facile, decidere è più difficile

La parte più interessante del keynote di Willison non è la cronologia dei modelli. È il paradosso che emerge alla fine: gli strumenti accelerano il lavoro facile e lasciano agli esseri umani una concentrazione sempre maggiore di problemi difficili.

Se produrre una prima implementazione costa meno, possiamo tentare più strade. Ma qualcuno deve scegliere quali strade meritano di esistere. Se generare codice costa meno, cresce il codice che possiamo produrre. Ma cresce anche ciò che dobbiamo verificare, mantenere, proteggere e magari cancellare. Se un agente può lavorare mentre dormiamo, dobbiamo essere ancora più precisi su ciò che gli è consentito fare quando non lo stiamo guardando.

Per questo non credo che il passaggio decisivo del 2026 sia stato avere chatbot più intelligenti. Il passaggio è stato cominciare a costruire software che agisce. E appena il software agisce, tornano al centro le discipline che l’hype vorrebbe farci dimenticare: architettura, sicurezza, osservabilità, costi e verifica.

La buona notizia è che non dobbiamo inventarle da zero. Sono esattamente le competenze che servivano prima dell’AI. Solo che adesso dobbiamo applicarle a componenti che non si limitano più a eseguire il percorso che abbiamo scritto riga per riga.