Come abbiamo usato Codex per sviluppare Sora per Android in 28 giorni

A partire dal 26/04/2026, Sora non è più disponibile.

A novembre abbiamo lanciato l'app Sora per Android, offrendo a chiunque possieda un dispositivo Android di trasformare un breve prompt in un video coinvolgente. Il giorno del lancio, l'app ha raggiunto il primo posto su Play Store. Gli utenti Android hanno generato più di un milione di video nelle prime 24 ore.

All'origine del lancio si cela una storia: la versione iniziale dell'app Android di Sora è stata realizzata in 28 giorni grazie allo stesso strumento a disposizione di qualsiasi team o sviluppatore: Codex.

Dall'8 ottobre al 5 novembre 2025, un team di ingegneri lean che ha lavorato a fianco di Codex utilizzando circa 5 miliardi di token, ha portato Sora per Android dal prototipo al lancio globale. Nonostante le sue dimensioni, l'app ha un tasso di crash pari allo 0,1% e un'architettura di cui siamo orgogliosi. Se ti stai chiedendo se abbiamo usato un modello segreto, abbiamo utilizzato una versione iniziale del modello GPT‑5.1‑Codex: la stessa versione che qualsiasi sviluppatore o azienda può utilizzare oggi tramite CLI, estensione IDE o app web.

Quando Sora è stata lanciata su iOS, il suo utilizzo è esploso. Le persone hanno iniziato subito a produrre una miriade di video. Su Android, invece, avevamo solo un piccolo prototipo interno e un numero crescente di utenti pre-registrati su Google Play.

Una risposta comune a un lancio ad alto rischio e con tempi ristretti è quella di accumulare risorse e aggiungere processi. Un'app per la produzione di questa portata e qualità richiederebbe in genere il lavoro di molti ingegneri per mesi, rallentato dal coordinamento. 

Il famoso architetto informatico americano Fred Brooks ha avvertito che "aggiungere più persone a un progetto software in ritardo lo ritarda ulteriormente". In altre parole, quando si cerca di portare a termine rapidamente un progetto complesso, l'aggiunta di altri ingegneri può spesso rallentare l'efficienza, aumentando i costi di comunicazione, la frammentazione dei compiti e i costi di integrazione. Abbiamo fatto tesoro di questa osservazione invece di ignorarla e abbiamo creato un team forte composto da quattro ingegneri, tutti dotati di Codex per aumentare drasticamente l'impatto di ciascuno di essi. 

Lavorando in questo modo, abbiamo distribuito una versione interna di Sora per Android ai dipendenti in 18 giorni e l'abbiamo lanciata pubblicamente 10 giorni dopo. Abbiamo mantenuto standard elevati nelle pratiche di ingegneria Android, investito nella manutenibilità e mantenuto l'app agli stessi livelli di affidabilità che ci aspetteremmo da un progetto più tradizionale. (Continuiamo a utilizzare ampiamente Codex anche oggi per sviluppare e aggiungere nuove funzionalità all'app).

Per comprendere appieno il nostro modo di lavorare con Codex, è utile sapere quali sono i suoi punti di forza e quali gli aspetti che necessitano di miglioramento. Un buon approccio è stato quello di trattarlo come un ingegnere senior appena assunto. Grazie alle funzionalità di Codex, abbiamo potuto dedicare più tempo alla direzione e alla revisione del codice piuttosto che alla sua scrittura.

Casi in cui Codex ha bisogno di miglioramenti

1. Codex non è ancora in grado di dedurre ciò che non gli è stato comunicato (ad esempio, i modelli di architettura preferiti, la strategia di prodotto, il comportamento reale degli utenti e le norme o scorciatoie interne).
2. Allo stesso modo, Codex non poteva vedere l'app effettivamente in funzione: non poteva aprire Sora su un dispositivo, notare che uno scroll non funzionava correttamente o percepire che un flusso era confuso. Solo il nostro team poteva occuparsi di questi aspetti relativi all'esperienza.
3. Ogni istanza richiede un processo di onboarding. Condividere il contesto con obiettivi chiari, vincoli e indicazioni su "come lavoriamo" è stato fondamentale per garantire il corretto funzionamento di Codex.
4. Allo stesso modo, Codex ha dovuto affrontare un difficile giudizio architettonico: lasciato a sé stesso, avrebbe potuto introdurre un modello di visualizzazione aggiuntivo laddove invece volevamo estendere uno esistente o inserire nella UI una logica che chiaramente apparteneva a un repository. Il suo istinto è quello di far funzionare qualcosa, non di dare priorità alla pulizia a lungo termine.

Abbiamo trovato utile che Codex creasse e conservasse una quantità generosa di file AGENT.md in tutto il codice. Ciò ha reso facile applicare le stesse linee guida e best practice in tutte le sessioni. Ad esempio, per garantire che Codex scrivesse il codice secondo le nostre linee guida di stile, abbiamo aggiunto quanto segue al nostro AGENTS.md di livello superiore:

In cosa eccelle Codex

1. Leggere e comprendere rapidamente grandi codici: Codex conosce praticamente tutti i principali linguaggi di programmazione, il che rende più facile sfruttare gli stessi concetti su molte piattaforme senza complesse astrazioni.
2. Copertura dei test: Codex è (particolarmente) attento alla scrittura di test unitari che coprano un'ampia varietà di casi. Non tutti i test erano approfonditi, ma l'ampiezza della copertura è stata utile per prevenire regressioni. 
3. Applicazione del feedback: allo stesso modo, Codex è in grado di gestire efficacemente il feedback. Quando CI non funzionava, era possibile incollare l'output del log in un prompt e chiedere a Codex di proporre delle soluzioni.
4. Esecuzione massivamente parallela e usa e getta: la maggior parte non supererà i limiti del numero di sessioni che potrebbero effettivamente eseguire in un dato momento. È molto fattibile testare più idee contemporaneamente e considerare il codice come usa e getta.
5. Offrire una nuova prospettiva: nelle discussioni sullo sviluppo, abbiamo utilizzato Codex come strumento generativo per esplorare potenziali punti di errore e scoprire nuovi modi per risolvere un problema. Ad esempio, mentre progettavamo ottimizzazioni della memoria del lettore video, Codex ha filtrato diversi SDK per proporre approcci che non avremmo avuto il tempo di analizzare. Le informazioni ottenute dalla ricerca di Codex si sono rivelate preziose per ridurre al minimo l'impronta di memoria nell'app finale.
6. Consentire un lavoro più efficiente: in pratica, abbiamo finito per dedicare più tempo alla revisione e alla supervisione del codice che alla sua scrittura. Detto ciò, Codex è molto efficace anche nella revisione del codice, spesso individuando i bug prima che vengano integrati, migliorando così l'affidabilità.

Una volta riconosciute queste caratteristiche, il nostro modello di lavoro è diventato più lineare. Ci siamo affidati a Codex per svolgere un enorme lavoro all'interno di modelli ben compresi e ambiti ben definiti, mentre il nostro team si è concentrato sull'architettura, l'esperienza utente, i cambiamenti sistemici e la qualità finale.

Anche il miglior nuovo assunto senior non ha immediatamente la giusta prospettiva per prendere decisioni a lungo termine. Per sfruttare Codex e garantire che il suo funzionamento fosse solido e sostenibile, era fondamentale supervisionare noi stessi la progettazione dei sistemi dell'app e le decisioni chiave. Questi includevano la definizione dell'architettura dell'app, la modularizzazione, la dependency injection e la navigazione; abbiamo anche implementato l'autenticazione e i flussi di rete di base. 

Partendo da queste basi, abbiamo scritto alcune funzionalità rappresentative end-to-end. Abbiamo utilizzato le regole che volevamo fossero seguite dall'intero codice e documentato i modelli a livello di progetto man mano che procedevamo. Indirizzando Codex verso funzionalità rappresentative, è stato in grado di operare più autonomamente all'interno dei nostri standard. Per un progetto che stimiamo sia stato scritto all'85% da Codex, una base pianificata con cura ha evitato costosi ripensamenti e rifattorizzazioni. È stata una delle decisioni più importanti che abbiamo preso. 

L'idea non era quella di realizzare "qualcosa che funzionasse" il più rapidamente possibile, ma piuttosto di realizzare "qualcosa che funzionasse come volevamo noi". Esistono molti modi "corretti" per scrivere un codice. Non avevamo bisogno di spiegare a Codex esattamente cosa fare; dovevamo solo mostrare a Codex cosa fosse "corretto" per il nostro team. Una volta stabilito il punto di partenza e il modo in cui volevamo procedere, Codex era pronto per iniziare.

Per vedere cosa sarebbe successo, abbiamo provato con il prompt: "Crea l'app Sora per Android basandoti sul codice iOS". Ma abbiamo rapidamente abbandonato questa strada. Sebbene ciò che Codex ha creato funzionasse tecnicamente, l'esperienza del prodotto era scadente. E senza una chiara comprensione degli endpoint, dei dati e dei flussi degli utenti, il codice single-shot di Codex era inaffidabile (anche senza utilizzare un agente, è rischioso unire migliaia di righe di codice). 

Abbiamo ipotizzato che Codex avrebbe funzionato bene in un ambiente sandbox con esempi ben scritti, e avevamo ragione. Chiedere a Codex di "creare questa schermata delle impostazioni" senza quasi nessun contesto non era affidabile Chiedere a Codex di "creare questa schermata delle impostazioni usando la stessa struttura e gli stessi modelli dell'altra schermata che hai appena visto" ha funzionato decisamente meglio Gli esseri umani hanno preso le decisioni strutturali e hanno impostato le invarianti, Codex ha poi inserito una grande quantità di codice all'interno di quella struttura.

Il passo successivo per massimizzare il potenziale di Codex è stato capire come farlo funzionare per lunghi periodi di tempo (recentemente, più di 24 ore⁠) senza supervisione.

All'inizio dell'uso di Codex, siamo passati rapidamente a prompt come: "Ecco la funzionalità. Ecco alcuni file. Per favore, creala". A volte funzionava, ma il più delle volte produceva un codice che tecnicamente era compilabile, ma che si allontanava dalla nostra architettura e dai nostri obiettivi.

Quindi abbiamo modificato il flusso di lavoro. Per qualsiasi cambiamento non banale, abbiamo prima chiesto a Codex di aiutarci a capire come funzionassero il sistema e il codice. Ad esempio, gli abbiamo chiesto di leggere una serie di file correlati e di riassumere il funzionamento di quella funzione; ad esempio, come i dati fluiscono dall'API attraverso il livello di repository, il modello di visualizzazione e nell'interfaccia utente. Quindi correggevamo o perfezionavamo la sua comprensione. (Ad esempio, facevamo notare che una particolare astrazione apparteneva in realtà a un livello diverso o che una determinata classe esisteva solo per la modalità offline e non doveva essere estesa).

Allo stesso modo in cui potresti coinvolgere un nuovo collega estremamente competente, abbiamo collaborato con Codex per creare un solido piano di implementazione. Questo piano era spesso simile a un documento di progettazione in miniatura che indicava quali file dovevano essere modificati, quali nuovi stati dovevano essere introdotti e come doveva fluire la logica. Solo allora abbiamo chiesto a Codex di iniziare ad attuare il piano, un passo alla volta. Un consiglio utile: per le attività molto lunghe, in cui raggiungevamo il limite della nostra finestra di contesto, chiedevamo a Codex di salvare il suo piano in un file, consentendoci di applicare la stessa direzione in tutte le istanze.

Questo ciclo di pianificazione aggiuntivo si è rivelato utile. Ci ha permesso di lasciare Codex "senza supervisione" per lunghi periodi, perché conoscevamo i suoi piani. Ha reso più semplice la revisione del codice, perché potevamo controllare l'implementazione rispetto al nostro piano, invece di leggere una diff senza contesto. E quando qualcosa andava storto, potevamo prima eseguire il debug del piano e poi del codice. 

La dinamica era simile a quella che si ottiene quando un buon documento di progettazione infonde fiducia in un progetto al responsabile tecnico. Non stavamo semplicemente creando un codice: stavamo sviluppando un codice che supportava una roadmap condivisa.

Nel momento di massima attività del progetto, spesso eseguivamo più sessioni Codex in parallelo. Una era dedicata alla riproduzione, un'altra alla ricerca, un'altra ancora alla gestione degli errori e talvolta un'altra ai test o alle rifattorizzazioni. Più che usare uno strumento, sembrava di gestire un team.

Ogni sessione ci forniva periodicamente un resoconto dei progressi compiuti. Qualcuno poteva dire: "Ho finito di pianificare questo modulo; ecco cosa propongo", mentre un altro poteva presentare un diff consistente per una nuova funzionalità. Ognuno richiedeva attenzione, feedback e revisione. Era molto simile all'essere un responsabile tecnico con diversi nuovi ingegneri, tutti impegnati a compiere progressi e tutti bisognosi di guida.

Il risultato è stato un flusso collaborativo. La funzionalità di coding di Codex ci ha sollevato da gran parte del lavoro di digitazione manuale. Abbiamo avuto più tempo per riflettere sull'architettura, esaminare attentamente le pull request e testare l'app. 

Allo stesso tempo, quella maggiore velocità significava che avevamo sempre qualcosa in attesa nella nostra coda di revisione. Codex non veniva bloccato dal cambio di contesto, ma noi sì. Il nostro collo di bottiglia nello sviluppo si è spostato dalla scrittura del codice al prendere decisioni, fornire feedback e integrare i cambiamenti.

È qui che le intuizioni di Brooks assumono una nuova dimensione. Non è possibile semplicemente aggiungere sessioni Codex e aspettarsi accelerazioni lineari, così come non è possibile continuare ad aggiungere ingegneri a un progetto e aspettarsi che i tempi si riducano in modo lineare. Ogni "mano" in più, anche virtuale, aumenta il costo di coordinamento Eravamo diventati il direttore di un'orchestra, invece che semplici solisti più veloci.

Abbiamo iniziato il nostro progetto con un enorme vantaggio: Sora era già disponibile su iOS. Abbiamo spesso indirizzato Codex verso i codici base iOS e backend per aiutarlo a comprendere i requisiti e i vincoli principali. Durante tutto il progetto abbiamo scherzato sul fatto che avevamo reinventato l'idea di un framework multipiattaforma. Dimentica React Native o Flutter: il futuro della multipiattaforma è solo Codex.

Dietro la battuta si celano due principi:

1. La logica è portatile. Che il codice sia scritto in Swift o Kotlin, la logica sottostante dell'applicazione (modelli di dati, chiamate di rete, regole di convalida, logica di business) è la stessa. Codex è molto abile nel leggere un'implementazione in Swift e nel produrre un equivalente in Kotlin che ne preservi la semantica.
2. Gli esempi concreti forniscono un contesto efficace. Una nuova sessione Codex che mostra "ecco esattamente come funziona su iOS" e "ecco l'architettura Android" è molto più efficace di una che si basa solo su descrizioni con linguaggio naturale.

Applicando questi principi, abbiamo reso disponibili i repository iOS, backend e Android nello stesso ambiente. Abbiamo fornito a Codex dei prompt come:

"Leggi questi modelli ed endpoint nel codice iOS e poi proponi un piano per implementare il comportamento equivalente su Android utilizzando il nostro client API esistente e le classi di modelli".

Un piccolo ma utile trucco era specificare in  ~/.codex/AGENTS.md dove si trovavano i repository locali e cosa contenevano. Ciò ha reso più facile per Codex individuare e navigare nel codice pertinente.

Abbiamo effettivamente realizzato uno sviluppo multipiattaforma attraverso la traduzione anziché l'astrazione condivisa. Poiché Codex ha gestito la maggior parte della traduzione, abbiamo evitato di raddoppiare i costi di implementazione.

In generale, per Codex il contesto è tutto. Codex ha dato il meglio di sé quando ha compreso come funzionava già la funzione in iOS, insieme alla comprensione di come era strutturata la nostra app Android. Quando Codex non conosceva quel contesto, non era che "si rifiutasse di collaborare", ma stava procedendo per tentativi. Più lo trattavamo come un nuovo membro del team e più investivamo nel fornirgli gli input giusti, migliori erano le sue prestazioni.

Alla fine del nostro sprint di quattro settimane, l'uso di Codex ha smesso di sembrare un esperimento ed è diventato il nostro ciclo di sviluppo predefinito. Lo abbiamo utilizzato per comprendere il codice esistente, pianificare le modifiche e implementare le funzionalità. Abbiamo revisionato i suoi output proprio come avremmo fatto con quelli di un membro del team. Era semplicemente il modo in cui lanciavamo il software.

È diventato chiaro che lo sviluppo assistito dall'IA non riduce la necessità di controlli rigorosi, ma piuttosto la aumenta. Per quanto Codex sia capace, il suo obiettivo è arrivare da A a B, al momento. Ecco perché la programmazione assistita dall'IA non funziona senza l'intervento umano. Gli ingegneri del software sono in grado di comprendere e applicare i vincoli reali dei sistemi, i modi migliori per progettare il software e come svilupparlo tenendo conto dei piani di sviluppo e dei prodotti futuri. I superpoteri degli ingegneri del software di domani saranno una profonda comprensione dei sistemi e la capacità di collaborare con l'IA su orizzonti temporali di lungo periodo. 

Gli aspetti più interessanti dell'ingegneria del software sono la creazione di prodotti accattivanti, la progettazione di sistemi scalabili, la scrittura di algoritmi complessi e la sperimentazione con dati, modelli e codice. Tuttavia, la realtà dell'ingegneria del software del passato e del presente è spesso più banale: allineare pulsanti, collegare endpoint e scrivere codice boilerplate. Ora, Codex consente di concentrarsi sugli aspetti più significativi dell'ingegneria del software e sui motivi per cui amiamo il nostro mestiere.

Una volta che Codex è configurato in un ambiente ricco di contesto in cui comprende i tuoi obiettivi e il tuo modo di lavorare, qualsiasi team può moltiplicare le proprie funzionalità. La nostra retrospettiva di lancio non è una soluzione universale e non pretendiamo di aver risolto il problema dello sviluppo assistito dall'IA. Tuttavia, speriamo che la nostra esperienza renda più facile trovare i modi migliori per potenziare Codex e potenziare te stesso. 

Quando Codex è stato lanciato in anteprima sette mesi fa, l'ingegneria del software era molto diversa. Grazie a Sora, abbiamo potuto esplorare il prossimo capitolo dell'ingegneria. Man mano che i nostri modelli e le nostre risorse continuano a migliorare, l'IA diventerà una parte sempre più indispensabile dello sviluppo. 

Cosa realizzerai con il tuo team di Codex?