Nel racconto di OpenAI sull’harness engineering, Codex ha scritto ogni riga di un nuovo prodotto: applicazione, test, CI, documentazione, osservabilità e strumenti interni. Il risultato più interessante non è il volume dichiarato di codice, ma l’infrastruttura costruita attorno all’agente. Persone, repository e controlli sono stati riprogettati affinché l’intento diventasse verificabile e gli errori producessero feedback riutilizzabile.
Che cosa mostra — e che cosa non mostra — il caso OpenAI
OpenAI riferisce che, partendo da un repository vuoto, in cinque mesi un piccolo team ha guidato Codex fino a una base di codice dell’ordine di un milione di righe e circa 1.500 pull request. Il prodotto aveva utenti interni quotidiani e tester alfa esterni; l’azienda stima un tempo di realizzazione pari a circa un decimo della scrittura manuale.
Sono dati auto-riferiti su un singolo prodotto, non un confronto controllato. Le righe di codice non misurano da sole valore o qualità e il gruppo disponeva di competenze, modelli e infrastruttura non comuni. OpenAI precisa inoltre che il comportamento dipende fortemente da quel repository e che non è ancora noto come la coerenza evolverà nell’arco di anni. Il caso va letto come esperienza progettuale, non come promessa di rendimento.
Rendere il repository leggibile all’agente
Per un agente, una decisione rimasta in una chat o nella memoria di una persona è di fatto invisibile. Il team ha quindi portato nel repository specifiche di prodotto, principi architetturali, piani di esecuzione, decisioni e debito tecnico, tutti versionati e collegati al codice.
Il file di istruzioni principale è rimasto una mappa breve, non un manuale monolitico: indirizza verso fonti più profonde quando servono. Questa divulgazione progressiva limita il rumore e rende verificabili proprietà come proprietario, stato e aggiornamento dei documenti. È utile anche per le persone nuove nel progetto, non soltanto per il modello.
Tradurre l’architettura in vincoli meccanici
La documentazione descrive la direzione; lint e test strutturali impediscono le deviazioni più costose. Nel caso raccontato da OpenAI, i domini seguono livelli e dipendenze consentite, mentre controlli automatici verificano logging strutturato, convenzioni, dimensione dei file e requisiti di affidabilità.
Questi vincoli non prescrivono ogni dettaglio dell’implementazione. Definiscono invarianti — per esempio validare i dati ai confini o non invertire una dipendenza — e lasciano all’agente spazio nel modo di rispettarle. Il team sposta così il giudizio ricorrente dalla singola review a una regola eseguibile. La responsabilità umana resta su priorità, criteri di accettazione, configurazione dei vincoli e validazione degli esiti, anche quando la revisione operativa è affidata ad altri agenti.
Chiudere il ciclo con feedback e recupero
Un harness efficace permette all’agente di riprodurre il problema, modificare il codice, eseguire test e controlli, osservare l’applicazione e preparare una pull request. Errori di build, commenti di review e bug degli utenti devono rientrare nel sistema come test, documentazione o nuovi guardrail, invece di restare correzioni isolate.
Serve anche una via di uscita: ambienti riproducibili, log, piccoli cambiamenti e rollback riducono il costo di una traiettoria sbagliata. OWASP raccomanda comunque un responsabile umano per ogni modifica generata e un’approvazione esplicita prima del merge. Un agente che valuta il proprio lavoro aggiunge un segnale, ma non costituisce una verifica indipendente nelle aree critiche.
Ottimizzare l’attenzione, non il numero di prompt
Quando il codice arriva più rapidamente, il collo di bottiglia diventa la capacità umana di specificare priorità, valutare risultati e mantenere coerente il sistema. Conviene partire da un flusso, rendere affidabili setup e test, codificare i difetti ripetuti e soltanto dopo eseguire più agenti in parallelo. Altrimenti si moltiplicano patch e review senza aumentare il valore consegnato.
DORA descrive l’AI come un amplificatore del sistema organizzativo esistente. L’harness engineering rende concreta questa idea: repository chiaro, ownership, vincoli e recupero trasformano la velocità del modello in capacità del team. Il prompt resta importante, ma il vantaggio che si accumula vive nel metodo che sopravvive alla singola conversazione.