La Software Factory di OpenAI Codex sostituisce la programmazione con la supervisione degli agenti

OpenAI ha trasformato Codex da assistente di programmazione opzionale a livello operativo alla base di quasi tutto il lavoro interno nel giro di pochi mesi. La software factory di OpenAI Codex collega ora gli agenti a codice, documentazione, sistemi di comunicazione, infrastrutture di test e telemetria di produzione.

Questa conclusione proviene da Gergely Orosz, che ha visitato la sede centrale di OpenAI e intervistato sette ingegneri e responsabili dell’ingegneria. Il suo resoconto dall’interno descrive un’organizzazione in cui gli agenti creano, ispezionano, distribuiscono e monitorano software in misura crescente.

Il conflitto importante non riguarda più Codex contro la velocità di digitazione umana. Riguarda il throughput degli agenti contro l’attenzione umana, i sistemi di revisione e i controlli organizzativi necessari per fidarsi di quell’output.

L’esperienza di OpenAI rappresenta inoltre un caso insolitamente favorevole. I dipendenti dispongono di un ampio accesso ai modelli, profonde integrazioni interne e team dedicati al miglioramento dell’harness degli agenti. La maggior parte delle aziende non dispone di queste condizioni, rendendo la replica meno certa di quanto i risultati in evidenza suggeriscano.

La Software Factory di OpenAI Codex diventa il flusso di lavoro predefinito

Il cambiamento più evidente è che Codex è passato dall’assistere singoli sviluppatori al coordinare il lavoro in tutta OpenAI.

Orosz riferisce che la transizione è iniziata intorno a gennaio 2026. Nel giro di quattro mesi, l’utilizzo di Codex tra le organizzazioni non ingegneristiche sarebbe salito da quasi zero a circa il 90%.

I dipendenti di finanza, recruiting, legale, marketing e ricerca si sono uniti agli ingegneri nell’adozione del sistema. Secondo quanto riferito, quasi tutti i dipendenti OpenAI utilizzano ora Codex o ChatGPT Work durante una settimana tipo.

La stessa analisi del lavoro di OpenAI supporta l’orientamento generale di questo resoconto. L’azienda afferma che Codex genera ora oltre l’85% dei token di output del dipendente medio.

Secondo OpenAI, questa quota raggiunge il 99% per l’ingegnere medio. In tutta l’azienda, Codex rappresenterebbe il 99,8% dei token di output settimanali generati con gli strumenti OpenAI.

Queste cifre misurano l’output dei modelli, non il valore aziendale effettivamente realizzato. Indicano comunque che l’interfaccia per il lavoro interno con l’AI si è spostata in modo decisivo dalla conversazione all’esecuzione delegata.

Un chatbot generalmente attende ogni nuova istruzione. Un agente riceve un obiettivo, usa strumenti, esamina i risultati e continua a lavorare attraverso una sequenza più lunga di decisioni.

Questa distinzione spiega perché Codex si sia diffuso oltre lo sviluppo software. Ricercare un argomento, assemblare una presentazione, trasformare un foglio di calcolo e monitorare Slack implicano tutti artefatti digitali che gli agenti possono manipolare tramite software.

OpenAI ha rilasciato la sua app desktop Codex per Mac nel febbraio 2026 e ne ha esteso la disponibilità a Windows a marzo. ChatGPT Work, che utilizza lo stesso harness sottostante degli agenti, è seguito a luglio.

Secondo quanto riferito, la curva di adozione è iniziata prima che l’interfaccia diventasse accessibile ai non ingegneri. Orosz afferma che l’utilizzo tra questi dipendenti si avvicinava al 40% mentre il prodotto mostrava ancora codice e presumeva familiarità tecnica.

Questo andamento mette in discussione una visione comune dell’adozione dell’AI sul posto di lavoro. Un’interfaccia rifinita era meno importante della capacità di un agente di completare un compito sostanziale e restituire un artefatto utilizzabile.

Il lavoro a esecuzione più lunga sembra aver accelerato la transizione. Orosz riferisce che l’utilizzo interno è salito da circa il 60% al 90% tra aprile e maggio, con il miglioramento dei flussi di lavoro basati sugli obiettivi.

Un dipendente può specificare un risultato e lasciare che un agente prosegua attraverso più passaggi. Il sistema può anche delegare sottoattività ad agenti aggiuntivi, invece di richiedere al dipendente di supervisionare ogni filone.

OpenAI descrive una tendenza simile nell’utilizzo esterno. Entro maggio, il 70,2% degli utenti individuali campionati aveva formulato almeno una richiesta che rappresentava oltre un’ora di lavoro umano stimato.

L’azienda afferma che il 25,6% aveva richiesto lavoro stimato oltre le otto ore. Tali stime derivano da valutazioni del modello, quindi OpenAI consiglia di considerarle indicative piuttosto che esatte.

La personalizzazione interna ha contato quanto la maggiore durata dei compiti. I team hanno creato skill e plugin specifici per ruolo, che hanno fornito all’agente generalista procedure ripetibili, strumenti e contesto di dominio.

Questa combinazione ha aiutato Codex a diventare infrastruttura anziché un’altra applicazione. I dipendenti non dovevano più tradurre ogni flusso di lavoro ricorrente in una nuova conversazione.

Dall’adozione è seguita la dipendenza. Orosz riferisce che anche interruzioni minori possono generare lamentele interne prima che il monitoraggio automatizzato avvisi i team responsabili.

OpenAI ha quindi creato sia un motore di produttività sia un punto condiviso di vulnerabilità. Più lavoro passa attraverso un unico harness di agenti, maggiore è l’impatto operativo quando quell’harness rallenta o si guasta.

Il codice più rapido mette sotto pressione revisione e rilascio

Codex ha ridotto il costo di produzione del codice, ma non ha eliminato il costo di validarlo e distribuirlo.

Orosz riferisce un calo nell’uso degli ambienti di sviluppo integrati presso OpenAI da gennaio. Un IDE combina modifica del codice, navigazione, test e debugging in un’unica interfaccia per sviluppatori.

Gli ingegneri delegano invece sempre più l’implementazione tramite Codex. Il loro lavoro si sposta verso la definizione dei risultati, la fornitura di contesto, la valutazione degli esiti e la decisione su quali modifiche meritino la distribuzione.

Questo cambia la risorsa scarsa. Quando un agente può generare diverse implementazioni mentre una persona partecipa a una riunione, il tempo umano di digitazione smette di limitare la produzione.

L’attenzione diventa il collo di bottiglia. Gli ingegneri devono ancora identificare problemi di valore, riconoscere soluzioni deboli, risolvere ambiguità e assumersi la responsabilità degli esiti in produzione.

Le tradizionali pull request sono state progettate attorno a un flusso più lento di modifiche create da esseri umani. Offrono ai colleghi un pacchetto delimitato di codice da ispezionare prima di integrarlo in un repository condiviso.

Questo modello diventa sotto pressione quando ogni ingegnere può avviare molti agenti. Venkat Venkataramani, vicepresidente dell’ingegneria delle infrastrutture applicate di OpenAI, ha descritto il volume delle pull request come in crescita a un ritmo accelerato.

L’output aggiuntivo non incide solo sulla revisione del codice. Ogni modifica consuma capacità di build, esecuzione dei test, infrastruttura di distribuzione, archiviazione, osservabilità e attenzione dei revisori.

I team OpenAI stanno riconsiderando l’integrazione continua e la distribuzione continua alla luce di questo volume più elevato. Questi sistemi compilano, testano e rilasciano automaticamente le modifiche dopo il loro invio da parte degli sviluppatori.

La sequenza precedente presupponeva che creare codice fosse relativamente costoso. Lo sviluppo agentico inverte questo rapporto, perché proporre un’altra modifica diventa economico mentre dimostrarne la sicurezza rimane costoso.

OpenAI sta rispondendo con agenti di revisione specializzati. Anziché chiedere a un modello generalista di ispezionare una modifica, il flusso di lavoro può assegnare prospettive separate su sicurezza, infrastruttura, prestazioni o conformità.

Ogni revisore riceve conoscenze rilevanti sul repository e regole organizzative. Le modifiche ad alto rischio possono attivare revisioni degli agenti più estese e l’approvazione umana obbligatoria.

Le aree a rischio inferiore possono utilizzare controlli più leggeri. Alcuni repository possono consentire a un agente di approvare modifiche classificate in modo ristretto senza attendere una persona.

Si tratta di un passaggio da fasi di revisione universali a un instradamento basato sul rischio. Dipende inoltre da una classificazione accurata, documentazione aggiornata e controlli di accesso affidabili.

L’approccio mette sotto pressione le organizzazioni che misurano ancora l’adozione dell’AI attraverso suggerimenti accettati o sondaggi tra gli sviluppatori. Queste misure non colgono i costi a valle creati dal codice aggiuntivo e dalla sperimentazione più rapida.

Un team può integrare più pull request senza migliorare i risultati per i clienti. Può anche creare più obblighi di manutenzione, rumore operativo e incoerenza architetturale.

La distribuzione mobile nativa rende chiaramente visibile questo divario. OpenAI può generare rapidamente una modifica a un’applicazione, ma aggiornamenti iOS e Android significativi devono ancora passare attraverso processi di revisione esterni.

L’approvazione degli app store può richiedere ore o giorni. Più modifiche generate dagli agenti si accumulano quindi dietro un sistema di distribuzione che gli agenti non controllano.

Lo stesso disallineamento appare all’interno delle imprese. Valutazioni della sicurezza, comitati di gestione delle modifiche, revisioni di conformità e validazione da parte dei clienti raramente accelerano semplicemente perché l’implementazione è diventata più veloce.

I concorrenti affrontano la stessa pressione strutturale. La ricerca di Anthropic su circa 400.000 sessioni Claude Code ha rilevato che gli esseri umani prendevano ancora la maggior parte delle decisioni di pianificazione, mentre l’agente gestiva più decisioni di esecuzione.

Il suo studio sull’utilizzo ha inoltre rilevato che l’esperienza di dominio restava associata a un maggiore successo. Gli agenti di programmazione hanno modificato l’allocazione del lavoro senza rendere irrilevante il giudizio.

La competizione emergente non è quindi OpenAI Codex contro Claude Code su benchmark isolati di programmazione. È quale organizzazione riesce a riprogettare l’intero sistema di distribuzione attorno a un’abbondante esecuzione automatizzata.

OpenAI possiede attualmente un vantaggio significativo perché sviluppa insieme modelli, prodotti e ambiente interno. Può adattare l’agente quando i suoi stessi flussi di lavoro rivelano una debolezza.

Gli acquirenti aziendali devono integrare gli agenti in repository, controlli e catene di approvazione ereditati. Il loro fattore limitante sarà spesso la prontezza organizzativa piuttosto che l’accesso ai modelli.

La fabbrica opera attraverso contesto e cicli di feedback

Il modello OpenAI assomiglia a una fabbrica perché gli agenti partecipano all’intero ciclo produttivo, non perché la generazione del codice sia completamente autonoma.

Il processo inizia con un essere umano che definisce il risultato desiderato. Questa persona decide quale problema conta, quali vincoli si applicano e cosa dovrebbe ottenere un risultato accettabile.

Codex raccoglie poi contesto da repository, documentazione, Slack, Notion, log, sistemi di monitoraggio e fonti di dati interne. Questa fase di recupero determina ciò che l’agente può comprendere prima di modificare qualcosa.

Secondo quanto riferito, OpenAI ha spostato la documentazione più vicino al codice sorgente. Questo rende la conoscenza operativa più facile da trovare nel repository sia per gli agenti sia per gli ingegneri.

L’agente implementa una modifica, esegue i test, corregge gli errori e apre una pull request. Può continuare a monitorare la richiesta e rispondere quando i controlli automatizzati identificano problemi.

Le modifiche sensibili alle prestazioni possono passare a una valutazione aggiuntiva. Un harness delle prestazioni sottopone build selezionate a confronti controllati per rilevare regressioni prima della distribuzione.

Più agenti di revisione ispezionano quindi il lavoro attraverso diverse lenti di dominio. Il loro valore deriva da istruzioni mirate e dall’accesso a conoscenze specifiche di OpenAI, non dalla semplice adozione di etichette di esperti.

Il flusso di lavoro classifica le modifiche in base al rischio. Questa classificazione determina se la modifica necessita di ulteriori revisioni da parte degli agenti, di una decisione umana o di un percorso di approvazione più semplice.

Un essere umano approva ancora la distribuzione in produzione nel processo documentato da Orosz. Dopo l’approvazione, un altro agente segue la modifica durante il rollout e ne osserva i segnali operativi.

Questo agente di distribuzione può individuare un feature flag, interpretare la modifica, selezionare metriche di successo e creare una dashboard di monitoraggio. Osserva quindi il rollout alla ricerca di segnali di problemi.

Il comportamento in produzione alimenta il nuovo sviluppo. La Perf Factory riportata da OpenAI raggruppa gli avvisi, identifica regressioni di latenza, indaga le cause probabili e propone correzioni.

Un altro sistema interno, Sevbot, assiste durante gli incidenti di servizio. Raccoglie il contesto, suggerisce mitigazioni e risponde alle domande nel canale di risposta.

Oggi Sevbot non esegue in autonomia le mitigazioni che propone. Un ingegnere deve autorizzare un’azione specificata, preservando una decisione umana in un punto ad alto rischio.

L’intero ciclo è più importante di qualsiasi singola risposta del modello. Gli agenti ricevono contesto strutturato, operano tramite strumenti vincolati, incontrano test automatizzati e restituiscono evidenze alle fasi successive.

OpenAI chiama harness il sistema circostante. Un harness collega il modello a strumenti, dati, autorizzazioni, ambienti di esecuzione, memoria e meccanismi di feedback.

Il precedente esperimento sull’harness dell’azienda illustra perché questa ingegnerizzazione sia importante. Un team afferma che Codex ha prodotto ogni riga di un prodotto interno contenente circa un milione di righe di codice.

OpenAI ha stimato che il progetto abbia richiesto circa un decimo del tempo necessario per un’implementazione manuale. Resta una stima aziendale relativa a un progetto interno greenfield, non un benchmark indipendente di settore.

La lezione più rivelatrice è stata che gli agenti richiedevano un ambiente leggibile. La conoscenza del repository doveva essere organizzata chiaramente, i test dovevano fornire feedback utile e i vincoli architetturali dovevano essere applicabili tramite verifiche automatiche.

Gli ingegneri hanno dovuto anche rimuovere il disordine accumulato. Un agente può riprodurre rapidamente schemi obsoleti quando il repository presenta tali schemi come esempi validi.

Un throughput elevato aumenta quindi l’importanza di ciò che OpenAI chiama garbage collection. I team devono rimuovere documentazione obsoleta, astrazioni duplicate, codice morto e convenzioni incoerenti prima che si moltiplichino.

Successivamente OpenAI ha sviluppato Symphony, una specifica di orchestrazione che collega gli agenti di coding a un issue tracker. Ogni attività idonea può ricevere uno spazio di lavoro dedicato e un agente che continua a lavorare fino al completamento.

L’azienda afferma che il suo workflow Symphony ha prodotto un aumento del 500 percento nelle pull request integrate per alcuni team durante le prime tre settimane.

Anche in questo caso, il volume delle pull request è una misura dell’output anziché del valore per il cliente. Tuttavia, l’esperimento individua un altro collo di bottiglia importante: le persone faticano a supervisionare simultaneamente molte sessioni interattive di agenti.

OpenAI afferma che la maggior parte degli ingegneri riusciva a gestire comodamente da tre a cinque sessioni prima che il cambio di contesto diventasse oneroso. Symphony sposta la supervisione dalle singole sessioni agli stati delle attività e ai risultati consegnati.

L’issue tracker diventa un piano di controllo. Gli agenti raccolgono il lavoro non bloccato, ripartono dopo gli errori, creano attività di follow-up e mantengono l’esecuzione tra repository diversi.

Gli esseri umani esaminano piani, priorità e risultati finali invece di sollecitare ripetutamente ogni sessione. Questo schema porta l’ingegnere un livello sopra l’implementazione.

Cambia anche ciò che rende un’organizzazione pronta per lo sviluppo agentico. Ticket ben scritti, documentazione aggiornata, sistemi osservabili e test deterministici diventano infrastruttura di produzione.

I team che esplorano workflow simili hanno bisogno di una fonte affidabile di contesto organizzativo. Una base di conoscenza ingegneristica ricercabile può aiutare, anche se il recupero delle informazioni da solo non crea automazione affidabile.

La metafora della fabbrica va quindi usata con cautela. OpenAI non ha eliminato le persone dallo sviluppo software e le sue decisioni più sensibili mantengono ancora il controllo umano.

Ha invece automatizzato una porzione maggiore del percorso tra intenzione ed evidenza. Il lavoro umano si sposta verso la progettazione di quel percorso, la valutazione dei suoi output e il mantenimento dei suoi vincoli.

La storia della produttività presenta ancora un divario di verifica

Le evidenze interne di OpenAI sono sorprendenti, ma non dimostrano ancora che la maggior parte delle aziende possa riprodurre gli stessi guadagni in sicurezza.

OpenAI opera con vantaggi insoliti. I suoi dipendenti possono utilizzare ampia capacità di calcolo, budget di token generosi, modelli interni avanzati e accesso diretto ai team che sviluppano Codex.

Il sistema interno si collega anche ai repository aziendali, agli strumenti di comunicazione, ai dati operativi e alla documentazione. I clienti pubblici ricevono un prodotto più circoscritto, con meno integrazioni specifiche per l’organizzazione.

Questo divario conta perché gli agenti dipendono dal contesto. Un agente collegato a documentazione incompleta o autorizzazioni frammentate produrrà risultati diversi da uno integrato in ogni parte di un laboratorio di modelli.

Le metriche di OpenAI enfatizzano inoltre utilizzo e output. Quota di token, volume delle pull request e righe di codice rivelano attività, ma non misurano direttamente affidabilità, soddisfazione dei clienti o costo totale di manutenzione.

Anche le stime dei tempi richiedono cautela. Le affermazioni di OpenAI sulle attività di lunga durata usano un modello per stimare lo sforzo umano equivalente, anziché registrare una persona che svolge lo stesso incarico.

Le evidenze indipendenti restano contrastanti. Uno studio randomizzato di METR ha rilevato che sviluppatori open source esperti hanno impiegato il 19 percento di tempo in più utilizzando strumenti di IA dei primi mesi del 2025 su repository familiari.

Lo studio sugli sviluppatori ha coinvolto 16 sviluppatori che hanno completato 246 attività. I partecipanti avevano lavorato con i rispettivi repository per circa cinque anni in media.

Quell’esperimento ha analizzato strumenti precedenti e attività della durata approssimativa da 20 minuti a quattro ore. Non testa i workflow del 2026 a più lunga esecuzione descritti all’interno di OpenAI.

Il contrasto fornisce comunque un avvertimento utile. Capacità del modello, forma dell’attività, progettazione del repository, competenza dell’utente e costo della verifica possono ribaltare l’apparente risultato di produttività.

L’ambiente di OpenAI è stato riprogettato per gli agenti. Molte aziende inizialmente collocheranno un agente in sistemi ottimizzati per gli esseri umani, per poi chiedersi perché l’output resti inaffidabile.

La sicurezza crea un altro problema di replicazione. Un agente utile necessita dell’accesso al codice sorgente, alle credenziali, ai sistemi di comunicazione, agli strumenti di deployment e alle informazioni di produzione.

Ogni nuova connessione amplia il possibile impatto di errori o istruzioni manipolate. Il prompt injection può nascondere direttive ostili in documenti, siti web, messaggi o output degli strumenti letti da un agente.

OpenAI afferma di limitare questi rischi tramite sandboxing, policy di rete gestite, autenticazione centralizzata, regole sui comandi e telemetria dettagliata. Le sue protezioni di Codex bloccano l’accesso di rete senza vincoli e richiedono approvazione per destinazioni non familiari.

L’azienda registra inoltre prompt, attività degli strumenti, approvazioni e decisioni relative alle policy di rete. I team di sicurezza possono combinare tali registri con gli avvisi sugli endpoint per ricostruire perché un agente abbia compiuto un’azione insolita.

Questi controlli fanno parte del prodotto, non sono un ornamento amministrativo opzionale. Un agente veloce con autorizzazioni ampie può trasformare un piccolo fraintendimento in una rapida serie di azioni rilevanti.

L’automazione della revisione introduce una propria incertezza. Un agente specializzato può individuare difetti che un essere umano impegnato non nota, soprattutto quando può ispezionare ogni modifica con coerenza.

Tuttavia, diversi agenti che utilizzano modelli correlati possono condividere gli stessi punti ciechi. L’accordo tra revisori automatizzati non garantisce che una modifica sia corretta.

I team rischiano anche il bias dell’automazione. I revisori potrebbero esaminare con minore attenzione le modifiche approvate dalla macchina perché il processo appare completo.

La fabbrica può indebolire anche la comprensione condivisa. Tradizionalmente, gli ingegneri imparano i sistemi implementando funzionalità, eseguendo il debug degli errori e rivedendo le decisioni dei colleghi.

Quando gli agenti svolgono una parte maggiore di quel lavoro, le organizzazioni hanno bisogno di un altro modo per preservare la conoscenza architetturale. Altrimenti, gli esseri umani potrebbero mantenere l’autorità di approvazione perdendo al contempo il contesto necessario per esercitarla.

La risposta dichiarata da OpenAI è una maggiore enfasi su gusto, giudizio e capacità d’azione. Queste qualità aiutano gli ingegneri a specificare risultati migliori e a respingere implementazioni plausibili ma indesiderabili.

Eppure sono difficili da valutare e insegnare. Storicamente, gli ingegneri junior hanno sviluppato il giudizio attraverso compiti di implementazione più piccoli che gli agenti assorbono sempre più spesso.

Le implicazioni a lungo termine per l’organico restano quindi irrisolte. I workflow agentici possono ampliare ciò che un singolo ingegnere esperto realizza, restringendo al contempo i tradizionali punti d’ingresso nella professione.

Il caso di OpenAI non dovrebbe nemmeno essere ridotto alla sostituzione dei posti di lavoro. Il sistema documentato continua a fare affidamento sulle persone per la definizione delle priorità, la competenza di dominio, l’accettazione del rischio e l’autorità sugli incidenti.

Il cambiamento immediato è più concreto. Le organizzazioni possono generare lavoro proposto più velocemente di quanto i loro sistemi di governance, infrastruttura e apprendimento riescano ad assorbirlo.

Questo rende decisiva la qualità dei cicli di feedback. Test deboli e documentazione obsoleta consentono agli errori di propagarsi rapidamente, mentre controlli solidi trasformano i tentativi falliti in informazioni utili.

L’affermazione centrale è credibile nella direzione, ma incompleta nella portata. OpenAI ha mostrato quanto profondamente un agente possa rimodellare un’azienda progettata per supportarlo.

Non ha ancora dimostrato che la stessa architettura resti economica, sicura e manutenibile nelle aziende ordinarie con sistemi frammentati e competenze di IA limitate.

Tre segnali mostreranno se il modello è trasferibile

Il prossimo test sarà verificare se OpenAI riuscirà a trasformare il proprio modello operativo interno in un sistema ripetibile per i clienti senza trasferire rischi inaccettabili.

Il primo segnale è costituito da evidenze più ampie sugli esiti. Gli acquirenti dovrebbero cercare cambiamenti misurati nei tempi di ciclo, negli incidenti, nei tassi di rollback, nell’impatto sui clienti e nello sforzo di manutenzione.

Più codice non basta. La software factory OpenAI Codex diventa persuasiva al di fuori della sede centrale solo quando team indipendenti migliorano la consegna senza aumentare difetti o carico operativo.

Le evidenze più solide confronterebbero team simili prima e dopo l’adozione. Dovrebbero includere il tempo dedicato alla revisione, alla correzione e alla manutenzione delle modifiche generate dagli agenti.

Il secondo segnale riguarda l’evoluzione dei controlli di revisione e deployment. L’architettura attuale di OpenAI colloca ancora gli esseri umani in selezionati confini di produzione e risposta agli incidenti.

Le future versioni riveleranno quali decisioni diventeranno autonome e quali rimarranno deliberatamente umane. La collocazione di tali confini definirà il modello di rischio pratico del sistema.

Osservate se dashboard generate dagli agenti, revisioni specializzate e classificazioni del rischio intercettano errori che i controlli esistenti non rilevano. Osservate anche se i comuni punti ciechi dei modelli creano errori di revisione correlati.

Il terzo segnale è la risposta competitiva di Anthropic, Google, Microsoft e dei fornitori di software enterprise. Ognuno ha un incentivo a controllare l’interfaccia attraverso cui le persone delegano il lavoro.

Anthropic ha già collegato agenti Claude di lunga durata ad ambienti di sviluppo e workflow aziendali. Google e Microsoft possono combinare gli agenti con grandi suite di produttività, piattaforme cloud e sistemi di identità.

Il premio strategico va oltre la generazione di codice. Il sistema vincente può diventare il livello di controllo che legge il contesto organizzativo, assegna compiti e restituisce artefatti completati.

Questa posizione crea costi di cambiamento sostanziali. Competenze, autorizzazioni, policy di revisione, conoscenza istituzionale e cronologia dei workflow si accumulano attorno all’harness scelto.

Concentra inoltre la dipendenza operativa. Una regressione del modello, un’interruzione del servizio, un difetto di sicurezza o una modifica delle policy possono interrompere il lavoro in molti reparti contemporaneamente.

L’adozione enterprise dipenderà quindi dalla portabilità e dall’auditabilità tanto quanto dalla capacità grezza. Gli acquirenti devono capire a cosa un agente abbia avuto accesso, cosa abbia deciso, modificato e passato a un altro agente.

Standard aperti per competenze, connessioni agli strumenti, tracce e valutazione ridurrebbero la dipendenza da un singolo fornitore. Le integrazioni interne chiuse possono offrire progressi più rapidi, ma rendono più difficile la migrazione.

Il ruolo degli ingegneri resterà la quarta questione, di più lungo periodo, dietro questi tre segnali. I dipendenti di OpenAI dedicano meno tempo alla produzione diretta di codice e più tempo a dirigere i sistemi.

Questo non elimina le competenze ingegneristiche. Cambia il punto in cui tali competenze entrano nel processo, spostandole verso specifiche, architettura, valutazione, sicurezza e giudizio operativo.

Le organizzazioni più capaci non si limiteranno ad aggiungere un agente a un vecchio workflow. Decideranno quali conoscenze debbano diventare leggibili dalle macchine e quali decisioni debbano restare responsabilità delle persone.

Misureranno inoltre gli esperimenti scartati, il costo delle revisioni e il recupero dagli errori. Un’implementazione economica non è davvero economica quando genera costosa incertezza a valle.

La visita di Orosz coglie una transizione importante mentre è ancora in corso. OpenAI non usa più Codex soltanto per aiutare gli ingegneri a scrivere software più rapidamente.

Sta riorganizzando la produzione software attorno ad agenti che raccolgono contesto, eseguono attività, revisionano modifiche, monitorano i deployment e apprendono dai segnali provenienti dalla produzione.

Il risultato è una fabbrica software agentica, ma non una fabbrica senza esseri umani. Le persone scelgono ancora gli obiettivi, definiscono i vincoli, accettano i rischi e intervengono quando i sistemi si comportano in modo inatteso.

La domanda pratica per i lettori non è se copiare immediatamente il workflow di OpenAI. È quale parte del vostro sistema di delivery diventi il collo di bottiglia quando l’implementazione diventa drasticamente più economica.

Iniziate identificando un workflow circoscritto con risultati misurabili, test affidabili, contesto aggiornato e azioni reversibili. Poi misurate l’intero onere di revisione e manutenzione, non solo la velocità visibile dell’agente.

Se quell’esperimento ha successo, ampliate il sistema di feedback prima di ampliare l’autonomia. La fabbrica software di OpenAI Codex suggerisce che gli agenti scalano grazie ad ambienti migliori, mentre il giudizio umano determina se il loro output meriti di essere distribuito.