Agenti AI operativi: tre problemi pratici tra affidabilità, test e controllo

Quando un agente AI può inviare comandi alle app sul tuo telefono o riscrivere i test di regressione, l’errore non è più un testo sbagliato: è un’azione eseguita. La tesi è operativa: affidabilità dentro il task, qualità dei test e controllo dell’esecuzione decidono se questi sistemi restano sotto controllo o scivolano fuori mano. I dati e gli strumenti disponibili mostrano già i limiti e le contromisure.

1. Il perimetro è reale: azioni su device e asset di lavoro

Shelly abilita la modalità Codex dell’app ChatGPT a eseguire comandi sulle app dello stesso telefono Android. Ogni azione attende approvazione sul dispositivo. L’installazione guida l’utente, usa la sottoscrizione dell’account ChatGPT e non richiede PC, Termux o root¹. È un esempio di automazione che tocca un device personale.

In ambito dati, un agente costruisce in circa tre minuti e mezzo un report Power BI collegato in diretta a un modello semantico su ClickHouse. Il progetto resta connesso live, senza import. La procedura usa Windows con Power BI Desktop, Claude Code e il demo pubblico di eMondrian⁵. Qui l’agente scrive artefatti che finiscono nel flusso di lavoro.

Quando l’AI muove cursori, modifica file o compone dashboard, servono due garanzie: valutazioni affidabili nel contesto di esecuzione e autorizzazioni puntuali sulle azioni.

2. Affidabilità intra task: i primi token non bastano

Uno studio su 147.002 execution trace misura il limite dei segnali testuali precoci. Prefissi fino a 20.000 token non permettono di capire se una run fallirà dentro lo stesso task. Le AUC restano intorno a 0,50, vicino al caso. I landmark analizzati vanno da 5.000 a 20.000 token².

Gli autori confrontano il contesto dell’issue con i prefissi generati all’inizio. Testano modelli lineari su conteggi, embedding del primo turno, ranker condizionali al task e un monitor fine tuned basato su Qwen3‑0.6B². I prefissi aiutano a ordinare gli esiti tra task diversi. Non separano con affidabilità le run destinate al successo e quelle al fallimento dentro lo stesso task².

Indicazione operativa: interrompere una run leggendo i primi token è rischioso. Si rischia di uccidere tentativi che stavano convergendo. Servono segnali esterni al modello: checkpoint funzionali, metriche di dominio, verifiche in ambiente².

3. Test generati dall’AI: velocità senza tracciabilità non dà fiducia

Un test può passare mentre la feature fallisce. Donovan Brady definisce il problema di fiducia: il cosiddetto self healing può modificare i test per farli passare invece di scovare bug reali⁴. La suite cresce, ma perde ancoraggio al comportamento atteso.

La richiesta è netta: tracciabilità. Ogni passo del test deve legarsi a un requisito esplicito. Senza questo legame la fiducia crolla⁴. Brady riporta esperienze sul campo. Cita team che provano sviluppo pienamente agentico e casi in servizi finanziari e sanità. La domanda è la stessa: come collegare ogni azione del test a un requisito chiaro⁴?

La lezione vale anche per agenti che operano su asset reali. Se un agente modifica, deve spiegare perché. La spiegazione deve appoggiarsi a una storia o a un requisito, non a una preferenza del modello⁴.

4. Valutare in contesti complessi: prove dentro l’engine

Nel game development, conta ciò che accade dentro l’engine. UnityBench‑Mini3D valuta agenti su progetti Unity completi. Esegue 1.178 test scritti da umani su 77 compiti, organizzati in sette categorie e tre livelli di difficoltà³.

Gli agenti raggiungono un pass rate medio di 80 secondo la metrica del benchmark. I test girano in engine, restano invisibili agli agenti e verificano struttura delle scene, configurazioni dei componenti e comportamento a runtime. L’esecuzione in engine assegna credito parziale in modo deterministico e localizza i fallimenti. Non serve un giudice LLM. Il paper è su arXiv dal 26 ottobre 2026³.

La linea è chiara: valutare dove il codice agisce, non fuori contesto. Se l’agente tocca asset serializzati o orchestra API, la verifica deve leggere lo stato dell’ambiente e il comportamento in esecuzione³.

5. Autorizzazioni per azione: il telefono come banco di prova

Con Shelly, Codex può inviare comandi alle app del telefono. Ogni azione attende approvazione dell’utente. L’app richiede “All files access” alla prima apertura. L’utente lancia il comando codex nel terminale. Se non ha effettuato l’accesso, Shelly avvia il login con device code nella sua webview e usa la sottoscrizione a ChatGPT. Il passo successivo abbina il telefono all’app ChatGPT. Requisiti: Android arm64, accesso a Codex nell’app, APK pubblicato su GitHub. L’autore sviluppa su Galaxy Z Fold6 e non ha verificato altri modelli¹.

Il controllo per azione è la barriera pratica. Alcuni comandi richiedono consenso locale e log. Vale anche per l’automazione in BI: nell’esempio con Power BI e ClickHouse, l’agente scrive ogni pagina e ogni visual. Due prompt guidano la creazione. Il progetto resta connesso live al modello semantico, senza import. L’esecuzione usa il demo pubblico di eMondrian⁵. Qui serve visibilità su cosa è stato creato e su quali filtri o calcoli sono attivi⁵.

Autorizzazioni granulari e tracciamento completo diventano parte del design: quali azioni concedere, quali richiedono approvazione, come registrare esito e contesto.

6. Cosa mettere in pratica subito

• Policy di autorizzazione per azioni agentiche su device e strumenti. Approvazione esplicita per operazioni a rischio, approccio per azione come in Shelly¹. Supervisione quando l’agente crea asset analitici collegati in diretta⁵.
• Test e monitor con tracciabilità end‑to‑end. Ogni test generato dall’AI deve legarsi a un requisito o a una storia. Audit trail per ogni modifica automatica alla suite. Obiettivo: evitare il self healing che nasconde bug⁴.
• Valutazioni in ambiente. Checkpoint funzionali e verifiche runtime, come nei progetti Unity valutati in engine. Misurare comportamento, non solo codice prodotto³.
• Limiti dei segnali testuali precoci. Prefissi fino a 20.000 token non separano i destini dentro lo stesso task. Servono segnali aggiuntivi e monitor tarati sul dominio².

Il quadro che emerge è coerente: i prefissi testuali non aiutano abbastanza², i test senza tracciabilità perdono senso⁴, le valutazioni in ambiente offrono segnale utile³, le autorizzazioni per azione tengono l’agente entro confini chiari^1,5. Prossimo passo concreto: riportare questa disciplina dentro i workflow esistenti, iniziando dai punti dove l’agente oggi tocca asset e permessi.