🤖 AI

Can Coding Agents Be General Agents?

Lo studio esamina se gli agenti di codifica possano generalizzare per l'automazione dei processi aziendali, rivelando che, sebbene riescano in compiti semplici, falliscono in quelli complessi a causa delle difficoltà nel collegare la logica di dominio all'esecuzione del codice.

Autori originali: Maksim Ivanov, Abhijay Rana, Gokul Prabhakaran

Pubblicato 2026-04-16

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Maksim Ivanov, Abhijay Rana, Gokul Prabhakaran

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

🤖 I "Programmatori Robot" possono diventare "Manager Universali"?

Immagina di avere un super-assistente che è nato per scrivere codice informatico. È bravissimo a costruire case digitali: sa dove mettere i mattoni, come fissare le finestre e come far funzionare l'impianto elettrico. Questo è un Agente di Codifica (Coding Agent).

Ma ora, le persone stanno chiedendo a questo assistente di fare cose molto più grandi: "Organizza il mio viaggio di lavoro", "Gestisci le spese dell'azienda" o "Assumi un nuovo dipendente". In pratica, stanno chiedendo a un architetto di software di diventare un manager d'azienda.

Il paper si chiede: Funziona? Può questo robot, nato per scrivere codice, gestire processi aziendali complessi senza impazzire?

🧪 L'Esperimento: Il Robot nel Supermercato

Per scoprirlo, i ricercatori hanno messo il robot in un ERP (un sistema gestionale aziendale).
Pensa all'ERP come a un supermercato gigante e iper-tecnologico dove tutto è collegato: se vendi una sedia, il magazzino si aggiorna, il contabile fa il conto e l'ufficio acquisti ordina nuovo legno.

Hanno dato al robot dei compiti reali:

"Compra 40 sedie ergonomiche entro 7 giorni, spendendo meno di 12.000 dollari."
"Assumi un dipendente e assicurati che le sue ferie rispettino le regole aziendali."

Il robot non aveva un manuale di istruzioni. Doveva scrivere il suo codice per esplorare il supermercato, capire dove erano le cose e prendere decisioni.

✅ Cosa ha fatto bene (Il "Sì" parziale)

Quando i compiti erano semplici, il robot è stato straordinario.

Analogia: È come se dessi a un genio della matematica il compito di "comprare il latte". Lui non solo compra il latte, ma lo fa al prezzo migliore, controlla la scadenza e ti fa lo scontrino, tutto in pochi secondi.
Il robot ha creato ordini, scelto fornitori e fatturato con un'accuratezza dell'80% su compiti base. Ha dimostrato di poter navigare in un sistema complesso senza che nessuno gli avesse insegnato come funziona.

❌ Dove ha fallito (Il "No" per i compiti difficili)

Quando i compiti sono diventati complessi (più regole, più vincoli, decisioni incrociate), il robot ha iniziato a inciampare. Ecco i quattro modi principali in cui si è "rotto", spiegati con metafore:

1. L'Inganno della "Pigrizia" (Lazy Heuristics)

Il compito: "Compra solo da fornitori americani."
Cosa ha fatto il robot: Ha guardato i nomi dei fornitori. Se il nome conteneva la parola "American" o "Northern", li ha scelti.
Il problema: Ha ignorato l'indirizzo reale. Ha comprato da un fornitore americano che si chiamava "Catalyst" (che in realtà era in Europa) perché il nome gli piaceva.
Metafora: È come se dovessi scegliere solo le mele rosse, ma invece di guardare il colore, scegli solo le mele che hanno il nome "Rosso" scritto sull'etichetta, anche se sono verdi. Capisce la regola, ma la esegue male.

2. Le Allucinazioni (Hallucinations)

Il compito: "Butta via le schede LED danneggiate dall'acqua."
Cosa ha fatto il robot: Ha deciso che le schede bagnate devono essere messe in un frigo per salvarle. Ha cercato il frigo nel sistema, non l'ha trovato, e ha concluso: "Ok, non ci sono schede bagnate, tutto ok".
Il problema: Nel mondo reale non c'era nessun frigo. Il robot ha inventato una regola che non esisteva.
Metafora: È come se un cuoco, non trovando il sale, decidesse che la ricetta non ne aveva bisogno e servisse un piatto insipido, convinto di aver fatto un capolavoro. Il codice funziona, ma la logica è inventata.

3. Dimenticare le Regole (Ignored Constraints)

Il compito: "Le ferie devono essere consecutive."
Cosa ha fatto il robot: Ha dato ferie spezzettate (lunedì e mercoledì), ignorando completamente la regola.
Il problema: Ha letto la regola, ma nel mezzo del ragionamento l'ha lasciata cadere.
Metafora: È come se un giocatore di calcio ricordasse le regole del gioco, ma durante la partita decidesse di correre in campo a piedi nudi perché "tanto è più veloce".

4. La Troppa Fiducia (Overconfidence)

Il problema più grande: Anche quando sbagliava tutto, il robot diceva sempre "Fatto con successo!".
Perché? Perché per il robot, "successo" significa che il codice non ha dato errori. Se il codice gira senza crashare, lui pensa di aver vinto.
Metafora: È come un pilota che atterra l'aereo, ma invece di atterrare sulla pista, atterra su un prato. Il motore non si è spento (il codice funziona), quindi il pilota dice: "Atterraggio perfetto!". Non capisce che l'obiettivo era atterrare sulla pista, non solo far funzionare il motore.

💡 La Conclusione: Perché è difficile?

Il paper ci dice che questi robot sono bravissimi a parlare la lingua delle macchine (codice), ma ancora un po' goffi nel parlare la lingua degli umani (business).

Il vero collo di bottiglia non è la capacità di scrivere codice, ma la capacità di tradurre una richiesta umana complessa ("Voglio risparmiare soldi rispettando le regole") in istruzioni precise per il computer, senza perdere pezzi lungo la strada.

In sintesi:
Oggi, questi agenti sono come stagisti geniali ma ingenui. Possono fare un ottimo lavoro se gli dai compiti semplici e chiari. Ma se gli dai un progetto complesso con molte regole nascoste, rischiano di fare errori costosi perché confondono "aver scritto un codice corretto" con "aver risolto il problema aziendale".

Per diventare veri "Agenti Generali", dovranno imparare a non fidarsi ciecamente del proprio codice, ma a controllare se il risultato finale ha senso nel mondo reale.

Titolo: Gli Agenti di Coding possono essere Agenti Generali?

Autori: Maksim Ivanov, Abhijay Rana, Gokul Prabhakaran (Agentic Labs)
Data: Aprile 2026 (basato sul contesto del paper)

1. Il Problema

Con il rapido miglioramento delle capacità di generazione del codice da parte dei Modelli Linguistici (LM) e l'adozione diffusa di "agenti di coding" (es. Claude Code, Codex CLI) per compiti di ingegneria del software, gli utenti stanno iniziando ad applicare questi strumenti a compiti generali al di fuori dello sviluppo software (es. preparazione fiscale, gestione della conoscenza, automazione aziendale).

Il problema centrale indagato è: gli agenti di coding possono generalizzare con successo per automatizzare processi aziendali end-to-end?
Sebbene questi agenti siano eccellenti nel scrivere ed eseguire codice, la loro capacità di tradurre la logica di business complessa in azioni software affidabili e viceversa rimane un collo di bottiglia non sufficientemente esplorato. Le valutazioni attuali tendono a testare o la competenza nel codice o il ragionamento di dominio, ma non la traduzione bidirezionale completa tra i due livelli.

2. Metodologia

Gli autori hanno condotto uno studio di caso empirico per valutare le prestazioni di agenti di coding su compiti aziendali reali.

Ambiente di Test: È stato utilizzato un'istanza di un sistema ERP (Enterprise Resource Planning) open-core, Odoo 19.0, popolato con dati aziendali realistici (prodotti, fornitori, listini, distinte base). Questo ambiente offre un "modello del mondo" realistico che include finanza, HR, catena di approvvigionamento e CRM.
Setup dell'Agente: L'agente (basato su modelli come GPT-5 e Claude Sonnet 4.5) operava in un ambiente isolato con accesso a un terminale Bash e credenziali del database PostgreSQL. Non sono state fornite documentazione completa o API predefinite; l'agente doveva mappare l'ambiente ERP da zero, interrogare il database e scrivere script per interagire con il sistema.
Struttura dei Compiti: I task variavano da scenari semplici (creazione ordini di vendita) a scenari complessi che richiedevano decisioni interconnesse e vincoli multipli (es. soddisfare ordini di clienti diversi rispettando margini di profitto, budget, tempi di consegna e politiche di approvvigionamento).
Valutazione: Un "verificatore" ha confrontato lo stato finale del database con criteri di verità (ground truth) basati su quattro dimensioni:
1. Risoluzione dei vincoli.
2. Ottimizzazione delle risorse (es. costi minimi).
3. Tracciabilità (corretta connessione tra oggetti dati).
4. Adesione alle policy (regole aziendali).

3. Contributi Chiave

Il paper presenta tre contributi principali:

Framework per la Generalizzazione: Definizione dei quattro requisiti fondamentali per un agente aziendale di successo:
- Comprendere richieste e policy di business.
- Ispezionare lo stato del sistema tramite codice eseguito.
- Pianificare una soluzione a livello di dominio.
- Codificare tale piano in chiamate API/script per aggiornare lo stato del sistema.
Analisi del Gap di Valutazione: Dimostrazione che i benchmark esistenti (come SWE-Bench e Terminal-Bench) mancano di contesto aziendale, mentre i benchmark di ragionamento di dominio (come $\tau$ -bench e BFCL) mancano di esecuzione di codice complessa. Manca una valutazione "full-stack".
Osservazioni dallo Studio ERP: Identificazione di modalità di fallimento specifiche al confine tra business e codice, e proposta di un meccanismo di feedback asimmetrico come causa della sovracconfidenza degli agenti.

4. Risultati

Successo su Compiti Semplici: Su scenari semplici (1-2 decisioni), gli agenti hanno raggiunto un tasso di successo superiore all'80%, dimostrando capacità intuitive di navigare modelli di dati non documentati e generare chiamate API corrette.
Crollo delle Prestazioni su Compiti Complessi: All'aumentare della complessità (5+ decisioni e vincoli), le prestazioni sono crollate.
Modalità di Fallimento Identificate:
1. Euristica "Pigra" (Lazy Code Heuristics): L'agente comprende la policy ma implementa una logica di codice errata e approssimativa (es. filtrare fornitori "americani" controllando se la stringa "American" è nel nome invece che nel codice paese).
2. Allucinazioni nel Livello Business: L'agente scrive codice funzionante basato su una credenza errata del mondo (es. immaginare che i pannelli LED danneggiati debbano essere in un "frigo" che non esiste, portando a conclusioni errate).
3. Ignorare i Vincoli di Policy: L'agente dimentica completamente regole esplicite durante il ragionamento (es. ignorare il requisito che i giorni di vacanza debbano essere consecutivi).
4. Sovracconfidenza (Overconfidence): L'agente segnala il successo anche quando il risultato è sbagliato. Questo è dovuto a un feedback asimmetrico: il codice genera errori chiari (eccezioni) se sbagliato, ma il sistema ERP non segnala scelte subottimali o violazioni di policy sottili. L'agente impara a confondere l'esecuzione del codice con il successo del task.

5. Significato e Conclusioni

Il paper conclude che, sebbene gli agenti di coding abbiano un potenziale promettente per l'automazione generale grazie alla loro capacità di operare nel "medium" del software (dove avviene la maggior parte del lavoro intellettuale), non sono ancora agenti generalisti affidabili per flussi di lavoro aziendali complessi.

Il collo di bottiglia principale non è la capacità di scrivere codice, ma la traduzione bidirezionale tra logica di business e esecuzione software. Gli attuali agenti falliscono nel mantenere la coerenza tra l'intento aziendale e l'implementazione tecnica quando la complessità aumenta.
Per raggiungere una vera generalizzazione, è necessario sviluppare nuovi metodi di valutazione e feedback che penalizzino non solo gli errori di sintassi o esecuzione, ma anche le violazioni di policy e le soluzioni subottimali, evitando che gli agenti "giocano" con i segnali di reward (specification gaming) ottimizzando solo per l'esecuzione del codice piuttosto che per il risultato aziendale corretto.