Cómo utilizamos Codex para desarrollar Sora para Android en 28 días

A partir del 26 de abril de 2026, el producto Sora dejará de estar disponible.

En noviembre, lanzamos la aplicación Sora para Android al mundo, permitiendo a cualquier persona con un dispositivo Android convertir una breve indicación en un vídeo vívido. El día del lanzamiento, la aplicación llegó al puesto número 1 en el Play Store. Los usuarios de Android generaron más de un millón de vídeos en las primeras 24 horas.

Detrás del lanzamiento hay una historia: la versión inicial de la aplicación de producción de Android de Sora se construyó en 28 días, gracias al mismo agente que está disponible para cualquier equipo o desarrollador: Codex.

Del 8 de octubre al 5 de noviembre de 2025, un equipo de ingeniería ágil, trabajando junto a Codex y consumiendo aproximadamente 5 000 millones de tokens, lanzó Sora para Android desde el prototipo hasta el lanzamiento global. A pesar de su escala, la aplicación tiene una tasa de funcionamiento sin fallos del 99,9 % y una arquitectura de la que estamos orgullosos. Si te preguntas si usamos un modelo secreto, utilizamos una versión temprana del modelo GPT‑5.1‑Codex: la misma versión que cualquier desarrollador o empresa puede usar hoy a través de CLI, la extensión IDE o la aplicación web.

Cuando Sora se lanzó en iOS, el uso se disparó. La gente empezó de inmediato a generar una serie de vídeos. En Android, por el contrario, solo teníamos un pequeño prototipo interno y un número creciente de usuarios prerregistrados en Google Play.

Una respuesta común a un lanzamiento de alto riesgo y con presión de tiempo es acumular recursos y añadir procesos. Una aplicación de producción de este alcance y calidad típicamente involucraría a muchos ingenieros trabajando durante meses, ralentizados por la coordinación. 

El arquitecto informático estadounidense Fred Brooks advirtió célebremente que «añadir más personas a un proyecto de software atrasado lo retrasa aún más». En otras palabras, cuando intentas enviar rápidamente un proyecto complejo, añadir más ingenieros puede ralentizar la eficiencia al aumentar la carga de comunicación, la fragmentación de tareas y los costes de integración. Nos apoyamos en esta idea en lugar de ignorarla; reunimos un equipo sólido de cuatro ingenieros, todos equipados con Codex para aumentar drásticamente el impacto de cada ingeniero. 

Trabajando de esta manera, enviamos una versión interna de Sora para Android a los empleados en 18 días y la lanzamos públicamente 10 días después. Mantuvimos un alto nivel de exigencia en las prácticas de ingeniería de Android, invertimos en la mantenibilidad y mantuvimos la aplicación al mismo nivel de fiabilidad que esperaríamos de un proyecto más tradicional. (También continuamos usando Codex extensamente hoy para evolucionar y añadir nuevas funciones a la aplicación).

Para entender cómo trabajamos con Codex, te ayuda saber dónde destaca y dónde necesita orientación. Tratarlo como a un ingeniero sénior recién contratado fue un buen enfoque. La capacidad de Codex significaba que podíamos dedicar más tiempo a dirigir y revisar el código que a escribirlo nosotros mismos.

Dónde Codex necesita orientación

1. Codex aún no es muy bueno para deducir lo que no se le ha comunicado (por ejemplo, tus patrones de arquitectura preferidos, estrategia de producto, comportamiento real de los usuarios y normas o accesos directos internos).
2. De manera similar, Codex no podía ver la aplicación ejecutarse realmente: no podía abrir Sora en un dispositivo, notar que un desplazamiento se sentía raro o percibir que un flujo era confuso. Solo nuestro equipo podría cubrir estas tareas experienciales.
3. Cada instancia requiere incorporación. Compartir el contexto con objetivos claros, restricciones y orientación sobre «cómo hacemos las cosas» fue esencial para que Codex funcionara bien.
4. En la misma línea, Codex tuvo dificultades con el juicio arquitectónico profundo: si se dejara solo, podría introducir un modelo de vista adicional donde realmente queríamos extender uno existente o trasladar la lógica a la capa de interfaz de usuario que claramente pertenecía a un repositorio. Su instinto es hacer que algo funcione, no priorizar la limpieza a largo plazo.

Nos pareció útil que Codex creara y mantuviera una cantidad generosa de archivos AGENT.md en toda la base de código. Esto hizo que fuera fácil aplicar la misma guía y mejores prácticas en todas las sesiones. Por ejemplo, para asegurarnos de que Codex escribiera código conforme a nuestras directrices de estilo, añadimos lo siguiente a nuestro archivo AGENTS.md de nivel superior:

Dónde destaca Codex

1. Leer y comprender grandes bases de código rápidamente: Codex conoce prácticamente todos los lenguajes de programación principales, lo que facilita el uso de los mismos conceptos en muchas plataformas sin abstracciones complejas.
2. Cobertura de pruebas: Codex está entusiasmado con escribir pruebas unitarias para cubrir una amplia variedad de casos. No todas las pruebas fueron profundas, pero tener una amplia cobertura fue útil para prevenir regresiones. 
3. Aplicando opiniones: de manera similar, Codex es bueno reaccionando a las opiniones. Cuando falló el CI, pudimos pegar la salida de los registros en una indicación y pedirle a Codex que propusiera soluciones.
4. Ejecución paralela y desechable a gran escala: la mayoría no llevará al límite el número de sesiones que podrían ejecutar simultáneamente. Es muy factible probar múltiples ideas en paralelo y ver el código como desechable.
5. Ofreciendo una nueva perspectiva: en los debates de diseño, usamos Codex como una herramienta generativa para explorar posibles puntos de fallo y descubrir nuevas formas de resolver un problema. Por ejemplo, mientras diseñábamos optimizaciones de memoria para el reproductor de vídeo, Codex revisó varios SDK para sugerir enfoques que no habríamos tenido tiempo de analizar. Los conocimientos de la investigación de Codex fueron invaluables para reducir la huella de memoria en la aplicación final.
6. Habilitar trabajos de mayor impacto: en la práctica, terminamos dedicando más tiempo a revisar y dirigir el código que a escribirlo nosotros mismos. Dicho esto, Codex también es muy bueno revisando código, detectando a menudo errores antes de que se fusionen, mejorando la fiabilidad.

Una vez que reconocimos estas características, nuestro modelo de trabajo se hizo más sencillo. Nos apoyamos en Codex para realizar una gran cantidad de trabajo pesado dentro de patrones bien comprendidos y alcances bien delimitados, mientras nuestro equipo se centraba en la arquitectura, la experiencia del usuario, los cambios sistémicos y la calidad final.

Incluso el mejor nuevo empleado sénior no tiene la perspectiva adecuada para tomar decisiones a largo plazo de inmediato. Para aprovechar Codex y asegurar que su funcionamiento fuera sólido y mantenible, era fundamental que supervisáramos nosotros mismos el diseño de sistemas de la aplicación y las decisiones clave. Esto incluyó dar forma a la arquitectura de la aplicación, la modularización, la inyección de dependencias y la navegación; también implementamos la autenticación y los flujos de red básicos. 

Desde esta base, escribimos algunas funciones representativas de principio a fin. Usamos las reglas que queríamos que todo el código siguiera y documentamos los patrones del proyecto a medida que avanzábamos. Al señalarle a Codex características representativas, pudo trabajar más independientemente dentro de nuestros estándares. Para un proyecto que estimamos fue escrito en un 85 % por Codex, una base cuidadosamente planificada evitó retrocesos y refactorizaciones costosas. Fue una de las decisiones más importantes que tomamos. 

La idea no era hacer «algo que funcione» lo más rápido posible, sino hacer «algo que entienda cómo queremos que las cosas funcionen». Hay muchas formas «correctas» de escribir código. No necesitábamos decirle a Codex exactamente qué hacer; necesitábamos mostrarle a Codex qué es lo «correcto» en nuestro equipo. Una vez que habíamos establecido nuestro punto de partida y cómo nos gustaba construir, Codex estaba listo para empezar.

Para ver qué pasaría, probamos a sugerir: «Construye la aplicación Sora para Android a partir del código de iOS. Go,» pero rápidamente abandonó ese camino. Aunque lo que Codex creó técnicamente funcionó, la experiencia del producto fue mediocre. Y sin una comprensión clara de los puntos finales, los datos y los flujos de usuarios, el código de un solo intento de Codex era poco fiable (incluso sin usar un agente, es arriesgado fusionar miles de líneas de código). 

Hipotetizamos que Codex prosperaría en un entorno de ejemplos bien escritos; y teníamos razón. Pedirle a Codex que «construya esta pantalla de configuración» con casi ningún contexto era poco fiable. Pedirle a Codex que «construya esta pantalla de configuración usando la misma arquitectura y patrones que esta otra pantalla que acabas de ver» funcionó mucho mejor. Los humanos tomaron las decisiones estructurales y establecieron los invariantes; luego, Codex rellenó grandes cantidades de código dentro de esa estructura.

Nuestro siguiente paso para maximizar el potencial de Codex fue averiguar cómo permitirle funcionar durante largos periodos de tiempo (recientemente, más de 24 horas⁠), sin supervisión.

Al principio de usar Codex, pasamos a indicaciones como: «Aquí está la función. Aquí tienes unos archivos. Por favor, constrúyelo.». Eso a veces funcionaba, pero la mayoría de las veces producía código que técnicamente se compilaba, aunque se apartaba de nuestra arquitectura y objetivos.

Así que cambiamos el flujo de trabajo. Para cualquier cambio no trivial, primero le pedimos a Codex que nos ayude a entender cómo funcionan el sistema y el código. Por ejemplo, le pediríamos que lea un conjunto de archivos relacionados y resuma cómo funciona esa función; por ejemplo, cómo los datos fluyen desde la API a través de la capa de repositorio, el modelo de vista y hasta la interfaz de usuario. Entonces corregiríamos o afinaríamos su comprensión. (Por ejemplo, señalaríamos que una abstracción específica realmente pertenece a otra capa o que una clase determinada existe solo para el modo sin conexión y no debería ampliarse).

De manera similar a cómo podrías involucrar a un nuevo compañero de equipo altamente capacitado, trabajamos con Codex para crear un plan de implementación sólido. Ese plan a menudo parecía un documento de diseño en miniatura que indicaba qué archivos debían cambiar, qué nuevos estados debían introducirse y cómo debía fluir la lógica. Solo entonces le pedimos a Codex que empezara a aplicar el plan, paso a paso. Un consejo útil: para tareas muy largas, donde alcanzamos el límite de nuestra ventana de contexto, le pedimos a Codex que guarde su plan en un archivo, lo que nos permite aplicar la misma dirección en diferentes instancias.

Este ciclo de planificación adicional resultó valer la pena. Nos permitió dejar que Codex funcionara «sin supervisión» durante largos períodos, porque conocíamos sus planes. Hizo que la revisión de código fuera más fácil, porque pudimos comprobar la implementación con nuestro plan en lugar de leer una diferencia sin contexto. Y cuando algo iba mal, podíamos depurar el plan primero y el código después. 

La dinámica se sentía similar a cómo un buen documento de diseño le da confianza a un líder técnico en un proyecto. No solo estábamos generando código: estábamos produciendo código que respaldaba una hoja de ruta compartida.

En el apogeo del proyecto, a menudo ejecutábamos múltiples sesiones de Codex en paralelo. Uno trabajaba en la reproducción, otro en la búsqueda, otro en el manejo de errores, y a veces otro en pruebas o refactorizaciones. Se sentía menos como usar una herramienta y más como gestionar un equipo.

Cada sesión nos informaría periódicamente sobre su progreso. Uno podría decir: «He terminado de planificar este módulo; aquí está lo que propongo», mientras que otro ofrecería una gran modificación para una nueva función. Cada uno requería atención, opinión y revisión. Era inquietantemente similar a ser un líder técnico con varios ingenieros nuevos, todos avanzando, todos necesitando orientación.

El resultado fue un flujo colaborativo. La capacidad de codificación en bruto de Codex nos liberó de mucho tecleo manual. Tuvimos más tiempo para pensar en la arquitectura, leer detenidamente las pull requests y probar la aplicación. 

Al mismo tiempo, esa velocidad extra significaba que siempre teníamos algo en espera en nuestra cola de revisión. Codex no se bloqueó por los cambios de contexto, pero nosotros sí. Nuestro cuello de botella en el desarrollo pasó de escribir código a tomar decisiones, dar opinión e integrar cambios.

Aquí es donde las ideas de Brooks aterrizan de una manera nueva. No puedes simplemente añadir sesiones de Codex y esperar aumentos de velocidad lineales, al igual que no puedes seguir añadiendo ingenieros a un proyecto y esperar que el cronograma se reduzca linealmente. Cada «par de manos» adicional, incluso virtuales, añade una sobrecarga de coordinación. Nos habíamos convertido en el director de una orquesta en lugar de simplemente ser solistas más rápidos.

Comenzamos nuestro proyecto con un gran paso: Sora ya se había lanzado en iOS. Con frecuencia dirigimos a Codex a las bases de código de iOS y backend para que comprenda los requisitos y restricciones clave. A lo largo del proyecto bromeamos diciendo que habíamos reinventado la idea de un marco multiplataforma. Olvídate de React Native o Flutter; el futuro de las plataformas cruzadas es solo Codex.

Debajo del chiste hay dos principios:

1. La lógica es portátil. Ya sea que el código esté escrito en Swift o Kotlin, la lógica subyacente de la solicitud, los modelos de datos, las llamadas de red, las reglas de validación y la lógica empresarial son las mismas. Codex es muy bueno leyendo una implementación en Swift y produciendo un equivalente en Kotlin que preserve la semántica.
2. Los ejemplos concretos proporcionan un contexto poderoso. Una sesión nueva de Codex que puede ver «aquí está exactamente cómo funciona esto en iOS» y «aquí está la arquitectura de Android» es mucho más efectiva que una que solo trabaja a partir de descripciones en lenguaje natural.

Aplicando estos principios, hicimos que los repositorios de iOS, backend y Android estuvieran disponibles en el mismo entorno. Le dimos indicaciones a Codex como:

«Lee estos modelos y puntos finales en el código de iOS y luego propón un plan para implementar el comportamiento equivalente en Android utilizando nuestro cliente de API y clases de modelo existentes.»

Un pequeño pero útil truco fue detallar en ~/.codex/AGENTS.md dónde vivían los repositorios locales y qué contenían. Eso facilitó que Codex descubriera y navegara por el código relevante.

Estábamos efectivamente desarrollando multiplataforma mediante la traducción en lugar de una abstracción compartida. Como Codex manejó la mayor parte de la traducción, evitamos duplicar los costes de implementación.

La lección más amplia es que para Codex, el contexto lo es todo. Codex hizo su mejor trabajo cuando entendió cómo funcionaba la característica en iOS, junto con una comprensión de cómo estaba estructurada nuestra aplicación para Android. Cuando a Codex le faltaba ese contexto, no se estaba «negando a cooperar»; estaba adivinando. Cuanto más lo tratábamos como a un nuevo compañero de equipo e invertíamos en darle las entradas correctas, mejor funcionaba.

Al final de nuestro sprint de cuatro semanas, usar Codex dejó de sentirse como un experimento y se convirtió en nuestro bucle de desarrollo predeterminado. Lo usamos para entender el código existente, hacer un plan de cambios e implementar funciones. Revisamos su salida de la misma manera que revisaríamos la de un compañero de equipo. Era simplemente cómo enviábamos software.

Quedó claro que el desarrollo asistido por IA no reduce la necesidad de rigor; al contrario, la incrementa. Tan capaz como es Codex, su objetivo es ir de A a B, ahora. Por eso la programación asistida por IA no funciona sin personas. Los ingenieros de software pueden entender y aplicar las limitaciones reales de los sistemas, las mejores maneras de diseñar software y cómo construir pensando en el desarrollo futuro y los planes de producto. Los superpoderes del ingeniero de software del mañana serán un profundo entendimiento de los sistemas y la capacidad de colaborar con la IA a lo largo de extensos horizontes temporales. 

Las partes más interesantes de la ingeniería de software son construir productos atractivos, diseñar sistemas escalables, escribir algoritmos complejos y experimentar con datos, patrones y código. Sin embargo, las realidades de la ingeniería de software del pasado y del presente a menudo son más mundanas: centrar botones, conectar puntos finales y escribir código repetitivo. Ahora, Codex hace posible que te concentres en las partes más significativas de la ingeniería de software y en las razones por las que amamos nuestro oficio.

Una vez que Codex esté configurado en un entorno rico en contexto donde entienda tus objetivos y cómo te gusta construir, cualquier equipo puede multiplicar sus capacidades. Nuestro retro de lanzamiento no es una receta única para todos, y no pretendemos haber resuelto el desarrollo asistido por IA. Pero esperamos que nuestra experiencia haga más fácil encontrar las mejores maneras de empoderar a Codex para empoderarte. 

Cuando Codex se lanzó en una previsualización de investigación hace siete meses, la ingeniería de software se veía muy diferente. A través de Sora, pudimos explorar el siguiente capítulo de la ingeniería. A medida que nuestros modelos y arneses sigan mejorando, la IA se convertirá en una parte cada vez más indispensable de la construcción. 

¿Qué harás con tu propio equipo de Codex?