Com vam utilitzar Codex per crear Sora per a Android en 28 dies

A data de 26 d’abril de 2026, el producte Sora ja no està disponible.

Al novembre, vam llançar al món l’app Sora per a Android, donant a qualsevol persona amb un dispositiu Android la possibilitat de convertir una indicació breu en un vídeo vibrant. El dia del llançament, l’app va arribar al número 1 de la Play Store. Els usuaris d’Android van generar més d’un milió de vídeos en les primeres 24 hores.

Al darrere del llançament hi ha una història: la versió inicial de l’app de producció de Sora per a Android es va crear en 28 dies, gràcies al mateix agent que està disponible per a qualsevol equip o desenvolupador: Codex.

Del 8 d’octubre al 5 de novembre de 2025, un equip reduït d’enginyeria treballant al costat de Codex i consumint aproximadament 5.000 milions de segments va portar Sora per a Android del prototip al llançament global. Malgrat la seva escala, l’app té una taxa sense fallades del 99,9 per cent i una arquitectura de la qual estem orgullosos. Si et preguntes si vam fer servir un model secret, vam utilitzar una versió primerenca del model GPT‑5.1‑Codex, la mateixa versió que qualsevol desenvolupador o empresa pot fer servir avui mitjançant CLI, extensió d’IDE o aplicació web.

Quan Sora es va llançar a iOS, l’ús es va disparar. La gent de seguida va començar a generar un flux de vídeos. A Android, en canvi, només teníem un petit prototip intern i un nombre creixent d’usuaris preregistrats a Google Play.

Una resposta habitual a un llançament d’alt risc i amb pressió de temps és acumular recursos i afegir procés. Una app de producció d’aquest abast i qualitat normalment implicaria molts enginyers treballant durant mesos, alentits per la coordinació.

El famós arquitecte informàtic nord-americà Fred Brooks va advertir que «afegir més persones a un projecte de programari endarrerit el retarda encara més». Dit d’una altra manera, quan s’intenta llançar ràpidament un projecte complex, afegir més enginyers sovint pot reduir l’eficiència en augmentar la sobrecàrrega de comunicació, la fragmentació de tasques i els costos d’integració. En lloc d’ignorar aquesta idea, la vam assumir; vam reunir un equip sòlid de quatre enginyers, tots equipats amb Codex per augmentar dràsticament l’impacte de cadascun.

Treballant d’aquesta manera, vam lliurar una versió interna de Sora per a Android als empleats en 18 dies i la vam llançar públicament 10 dies després. Vam mantenir un nivell alt en les pràctiques d’enginyeria Android, vam invertir en mantenibilitat i vam exigir a l’app el mateix nivell de fiabilitat que esperaríem d’un projecte més tradicional. (També continuem fent servir Codex de manera extensiva avui per evolucionar l’app i incorporar-hi funcions noves).

Per entendre com treballàvem amb Codex, ajuda saber en què destaca i on necessita orientació. Tractar-lo com un enginyer sènior acabat de contractar va ser un bon enfocament. La capacitat de Codex feia que poguéssim dedicar més temps a dirigir i revisar codi que no pas a escriure’l nosaltres mateixos.

On Codex necessita orientació

1. Codex encara no és gaire bo inferint allò que no se li ha dit (p. ex., els teus patrons d’arquitectura preferits, l’estratègia de producte, el comportament real dels usuaris i les normes internes o dreceres).
2. De la mateixa manera, Codex no podia veure l’app en execució: no podia obrir Sora en un dispositiu, notar que un desplaçament no acabava d’anar bé o percebre que un flux era confús. Només el nostre equip podia cobrir aquestes tasques vivencials.
3. Cada instància requereix incorporació. Compartir context amb objectius, restriccions i orientacions clares sobre «com fem les coses» era essencial perquè Codex executés bé.
4. En la mateixa línia, Codex tenia dificultats amb el criteri arquitectònic profund: deixat pel seu compte, podia introduir un view model addicional on en realitat volíem ampliar-ne un d’existent o portar lògica a la capa d’UI quan clarament havia d’anar a un repositori. El seu instint és fer que alguna cosa funcioni, no prioritzar la netedat a llarg termini.

Vam trobar útil fer que Codex creés i mantingués una quantitat generosa d’arxius AGENT.md a tot el codi base. Això facilitava aplicar la mateixa orientació i les mateixes bones pràctiques entre sessions. Per exemple, per assegurar-nos que Codex escrivia codi segons les nostres guies d’estil, vam afegir el següent al nostre AGENTS.md de nivell superior:

On Codex destaca

1. Llegint i entenent grans bases de codi ràpidament: Codex coneix essencialment tots els principals llenguatges de programació, cosa que facilita aprofitar els mateixos conceptes en moltes plataformes sense abstraccions complexes.
2. Cobertura de proves: Codex és (de manera única) entusiasta a l’hora d’escriure proves unitàries per cobrir una gran varietat de casos. No totes les proves eren profundes, però tenir amplitud de cobertura va ser útil per evitar regressions.
3. Aplicar comentaris: en la mateixa línia, Codex és bo reaccionant als comentaris. Quan la CI fallava, podíem enganxar la sortida del registre en una indicació i demanar a Codex que proposés correccions.
4. Execució massivament paral·lela i d’un sol ús: la majoria no portaran al límit el nombre de sessions que realment podrien executar alhora. És perfectament factible provar múltiples idees en paral·lel i considerar el codi com a prescindible.
5. Oferir una nova perspectiva: en debats de disseny, vam utilitzar Codex com a eina generativa per explorar possibles punts de fallada i descobrir noves maneres de resoldre un problema. Per exemple, mentre dissenyàvem optimitzacions de memòria del reproductor de vídeo, Codex va examinar diversos SDK per proposar enfocaments que no hauríem tingut temps d’analitzar. Les aportacions de la recerca de Codex van resultar inestimables per minimitzar l’empremta de memòria a l’app final.
6. Permetre feina de més impacte: a la pràctica, vam acabar dedicant més temps a revisar i dirigir codi que no pas a escriure’l nosaltres mateixos. Dit això, Codex també és molt bo fent revisió de codi i sovint detecta errors abans que es fusionin, millorant la fiabilitat.

Un cop vam reconèixer aquestes característiques, el nostre model de treball es va tornar més senzill. Vam recolzar-nos en Codex perquè fes una gran part de la feina pesada dins de patrons ben entesos i àmbits ben delimitats, mentre el nostre equip es concentrava en l’arquitectura, l’experiència d’usuari, els canvis sistèmics i la qualitat final.

Fins i tot la millor incorporació nova i sènior no té de seguida la perspectiva adequada per prendre decisions de compromís a llarg termini. Per aprofitar Codex i assegurar que la seva feina fos robusta i mantenible, era clau que superviséssim nosaltres mateixos el disseny dels sistemes de l’app i les decisions de compromís principals. Això incloïa definir l’arquitectura de l’app, la modularització, la injecció de dependències i la navegació; també vam implementar l’autenticació i els fluxos bàsics de xarxa.

A partir d’aquesta base, vam escriure unes quantes funcionalitats representatives d’extrem a extrem. Vam fer servir les regles que volíem que seguís tota la base de codi i vam documentar patrons de projecte transversals mentre avançàvem. En indicar a Codex funcionalitats representatives, va poder treballar amb més independència dins dels nostres estàndards. Per a un projecte que estimem que va ser escrit en un 85% per Codex, una base planificada amb cura va evitar marxa enrere i refactoritzacions costoses. Va ser una de les decisions més importants que vam prendre.

La idea no era fer «alguna cosa que funcioni» tan de pressa com fos possible, sinó fer «alguna cosa que entengui com volem que funcionin les coses». Hi ha moltes maneres «correctes» d’escriure codi. No necessitàvem dir a Codex exactament què havia de fer; necessitàvem mostrar a Codex què és «correcte» al nostre equip. Un cop vam establir el punt de partida i com ens agradava construir, Codex estava llest per començar.

Per veure què passaria, sí que vam provar la indicació: «Build the Sora Android app based on the iOS code. Go», però aviat vam abandonar aquest camí. Tot i que el que Codex va crear funcionava tècnicament, l’experiència de producte era mediocre. I sense una comprensió clara dels punts finals, de les dades i dels fluxos d’usuari, el codi d’un sol intent de Codex era poc fiable (fins i tot sense fer servir un agent, és arriscat fusionar milers de línies de codi.)

Vam plantejar la hipòtesi que Codex prosperaria en un entorn controlat d’exemples ben escrits, i teníem raó. Demanar a Codex que «construeixi aquesta pantalla de configuració» amb gairebé cap context no era fiable. Demanar a Codex que «construeixi aquesta pantalla de configuració fent servir la mateixa arquitectura i els mateixos patrons que aquesta altra pantalla que acabes de veure» funcionava molt millor. Els humans prenien les decisions estructurals i establien els invariants; Codex després omplia grans quantitats de codi dins d’aquesta estructura.

El següent pas per maximitzar el potencial de Codex va ser esbrinar com permetre que Codex treballés durant períodes llargs de temps (recentment, més de 24 hores⁠), sense supervisió.

Al principi d’utilitzar Codex, passàvem directament a indicacions com ara: «Aquí tens la funcionalitat. Aquí tens alguns fitxers. Si us plau, construeix-la». Això de vegades funcionava, però sovint produïa codi que compilava tècnicament mentre s’allunyava de la nostra arquitectura i dels nostres objectius.

Així que vam canviar el flux de treball. Per a qualsevol canvi no trivial, primer demanàvem a Codex que ens ajudés a entendre com funcionaven el sistema i el codi. Per exemple, li demanàvem que llegís un conjunt de fitxers relacionats i resumís com funcionava aquella funcionalitat; per exemple, com fluïen les dades des de l’API passant per la capa de repositori, el view model i fins a la UI. Després corregíem o refinàvem la seva comprensió. (Per exemple, assenyalàvem que una abstracció concreta en realitat pertanyia a una capa diferent o que una classe determinada només existia per al mode fora de línia i no s’havia d’ampliar.)

De manera similar a com pots relacionar-te amb un nou company molt capaç, vam treballar amb Codex per crear un pla d’implementació sòlid. Aquest pla sovint semblava un petit document de disseny que indicava quins fitxers s’havien de canviar, quins estats nous s’havien d’introduir i com havia de fluir la lògica. Només llavors demanàvem a Codex que comencés a aplicar el pla, un pas cada vegada. Un consell útil: per a tasques molt llargues, quan arribàvem al límit de la nostra finestra de context, demanàvem a Codex que desés el seu pla en un fitxer, cosa que ens permetia aplicar la mateixa direcció entre instàncies.

Aquest bucle extra de planificació va resultar valer el temps invertit. Ens permetia deixar que Codex funcionés «sense supervisió» durant trams llargs, perquè coneixíem els seus plans. Feia la revisió de codi més fàcil, perquè podíem comprovar la implementació contra el nostre pla en lloc de llegir un diff sense context. I quan alguna cosa anava malament, podíem depurar primer el pla i després el codi.

La dinàmica s’assemblava a la manera com un bon document de disseny dona confiança a un responsable tècnic en un projecte. No només generàvem codi: produíem codi que donava suport a un full de ruta compartit.

En el moment àlgid del projecte, sovint executàvem diverses sessions de Codex en paral·lel. Una treballava en la reproducció, una altra en la cerca, una altra en la gestió d’errors i, de vegades, una altra en proves o refactoritzacions. Semblava menys utilitzar una eina i més gestionar un equip.

Cada sessió ens informava periòdicament del progrés. Una podia dir: «Ja he acabat de planificar aquest mòdul; això és el que proposo», mentre una altra oferia un diff gran per a una funcionalitat nova. Totes requerien atenció, comentaris i revisió. S’assemblava d’una manera sorprenent a ser un responsable tècnic amb diversos enginyers nous, tots avançant, tots necessitant orientació.

El resultat va ser un flux col·laboratiu. La capacitat bruta de Codex per programar ens va alliberar de molta mecanografia manual. Teníem més temps per pensar en l’arquitectura, llegir les sol·licituds d'extracció amb atenció i provar l’app.

Alhora, aquella velocitat extra significava que sempre teníem alguna cosa esperant a la cua de revisió. Codex no quedava bloquejat pels canvis de context, però nosaltres sí. El nostre coll d’ampolla en el desenvolupament va passar de l’escriptura de codi a prendre decisions, donar comentaris i integrar canvis.

Aquí és on les idees de Brooks prenen una nova forma. No pots simplement afegir sessions de Codex i esperar acceleracions lineals, igual com no pots continuar afegint enginyers a un projecte i esperar que el calendari es redueixi linealment. Cada «parell de mans» addicional, fins i tot virtual, afegeix sobrecàrrega de coordinació. Ens havíem convertit en el director d’una orquestra en lloc de ser simplement solistes més ràpids.

Vam començar el projecte amb un enorme punt de suport: Sora ja s’havia llançat a iOS. Sovint orientàvem Codex cap a les bases de codi d’iOS i del backend perquè entengués requisits i restriccions clau. Durant tot el projecte fèiem broma dient que havíem reinventat la idea d’un framework multiplataforma. Oblideu React Native o Flutter; el futur de la multiplataforma és simplement Codex.

Sota aquesta broma hi ha dos principis:.

1. La lògica és portable. Tant si el codi està escrit en Swift com en Kotlin, la lògica subjacent de l’aplicació —models de dades, crides de xarxa, regles de validació, lògica de negoci— és la mateixa. Codex és molt bo llegint una implementació en Swift i produint-ne una d’equivalent en Kotlin que preservi la semàntica.
2. Els exemples concrets proporcionen un context potent. Una sessió nova de Codex que pot veure «així és exactament com funciona això a iOS» i «aquesta és l’arquitectura Android» és molt més eficaç que una que només treballa a partir de descripcions en llenguatge natural.

Posant aquests principis en pràctica, vam posar els repositoris d’iOS, backend i Android a disposició dins del mateix entorn. Donàvem a Codex indicacions com ara:

«Read these models and endpoints in the iOS code and then propose a plan to implement the equivalent behavior on Android using our existing API client and model classes.»

Un petit truc útil va ser detallar a ~/.codex/AGENTS.md on vivien els repositoris locals i què contenien. Això facilitava que Codex descobrís i navegés pel codi rellevant.

Estàvem fent efectivament desenvolupament multiplataforma mitjançant traducció en lloc d’abstracció compartida. Com que Codex gestionava la major part de la traducció, vam evitar duplicar els costos d’implementació.

La lliçó més general és que, per a Codex, el context ho és tot. Codex feia la seva millor feina quan entenia com funcionava ja la funcionalitat a iOS, combinat amb una comprensió de com estava estructurada la nostra app Android. Quan a Codex li faltava aquest context, no és que «es negués a cooperar»; és que endevinava. Com més el tractàvem com un company nou i invertíem a donar-li les entrades adequades, millor rendia.

Al final del nostre esprint de quatre setmanes, fer servir Codex va deixar de semblar un experiment i es va convertir en el nostre bucle de desenvolupament per defecte. El fèiem servir per entendre codi existent, planificar canvis i implementar funcionalitats. Revisàvem la seva sortida igual que revisaríem la d’un company. Simplement era la manera com lliuràvem programari.

Va quedar clar que el desenvolupament assistit per IA no redueix la necessitat de rigor; l’augmenta. Per molt capaç que sigui Codex, el seu objectiu és anar d’A a B, ara. És per això que la programació assistida per IA no funciona sense humans. Els enginyers de programari poden entendre i aplicar les restriccions del món real dels sistemes, les millors maneres d’arquitectar programari i com construir tenint en compte el desenvolupament futur i els plans de producte. Els superpoders de l’enginyer de programari de demà seran una comprensió profunda dels sistemes i la capacitat de treballar col·laborativament amb la IA durant horitzons temporals llargs.

Les parts més interessants de l’enginyeria de programari són crear productes convincents, dissenyar sistemes escalables, escriure algorismes complexos i experimentar amb dades, patrons i codi. Tanmateix, les realitats de l’enginyeria de programari del passat i del present sovint s’inclinen cap a tasques més mundanes: centrar botons, connectar punts finals i escriure codi repetitiu. Ara, Codex fa possible concentrar-se en les parts més significatives de l’enginyeria de programari i en les raons per les quals estimem el nostre ofici.

Un cop Codex està configurat en un entorn ric en context on entén els teus objectius i com t’agrada construir, qualsevol equip pot multiplicar les seves capacitats. La nostra retrospectiva del llançament no és una recepta universal, i no afirmem haver resolt el desenvolupament assistit per IA. Però esperem que la nostra experiència faci més fàcil trobar les millors maneres de capacitar Codex perquè et capaciti a tu.

Quan Codex es va llançar en una vista prèvia de recerca fa set mesos, l’enginyeria de programari tenia un aspecte molt diferent. A través de Sora, vam poder explorar el capítol següent de l’enginyeria. A mesura que els nostres models i el nostre entorn continuïn millorant, la IA esdevindrà una part cada cop més indispensable de la construcció.

Què crearàs amb el teu propi equip de Codex?