Quando OpenAI racconta di sé, la storia è sempre impeccabile. Stavolta parla di una migrazione di massa: quasi tutti i dipendenti, il 98%, usano Codex, il suo agente di coding, contro il 40% di agosto 2025. Il dato arriva da un paper aziendale intitolato “The Shift to Agentic AI: Evidence from Codex”, pubblicato mercoledì. Il documento tratteggia un cambiamento profondo nel modo in cui la forza lavoro dell’azienda interagisce con l’intelligenza artificiale.

La notizia è rilevante perché segna il passaggio da assistenti conversazionali a sistemi agentici che scrivono, verificano e integrano codice in autonomia. Tuttavia, ogni percentuale proviene esclusivamente da OpenAI. Nessuna verifica esterna, nessun dettaglio su come l’azienda abbia misurato l’adozione effettiva o distinto uso superficiale da integrazione profonda. In un settore dove i vendor pubblicano numeri con la stessa facilità con cui rilasciano modelli, il contesto è tutto.

Cosa fa un agente di coding come Codex

Codex non è un normale chatbot. È un agente che opera all’interno dell’ambiente di sviluppo: prende in carico un task, consulta repository, scrive codice, esegue test e propone modifiche con un livello di autonomia impossibile per un assistente testuale. Questa architettura poggia su LLM specializzati nel ragionamento e nella generazione di codice, spesso affiancati da pipeline di retrieval augmentation e strumenti di esecuzione in sandbox.

Per le aziende che sviluppano software, il passaggio a strumenti agentici non è solo una questione di produttività. Toccano temi come la governance del codice generato automaticamente, la sicurezza delle pipeline CI/CD e, per chi opera in ambienti regolamentati o air-gapped, la fattibilità di eseguire questi agenti on-premise. Il paper di OpenAI non fornisce dettagli sull’infrastruttura utilizzata (cloud, probabilmente), né su latenza, consumo energetico o modelli di costo. Sono lacune che pesano quando si cerca di replicare l’esperienza in casa.

La scomparsa della trasparenza tecnica

OpenAI ha trasformato un dato di adozione interna in un case study. Il paper – accessibile solo attraverso il comunicato dell’azienda – non include benchmark indipendenti, non quantifica il tempo risparmiato per sviluppatore e non spiega come l’agente gestisca contesti di codice complessi o repository di grandi dimensioni. Inoltre, non sono menzionati vincoli di quantization, dimensioni della finestra di contesto o requisiti di VRAM per un eventuale deployment locale.

Questa opacità è un campanello d’allarme per chi valuta l’introduzione di coding agent in infrastrutture proprietarie. Molte organizzazioni non possono o non vogliono affidare il proprio codice a servizi cloud esterni. Oggi esistono alternative self-hosted basate su modelli aperti, ma la loro adozione richiede un’analisi attenta del TCO, delle competenze interne e delle performance reali su carichi di lavoro specifici. Il messaggio implicito del paper – “noi lo usiamo, funziona” – ha poco valore senza contesto.

Cosa segnala il passaggio agli agenti

Al di là della singola notizia, il balzo dal 40% al 98% in pochi mesi suggerisce che OpenAI ha riprogettato i flussi di lavoro attorno a Codex, non viceversa. È un dettaglio importante: l’adozione di agenti non è plug-and-play, richiede un cambiamento organizzativo e di processo. Per chi gestisce ambienti on-premise, questo significa che il deployment tecnicico è solo una parte del percorso. Occorre preparare i team, ridefinire le responsabilità di revisione del codice e costruire fiducia in sistemi che operano in modo semi-autonomo.

Il paper, insomma, è più un manifesto interno che una fonte attendibile per decisioni architetturali. La direzione è chiara: gli strumenti agentici stanno diventando il nuovo standard nello sviluppo software. Ma per i responsabili IT che devono giustificare investimenti in hardware, sicurezza e formazione, servono dati misurabili, non percentuali slegate da ogni metrica reale.

Oltre il clamore, i conti con la realtà

L’episodio mostra quanto sia fragile il confine tra ricerca e marketing quando un’azienda controlla sia il prodotto che la narrazione. Chi lavora su deployment on-premise sa che i fattori critici – latenza di inference, occupazione di memoria, compatibilità con le proprie policy di sicurezza – non compaiono in paper aziendali. Ed è proprio qui che iniziano le valutazioni serie: quali modelli aperti possono avvicinarsi alle capacità di Codex? Quali framework di serving gestiscono carichi agentici in locale? Quali trade-off tra automazione e controllo sono accettabili? Domande che restano senza risposta, in attesa che qualcuno, al di fuori dei comunicati stampa, metta davvero i numeri sul tavolo.