OpenAI ha reso disponibile in generale per Codex il supporto ai subagents, dopo alcune settimane di preview dietro un feature flag. L’annuncio, riportato da Simon Willison, conferma l’integrazione di un pattern già diffuso in altri ambienti di sviluppo assistito da AI. Il sistema prevede subagents predefiniti denominati ‘explorer’, ‘worker’ e ‘default’. La documentazione non chiarisce completamente la distinzione tra ‘worker’ e ‘default’, ma un esempio con CSV suggerisce che ‘worker’ sia ottimizzato per l’esecuzione parallela di un gran numero di task di piccole dimensioni. La funzionalità permette inoltre di definire agenti personalizzati come file TOML nella directory ~/.codex/agents/. Questi agenti custom possono includere istruzioni specifiche e essere configurati per utilizzare modelli particolari, incluso gpt-5.3-codex-spark per operazioni che richiedono massima velocità. Una volta definiti, possono essere richiamati per nome all’interno dei prompt, come dimostra l’esempio ufficiale che coinvolge agenti specializzati in debug, mappatura del codice e riparazione dell’interfaccia utente.
Questa evoluzione di Codex ha un impatto diretto sugli sviluppatori e sui team di ingegneria del software che utilizzano assistenti AI per il coding. Il pattern dei subagents permette di scomporre problemi complessi, come il debugging di una feature o la refattorizzazione di un modulo, assegnando sotto-task specifici ad agenti con competenze dedicate. Un agente ‘explorer’ può analizzare il codice per identificare le cause di un bug, mentre un ‘worker’ può applicare sistematicamente una modifica a decine di file. La possibilità di creare agenti personalizzati con istruzioni e modelli dedicati consente di standardizzare flussi di lavoro ripetitivi all’interno di un’organizzazione, riducendo il tempo di scrittura dei prompt e aumentando la coerenza del codice generato. Questo approccio modulare si allinea con le implementazioni di altre piattaforme, come Claude Code, indicando la convergenza verso un paradigma comune per l’ingegneria agentica nello sviluppo software.
La fonte originale non menziona esplicitamente limiti o rischi. Tuttavia, l’architettura a subagents introduce complessità gestionale. La definizione, il mantenimento e il versioning dei file TOML per gli agenti custom diventano un asset da gestire, con il rischio di creare una proliferazione di agenti poco documentati o obsoleti. L’assegnazione di task a subagents richiede una scomposizione logica accurata del problema da parte dell’utente; un prompt mal formulato può portare a un coordinamento inefficace tra gli agenti, con risultati incoerenti o incompleti. L’uso di modelli diversi per agenti diversi, sebbene potenzialmente ottimale per le performance, potrebbe aumentare i costi computazionali e monetari. Inoltre, il debugging del flusso di lavoro diventa più articolato, poiché è necessario tracciare l’output e le decisioni di più entità autonome invece di un singolo agente monolito.
Il rilascio dei subagents in Codex consolida un trend emerso negli ultimi mesi: il passaggio da agenti AI generici a ecosistemi di agenti specializzati che collaborano. Questo modello, documentato ormai su diverse piattaforme, rappresenta un’evoluzione significativa verso sistemi di AI più strutturati e capaci di gestire workflow complessi. Lo sviluppo futuro potrebbe vedere l’integrazione di meccanismi di comunicazione più sofisticati tra subagents, forse ispirati a framework di orchestrazione come LangGraph o a pattern di ricerca e pianificazione. Rimane aperta la questione dell’ottimizzazione del trade-off tra la flessibilità offerta dalla personalizzazione e la semplicità d’uso. Per un team di sviluppo, la domanda pratica diventa come bilanciare l’investimento nella creazione di una libreria di agenti interni con i benefici tangibili in termini di velocità e qualità del codice prodotto.
Alessio Baronti
Consulente Strategico AI & Sviluppatore Web
