Il team Codex di OpenAI ha lanciato un prodotto da un milione di righe con zero codice scritto da umani

Il vincolo che ha plasmato tutto: niente codice scritto a mano

Il primo commit è arrivato in un repository vuoto a fine agosto 2025. Cinque mesi dopo, secondo il post, il repository contiene circa un milione di righe di codice, e nessuna è stata digitata da un umano. Persino l'impalcatura iniziale — struttura del repository, configurazione CI, regole di formattazione, setup dei package — è stata generata da Codex CLI eseguendo GPT-5, e il primo AGENTS.md, che indica agli agenti come lavorare nel repository, è stato scritto dall'agente stesso.

Il team riporta circa 1.500 pull request unite, una media di 3,5 PR per engineer al giorno, e un organico passato da tre a sette engineer mentre il throughput saliva invece di scendere. Il prodotto ha centinaia di utenti interni e power user quotidiani, quindi non si tratta di output fine a se stesso.

La regola del 'niente codice scritto a mano' sembra una trovata pubblicitaria, ma il post è chiaro sul fatto che è stata scelta deliberatamente come meccanismo forzante. Se gli umani non possono risolvere le cose digitando, ogni fallimento diventa una domanda sull'ambiente piuttosto che sul codice: quale capacità manca, e come la rendiamo leggibile e verificabile per l'agente?

Rendere l'applicazione in esecuzione leggibile per l'agente

Il collo di bottiglia riscontrato dal team non era la capacità di Codex di scrivere codice, ma la capacità umana di fare QA. La loro risposta è stata dare all'agente accesso diretto alle cose che un umano normalmente osserverebbe. Hanno reso l'app avviabile per ogni git worktree così che Codex potesse lanciare una propria istanza per ogni modifica, hanno collegato il Chrome DevTools Protocol al runtime dell'agente, e hanno costruito skill per snapshot del DOM, screenshot e navigazione.

Hanno fatto lo stesso per l'osservabilità. Ogni worktree riceve uno stack locale effimero di log, metriche e trace che viene smantellato al termine del task. Poiché l'agente può interrogare i log con LogQL e le metriche con PromQL, prompt come 'assicurati che l'avvio del servizio si completi in meno di 800ms' o 'nessuno span in questi quattro percorsi utente critici deve superare i due secondi' diventano istruzioni concrete e non semplici aspirazioni.

Questa è l'idea portante del post: come dice l'autore, dal punto di vista dell'agente, tutto ciò a cui non può accedere nel contesto praticamente non esiste. La conoscenza nei thread di Slack, nei Google Docs o nella testa delle persone è invisibile. Per questo il team tratta una directory docs/ strutturata come sistema di riferimento e mantiene AGENTS.md sulle 100 righe — un indice, non un'enciclopedia — con un agente ricorrente di 'doc-gardening' che apre PR di correzione quando la documentazione si discosta dal comportamento reale.

Un'architettura rigida come motore di velocità, non come freno

Il team ha avvolto il codebase in vincoli che la maggior parte delle organizzazioni rimanda a quando hanno centinaia di engineer. Ogni dominio di business è diviso in livelli fissi — Types, Config, Repo, Service, Runtime, UI — con dipendenze che possono fluire solo in avanti, e questioni trasversali come autenticazione e telemetria forzate attraverso un'unica interfaccia Providers. Tutto il resto non è permesso e viene verificato meccanicamente da linter personalizzati, che sono, naturalmente, anch'essi generati da Codex.

Il ragionamento inverte il solito compromesso. I confini rigidi sembrano pedanti in un flusso di lavoro umano; qui agiscono come moltiplicatori perché, una volta codificata, una regola si applica ovunque contemporaneamente. I messaggi di errore dei lint personalizzati iniettano persino istruzioni di correzione direttamente nel contesto dell'agente, così una violazione diventa un ciclo di autocorrezione invece di una PR bloccata.

Questo è il tipo di architettura che di solito si rimanda a quando si hanno centinaia di engineer. Con gli agenti di coding, è un prerequisito precoce: sono i vincoli che permettono velocità senza degrado o deriva architetturale.Montana Labs

È interessante notare che il team impone i confini a livello centrale ma lascia libertà sull'implementazione. Richiedono il parsing delle forme dei dati al confine ma non impongono una libreria specifica — il modello si è orientato da solo verso Zod. Hanno anche scelto di reimplementare piccole utility, come un helper per la concorrenza, invece di importare un package generico, perché una versione interna al repository è completamente ispezionabile e integrata con la loro strumentazione. La tecnologia 'noiosa' vince qui perché è stabile, componibile e ben rappresentata nei dati di training.

L'entropia è il costo ricorrente, e ora la pulizia è automatizzata

La piena autonomia ha creato un nuovo tipo di fallimento: Codex replica fedelmente i pattern esistenti, inclusi quelli sbagliati, e così il codebase deriva. Inizialmente il team passava ogni venerdì — un quinto della settimana — a sistemare quello che chiamano 'AI slop'. Chiaramente non era scalabile.

La loro soluzione è stata codificare 'principi guida' ben definiti direttamente nel repository e far eseguire task Codex in background a cadenza regolare per individuare le deviazioni, aggiornare i punteggi di qualità e aprire PR di refactoring mirate — nella maggior parte dei casi revisionabili in meno di un minuto e con automerge. Descrivono il debito tecnico come un prestito ad alto interesse da estinguere meglio con piccoli incrementi quotidiani. Il gusto umano viene catturato una volta e poi applicato continuamente a ogni riga.

La filosofia di merge cambia di conseguenza. I gate bloccanti sono minimi, le PR hanno vita breve, e i test instabili vengono gestiti con esecuzioni successive invece di un blocco indefinito. Il team è schietto sul fatto che questo sarebbe irresponsabile in un ambiente a basso throughput; funziona solo perché le correzioni sono economiche e l'attesa è la cosa costosa.

La lezione specifica: l'harness è il prodotto che gli engineer costruiscono ora

OpenAI è attenta a delimitare l'affermazione. Dicono che l'autonomia end-to-end sulle feature — riprodurre un bug, registrare un video del fallimento, risolverlo, validare guidando l'app, registrare un video di risoluzione, aprire e unire la PR — 'dipende fortemente dalla struttura specifica e dagli strumenti di questo repository e non va assunta come generalizzabile senza un investimento simile.' Ammettono anche di non sapere ancora come la coerenza architetturale si mantenga nel corso degli anni in un sistema generato interamente da agenti.

La lezione trasferibile non è il milione di righe. È che lo sforzo ingegneristico di questo team si è spostato quasi interamente sulla costruzione dell'ambiente in cui l'agente opera: istanze dell'app per ogni worktree, osservabilità effimera, documentazione strutturata e versionata, layering applicato meccanicamente e messaggi di lint autocorrettivi. Ogni volta che Codex incontrava difficoltà, la risposta era aggiungere uno strumento, un guardrail o un documento mancante — e far scrivere quella correzione a Codex stesso.

Per qualsiasi team che sta valutando lo sviluppo agent-first, il segnale di costo onesto in questo post è l'impalcatura, non il prompting. Il collo di bottiglia era l'attenzione umana, e tutto ciò che hanno costruito era un tentativo di usarne di meno. La domanda da portare avanti è quanto di quell'investimento nell'harness un team più piccolo possa permettersi prima che il throughput ripaghi lo sforzo.