Mostrar resumen Ocultar resumen
- Cómo se levantó Sora en Android en semanas
- Codex como fuerza multiplicadora del equipo
- Organización interna: reglas y manuales para la IA
- Planificación antes de la codificación: un cambio de paradigma
- La traducción de plataformas: alternativa a Flutter y React Native
- El nuevo rol del ingeniero en proyectos acelerados
OpenAI puso en marcha una versión nativa de Sora para Android en tiempo récord. Lo notable no fue solo la acogida del público, sino la forma en que el equipo lo construyó. Un grupo pequeño apoyado por agentes de IA transformó un proceso que suele tardar meses en semanas.
Cómo se levantó Sora en Android en semanas
La llegada de Sora a Android fue explosiva. En 24 horas la app escaló hasta el primer puesto de la Play Store y se generaron más de un millón de vídeos.
GTA VI: ganas, miedo y el problema que ya vivimos antes
Halo 2 y 3: remakes en desarrollo activo, no solo Campaign Evolved
En vez de ampliar la plantilla, OpenAI apostó por un equipo reducido. Solo cuatro ingenieros llevaron la versión final a producción en menos de un mes.
El prototipo funcional estuvo listo en apenas 18 días. La versión de producción se completó en torno a 28 días.
El secreto fue delegar la ejecución repetitiva en agentes de IA basados en Codex, una iteración temprana de los sistemas de lenguaje avanzados de OpenAI.
Codex como fuerza multiplicadora del equipo
Codex no sustituyó a los desarrolladores. Fue una herramienta que aumentó su productividad.
- Paralelismo: múltiples instancias trabajaban a la vez en distintas partes del código.
- Generación de tests: la IA escribió baterías de pruebas unitarias rápidas para evitar regresiones.
- Traducción entre plataformas: pudo convertir lógica escrita en Swift a implementaciones nativas en Kotlin.
Los ingenieros consumieron alrededor de 5.000 millones de tokens durante el desarrollo. El resultado: una app con cerca del 99,9% de estabilidad en su lanzamiento.
Organización interna: reglas y manuales para la IA
Para que Codex cumpliera con los estándares del equipo, los ingenieros plantearon un conjunto de normas.
- Archivos en el repositorio con instrucciones claras sobre estilo y procesos.
- Comandos obligatorios que la IA debía ejecutar antes de cada commit.
- Restricciones arquitectónicas para mantener coherencia entre plataformas.
Sin estas guías, la IA tiende a priorizar soluciones rápidas sobre mantenibilidad a largo plazo. Las reglas hicieron la diferencia.
Planificación antes de la codificación: un cambio de paradigma
El equipo comprobó que pedir directamente «construye esta pantalla» no era suficiente. El código compilaba, pero la arquitectura fallaba.
En respuesta implementaron un flujo distinto: primero solicitar a Codex que revise el código existente y proponga un plan.
- Lectura del código iOS y APIs existentes.
- Propuesta de diseño para Android que respetara el cliente de API.
- Aprobación humana del plan.
- Ejecución automática por parte de la IA.
Con ese método, los ingenieros dejaron que la IA trabajara durante largos periodos sin supervisión continua. Su papel cambió a revisar y tomar decisiones estratégicas.
La traducción de plataformas: alternativa a Flutter y React Native
En lugar de usar un framework multiplataforma, OpenAI convirtió el código nativo. Tradujeron Swift a Kotlin manteniendo la semántica.
Así lograron dos aplicaciones 100% nativas con rendimiento y experiencia de usuario propios de cada sistema.
La propuesta plantea una pregunta: ¿la IA puede reemplazar capas de abstracción multiplataforma?
- Ventajas: apps nativas, mejor rendimiento y control fino de UX.
- Desventajas: dependencia de la calidad de las traducciones automáticas.
El nuevo rol del ingeniero en proyectos acelerados
El caso de Sora muestra que las tareas repetitivas y rutinarias se automatizan. Los ingenieros se enfocan en arquitectura, calidad y experiencia.
Al actuar como directores de orquesta, gestionaron múltiples hilos de trabajo simultáneos. La revisión y la toma de decisiones se volvieron el cuello de botella.
Figuras como Sundar Pichai ya han defendido este enfoque. Empresas tecnológicas lo ven como una forma de escalar productos sin inflar equipos.
Lo que funcionó
- Equipo pequeño para reducir fricción y coordinación.
- IA especializada para tareas técnicas repetitivas.
- Documentación y procesos claros que orientaron a los agentes.
Riesgos a considerar
- Dependencia de modelos y consumo elevado de tokens.
- Necesidad de supervisión humana para decisiones de producto.
- Posibles brechas en la calidad del código a largo plazo.
