OpenAI creó la app de Sora para móviles Android en solo 18 días. Su secreto fue dejar que la IA hiciera el trabajo

En el mundo del desarrollo de software, existe una ley no escrita (bueno, en realidad sí está escrita, se llama Ley de Brooks) que dice que "añadir mano de obra a un proyecto de software retrasado, lo retrasa aún más". Si quieres lanzar una aplicación compleja, estable y masiva en tiempo récord, la lógica tradicional dicta que necesitas un ejército de ingenieros y meses de planificación.

OpenAI acaba de demostrar que la lógica tradicional está a punto de caducar.

El pasado mes de noviembre, la compañía lanzó Sora en Android. La aplicación se disparó inmediatamente al número 1 en la Google Play Store, y en sus primeras 24 horas, los usuarios generaron más de un millón de vídeos. Hasta aquí, el éxito habitual de un producto viral. Pero la verdadera noticia no está en lo que hace la app, sino en cómo se hizo.

Un equipo de solo cuatro ingenieros construyó la versión de producción de Sora para Android en 28 días. El prototipo funcional estuvo listo en apenas 18 días. ¿Cómo es posible? Porque no eran cuatro ingenieros trabajando solos. Eran cuatro humanos dirigiendo a una legión de agentes de IA impulsados por Codex (una versión temprana de GPT-5.1).

Ignorando las reglas para ganar velocidad

Cuando Sora se lanzó en iOS y el uso explotó, la presión para llegar a Android era inmensa. Lo normal hubiera sido contratar a un equipo grande de desarrolladores de Android, coordinar sprints, diseñar arquitecturas y asumir que el lanzamiento tardaría meses.

En lugar de eso, OpenAI decidió apoyarse en la agilidad extrema. Mantuvieron el equipo pequeño para evitar la burocracia y la sobrecarga de comunicación, pero equiparon a cada ingeniero con Codex. Durante el proceso, consumieron aproximadamente 5.000 millones de tokens.

El resultado fue una aplicación con una tasa de estabilidad del 99,9% construida en menos de un mes. No utilizaron un modelo secreto inalcanzable; usaron la misma tecnología que hoy está disponible para desarrolladores a través de la API y las herramientas de OpenAI.

Codex es el "Ingeniero Senior" que necesita supervisión

Patrick Hum y RJ Marsan, del equipo técnico de OpenAI, explican que la clave no fue pedirle a la IA que "hiciera la app", sino tratar a Codex como si fuera un nuevo ingeniero senior recién contratado.

Tiene capacidades sobrehumanas: conoce todos los lenguajes, escribe tests unitarios a una velocidad vertiginosa y puede leer bases de código enteras en segundos. Pero, como todo recién llegado, le falta contexto. Codex brilla en la ejecución bruta:

• Cobertura de tests: le encanta escribir pruebas unitarias, lo que ayudó a prevenir regresiones.
• Trabajo en paralelo: los ingenieros podían ejecutar múltiples sesiones de Codex a la vez. Mientras una instancia arreglaba un bug, otra refactorizaba un módulo y otra diseñaba una nueva función.
• Traducción de lógica: entiende Swift (iOS) y puede escribir su equivalente en Kotlin (Android) manteniendo la semántica.

Sin embargo, necesita dirección. Codex no puede "ver" la app. No sabe si una animación se siente tosca o si un flujo de usuario es confuso. Y, si se le deja solo, tiende a priorizar que las cosas "funcionen" sobre que el código sea limpio a largo plazo.

Para solucionar esto, el equipo creó archivos en el repositorio que eran, esencialmente, manuales de instrucciones para la IA: "Así es como hacemos las cosas aquí", "Ejecuta siempre este comando antes de hacer commit", "Usa esta arquitectura específica".

Primero planificar, luego programar

Logo de OpenAI en un smartphone

El equipo descubrió rápidamente que pedirle a la IA "construye esta pantalla" daba resultados mediocres. El código compilaba, pero la arquitectura era un desastre.

Cambiaron el enfoque. Antes de escribir una sola línea de código, le pedían a Codex que leyera los archivos, entendiera el sistema y propusiera un plan.

"Lee estos modelos y puntos finales en el código de iOS y propón un plan para implementar el comportamiento equivalente en Android usando nuestro cliente de API existente".

Solo cuando el plan (que actuaba como un mini-documento de diseño) era aprobado por los humanos, Codex empezaba a ejecutarlo. Esto permitió dejar a la IA trabajando sin supervisión durante largos periodos, porque ya sabían qué iba a hacer, no solo cómo.

El cuello de botella dejó de ser "escribir código" para convertirse en "revisar código y tomar decisiones". Los ingenieros humanos pasaron de ser solistas picando teclas a ser directores de orquesta gestionando múltiples hilos de trabajo simultáneos.

¿El fin de Flutter y React Native?

Hay una lectura fascinante en este caso de estudio que podría cambiar el desarrollo móvil para siempre. Durante años, hemos usado frameworks multiplataforma como React Native o Flutter para ahorrar tiempo, escribiendo el código una vez y ejecutándolo en iOS y Android, a costa de perder algo de rendimiento o sensación nativa.

OpenAI bromea con que han reinventado el concepto multiplataforma. "Olvídate de React Native o Flutter; el futuro de las plataformas cruzadas es solo Codex".

No usaron una capa de abstracción. Usaron la IA para traducir. Le daban a Codex el código nativo de iOS (Swift) y le pedían que escribiera el código nativo para Android (Kotlin). La lógicaes la misma, solo cambia la sintaxis. Esto les permitió tener dos aplicaciones 100% nativas, con el rendimiento y la calidad que eso conlleva, pero con la velocidad de desarrollo de un solo código base.

Conclusión: La nueva era de la ingeniería

La historia de Sora para Android nos deja una lección clara: la IA no reemplaza al ingeniero, pero eleva su nivel. El propio Sundar Pichai, CEO de Alphabet, ya defendió este tipo de estrategias, y OpenAI ha sido una de las primeras en aplicar dichas técnicas al desarrollo de un producto masivo.

El trabajo "mundano" (centrar botones, conectar APIs, escribir código repetitivo) desaparece. El ingeniero del futuro (y del presente, en el caso de OpenAI) se dedica a diseñar sistemas, asegurar la calidad, definir la experiencia de usuario y orquestar a la IA.

Si cuatro personas pueden hacer en 18 días lo que antes requería un departamento entero, la pregunta ya no es si debes usar IA en tu flujo de trabajo. La pregunta es qué vas a hacer con todo ese tiempo que vas a ganar.