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

Sora dejó de estar disponible el 26 de abril de 2026.

En noviembre, lanzamos la aplicación Sora para Android a nivel mundial, lo cual permitió a cualquier persona que tuviera un dispositivo Android convertir un mensaje corto en un video vívido. El día del lanzamiento, la aplicación llegó al puesto N.° 1 en el Play Store. Los usuarios de Android generaron más de un millón de videos en las primeras 24 horas.

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

Desde el 8 de octubre hasta el 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 estabilidad 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 del IDE o la aplicación web.

Cuando Sora se lanzó en iOS, el uso se disparó. La gente inmediatamente comenzó a generar una serie de videos. En Android, por el contrario, solo contábamos con un pequeño prototipo interno y un número creciente de usuarios preregistrados en Google Play.

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

El arquitecto informático estadounidense Fred Brooks se popularizó por advertir que "agregar más personas a un proyecto de software atrasado lo retrasa aún más". En otras palabras, al intentar entregar rápidamente un proyecto complejo, agregar más ingenieros puede a menudo disminuir la eficiencia al aumentar la carga de comunicación, la fragmentación de tareas y los costos de integración. Aprovechamos 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. 

Al trabajar 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 en las prácticas de ingeniería de Android, invertimos en la facilidad de mantenimiento y exigimos a la aplicación el mismo nivel de confiabilidad que esperaríamos de un proyecto más tradicional. (Hoy en día seguimos utilizando Codex de forma intensiva para desarrollar y añadir nuevas funciones a la aplicación).

Para comprender cómo trabajamos con Codex, es útil saber en qué se 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 nos permitió dedicar más tiempo a dirigir y revisar el código en lugar de escribirlo nosotros mismos.

Dónde Codex necesita orientación

1. Codex todavía no es muy bueno para inferir lo que no se le ha comunicado (por ejemplo, tus patrones de arquitectura preferidos, la estrategia del producto, el comportamiento real de los usuarios y las normas o atajos internos).
2. Del mismo modo, Codex no podía ver cómo funcionaba realmente la aplicación: no podía abrir Sora en un dispositivo, darse cuenta de que un desplazamiento no funcionaba bien o percibir que un flujo era confuso. Solo nuestro equipo podía cubrir estas tareas experienciales.
3. Cada instancia requiere incorporación. Compartir el contexto con objetivos, restricciones y orientación claros sobre “cómo hacemos las cosas” fue esencial para que Codex se ejecutara bien.
4. En la misma línea, Codex se enfrentó a un profundo dilema arquitectónico: si se dejaba tal cual, podía introducir un modelo de vista adicional cuando lo que realmente queríamos era ampliar uno ya existente o introducir lógica en la capa de interfaz de usuario que claramente pertenecía a un repositorio. Su instinto es lograr que algo funcione, no dar prioridad a la pureza a largo plazo.

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

Dónde se destaca Codex

1. Leer y entender rápidamente grandes bases de código: Codex domina prácticamente todos los lenguajes de programación principales, lo que facilita el uso de los mismos conceptos en muchas plataformas sin necesidad de abstracciones complejas.
2. Cobertura de pruebas: Codex está especialmente entusiasmado con escribir pruebas unitarias para abarcar una amplia variedad de casos. No todas las pruebas fueron exhaustivas, pero contar con una amplia cobertura fue útil para prevenir regresiones. 
3. Aplicar comentarios: De manera similar, Codex es bueno para reaccionar a los comentarios. Cuando fallaba la integración continua (CI), podíamos pegar la salida de los registros en un mensaje y pedirle a Codex que propusiera correcciones.
4. Ejecución paralela y desechable a gran escala: La mayoría no llevará al límite la cantidad de sesiones que podrían ejecutar simultáneamente. Es muy factible probar varias ideas en paralelo y ver el código como desechable.
5. Ofrecer una nueva perspectiva: En las discusiones de diseño, usamos Codex como una herramienta generativa para explorar posibles puntos de falla y descubrir nuevas maneras de resolver un problema. Por ejemplo, mientras diseñábamos optimizaciones de memoria para el reproductor de video, Codex examinó múltiples SDKs para proponer 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 en la revisión de código, detectando a menudo errores antes de que se fusionen, lo que mejora la fiabilidad.

Una vez que reconocimos estas características, nuestro modelo de trabajo se volvió más simple. 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 enfocaba en la arquitectura, la experiencia del usuario, los cambios sistémicos y la calidad final.

Ni siquiera el mejor nuevo empleado sénior tiene la perspectiva adecuada para tomar decisiones a largo plazo de inmediato. Para aprovechar Codex y asegurar que su trabajo fuera robusto y mantenible, era clave 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, desarrollamos algunas características 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ñalar a Codex hacia características representativas, pudo trabajar de forma más independiente 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 comprenda cómo queremos que las cosas funcionen". Hay muchas maneras “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é sucedería, intentamos con este mensaje: "Construye la aplicación Sora para Android basada en el código de iOS. Go”, pero rápidamente abandonó ese camino. Aunque lo que Codex creó técnicamente funcionó, la experiencia del producto fue deficiente. 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 confiable (Incluso sin usar un agente, es arriesgado fusionar miles de líneas de código). 

Planteamos la hipótesis de que Codex prosperaría en un entorno de ejemplos bien redactados, y acertamos. Pedirle a Codex que "construyera esta pantalla de configuración" con casi ningún contexto no era fiable. Pedirle a Codex que "construya esta pantalla de configuración usando la misma arquitectura y patrones de esta otra pantalla que acabas de ver" resultó mucho mejor. Los humanos tomaron las decisiones estructurales y establecieron los invariantes; luego, Codex llenó grandes cantidades de código dentro de esa estructura.

Nuestro siguiente paso para maximizar el potencial de Codex fue descubrir cómo habilitar a Codex para que funcione durante largos períodos de tiempo (recientemente, más de 24 horas⁠), sin supervisión.

Al principio de usar Codex, recurrimos a mensajes como, "Aquí está la función. Aquí tienes algunos archivos. Por favor, constrúyelo". A veces funcionaba, pero en la mayoría de los casos se generaba código que, aunque técnicamente se compilaba, se alejaba de nuestra arquitectura y nuestros 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 leyera un conjunto de archivos relacionados y resumiera cómo operaba 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 hacia la interfaz de usuario. Entonces corregiríamos o mejoraríamos su comprensión. (Por ejemplo, señalaríamos que una abstracción en particular realmente pertenece a otra capa o que una clase específica existe solo para el modo sin conexión y no debería extenderse.)

De manera similar a como podrías integrar 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 bucle de planificación adicional resultó valer el tiempo invertido. Nos permitió dejar que Codex operara "sin supervisión" durante largos períodos, porque conocíamos sus planes. Hizo que la revisión de código fuera más sencilla, ya que pudimos comprobar la implementación con nuestro plan en lugar de leer un diff sin contexto. Y cuando algo salía mal, podíamos depurar primero el plan y después el código. 

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 generábamos código: producíamos código que respaldaba una hoja de ruta compartida.

En el punto culminante 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 los avances. Uno podría decir: "He terminado de planear este módulo; esto es lo que propongo", mientras que otro podría ofrecer un gran cambio para una nueva función. Cada uno requería atención, comentarios 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 programación sin procesar de Codex nos liberó de mucho tecleo manual. Tuvimos más tiempo para pensar en la arquitectura, leer detenidamente las solicitudes de extracción y probar la aplicación. 

Al mismo tiempo, esa velocidad adicional implicaba que siempre teníamos algo en espera en nuestra cola de revisión. Codex no se bloqueó por el cambio de contexto, pero nosotros sí. Nuestro cuello de botella en el desarrollo pasó de la escritura de código a la toma de decisiones, la entrega de comentarios y la integración de cambios.

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

Comenzamos nuestro proyecto con un gran avance: Sora ya se había lanzado en iOS. Con frecuencia dirigíamos a Codex hacia los repositorios de código de iOS y backend para que pudiera entender los requisitos y limitaciones clave. A lo largo del proyecto bromeamos con que habíamos reinventado la idea de un framework multiplataforma. Olvídate de React Native o Flutter; el futuro de las multiplataformas es simplemente Codex.

Debajo de la broma 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 aplicación: modelos de datos, llamadas de red, reglas de validación, lógica Business, es la misma. Codex es muy bueno para leer una implementación en Swift y producir un equivalente en Kotlin que preserve la semántica.
2. Los ejemplos concretos proporcionan un contexto poderoso. Una nueva sesión 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.

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

“Lee estos modelos y puntos finales en el código de iOS y luego propone 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 el código relevante.

Estábamos efectivamente realizando desarrollo multiplataforma mediante traducción en lugar de una abstracción compartida. Como Codex se encargó de la mayor parte de la traducción, evitamos duplicar los costos de implementación.

La lección más amplia es que para Codex, el contexto lo es todo. Codex obtuvo los mejores resultados cuando comprendió cómo operaba ya la función 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 proporcionarle las entradas adecuadas, mejor rendía.

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

Quedó claro que el desarrollo asistido por IA no reduce la necesidad de rigor; la aumenta. Por muy capaz que sea Codex, su objetivo es llegar de A a B ahora. Por eso la programación asistida por IA no funciona sin humanos. Los ingenieros de software pueden comprender y aplicar las limitaciones reales de los sistemas, las mejores formas de diseñar software y cómo crear teniendo en cuenta el desarrollo futuro y los planes de producto. Los superpoderes del ingeniero de software del futuro serán un profundo entendimiento de los sistemas y la capacidad de trabajar colaborativamente con la IA a lo largo de extensos períodos de tiempo. 

Las partes más interesantes de la ingeniería de software son crear 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 permite centrarse en los aspectos más significativos de la ingeniería de software y en analizar por qué 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 estamos afirmando haber resuelto el desarrollo asistido por IA. Pero esperamos que nuestra experiencia facilite encontrar las mejores formas de empoderar a Codex para empoderarte. 

Cuando Codex se lanzó en una vista previa de investigación hace siete meses, la ingeniería de software era muy diferente. A través de Sora, exploramos el siguiente capítulo de la ingeniería. A medida que nuestros modelos y herramientas sigan mejorando, la IA se convertirá en una parte cada vez más indispensable del proceso de construcción. 

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