Perché gli agenti AI funzionano nel coding e faticano altrove

Oggi quasi la metà degli agenti AI in circolazione viene utilizzata nello sviluppo software.

È un dato utile, ma non è quello interessante.

Quello interessante è tutto ciò che manca: customer service, finance, operations, logistica, manifattura, sanità. Aree enormi, che rappresentano ancora una piccola parte dell'utilizzo complessivo.

Guardando la distribuzione per ambito, lo stacco è netto: sotto lo sviluppo software non c'è un secondo posto vicino. Il primo inseguitore resta sotto il dieci per cento, e tutto il resto si divide briciole.

Il vantaggio nascosto del codice

Secondo me il motivo è semplice, e non ha a che fare con l'intelligenza dei modelli.

Nel coding l'agente ha un feedback loop chiuso e immediato. Il test passa o non passa. Il build compila o non compila. Il linter segnala o resta zitto.

L'agente sa nel giro di secondi se ha sbagliato, e può correggersi da solo.

È un ambiente raro: il giudizio sulla decisione arriva subito, è binario, ed è generato dal sistema stesso senza che nessuno debba fermarsi a scriverlo.

Nel mondo reale il segnale arriva tardi

Fuori dal codice cambia tutto. Il feedback loop è lento, ambiguo, quasi mai binario, e spesso va verificato da una persona.

Un agente che decide un riordino di magazzino scopre se ha fatto la scelta giusta settimane dopo, quando quel materiale serve davvero o resta fermo a scaffale.

Un agente che smista un ticket di assistenza lo scopre quando il cliente si lamenta di nuovo, o quando non si lamenta più e nessuno sa perché.

Un agente che programma una manutenzione lo scopre quando la macchina si ferma comunque, oppure quando non si ferma e non è chiaro se sia merito suo.

In tutti questi casi il giudizio esiste, ma è disperso nel processo. E quasi mai qualcuno lo restituisce esplicitamente al sistema che ha preso la decisione.

Non è un problema di modello

Qui sta il punto che mi sembra sottovalutato.

Non è un problema di capacità del modello. È un problema di integrazione: ERP, CRM, macchine, sensori, API, procedure interne non sono stati progettati per restituire un giudizio immediato su una decisione.

Sono stati progettati per registrare fatti, non per valutare scelte.

Un gestionale sa dirti che l'ordine è stato emesso. Non sa dirti che era un ordine sbagliato. Un CRM sa dirti che il ticket è stato chiuso. Non sa dirti che è stato chiuso male e riaperto tre giorni dopo con un altro titolo.

Finché quel segnale non esiste, un agente resta un esecutore che nessuno corregge. E un esecutore che nessuno corregge, prima o poi, viene tolto dal processo.

Dove vedo la prossima ondata

Nei progetti che seguiamo in Syncronika il punto critico non è quasi mai la scelta del modello.

È molto più concreto: dove prendiamo il segnale che dice all'agente se sta andando bene o male.

A volte è un dato che esiste già ma non viene letto. A volte va costruito, aggiungendo un passaggio di conferma, una misura a valle, un evento che prima nessuno registrava. A volte significa accettare che il giudizio resti umano, e progettare il flusso perché quella correzione torni indietro invece di perdersi.

È lavoro poco spettacolare. Ma è quello che separa un pilota che funziona in demo da un agente che resta acceso dopo sei mesi.

Con AgenVIO stiamo costruendo la piattaforma che rende possibile questo monitoraggio: orchestrare i processi tra persone, software e dispositivi, e soprattutto tenere traccia di cosa succede dopo una decisione.

Non per aggiungere dashboard. Per chiudere il cerchio.

In chiusura

Gli agenti hanno conquistato il coding perché il coding aveva già il feedback loop pronto.

Negli altri settori quel loop va costruito, ed è un lavoro di integrazione, di processo e di dato, non di prompt.

Chi lo fa per primo nel proprio dominio non ottiene solo agenti più affidabili. Ottiene uno strato operativo che migliora mentre lavora, invece di restare fermo al giorno in cui è stato acceso.