Codex es el agente de programación de OpenAI que lee un repositorio de código, edita varios archivos a la vez y ejecuta comandos y pruebas. En el caso de Holiday Extras, una empresa británica de viajes con 44 años de operación, ese agente permitió reconstruir la aplicación principal en 2 semanas, un trabajo que en su versión anterior había tomado más de un año. La compañía reportó además un aumento de 32,5% en la conversión de apertura a reserva y una caída de la tasa de error de la app de 19% a 9%, aunque la propia empresa aclara que la comparación se hizo entre periodos distintos y no en un test controlado.
Lo llamativo del caso no es la velocidad en sí, sino quién construye. Según el video de OpenAI sobre Holiday Extras, todos en la empresa tienen acceso a la herramienta, desde el CEO hasta el personal de call center. La lógica es simple: quien está más cerca del cliente es quien mejor entiende el problema, y ahora también puede construir la solución.
Esto conecta con una discusión que veo cada vez más seguido en empresas peruanas: no es que falten ideas, es que faltan manos para convertirlas en software. Veamos qué hay detrás del caso, qué se puede replicar y qué conviene mirar con cautela.
¿Qué cambió realmente en Holiday Extras con Codex?
El cambio más visible está en la cadencia de entrega. Antes, la aplicación principal tenía un release grande por año. En las dos primeras semanas después de la reconstrucción, el equipo hizo 8 releases, cada uno con al menos 3 funcionalidades nuevas. La propia empresa lo describe en el video: "en las dos primeras semanas de nuestra nueva app en vivo, hicimos ocho releases".
Ese ritmo cambia el ciclo de retroalimentación. Cuando una mejora tarda meses en llegar al usuario, cada decisión de producto se vuelve una apuesta costosa que nadie quiere arriesgar. Cuando tarda días, se puede probar, medir y corregir. En un caso citado por OpenAI, un cliente de Countdown se quejó de que faltaba una vista de lista; un agente preparó el ajuste, el VP de AI Innovation lo aprobó, se envió la actualización y el cliente cambió su reseña de una estrella a cinco.
El segundo cambio es la división del trabajo. Los ingenieros no desaparecen: se quedan con la arquitectura, las APIs, la seguridad y los flujos de desarrollo. Los paquetes pequeños y documentados funcionan como base reutilizable. Y como el agente trabaja sobre el mismo código, las funcionalidades de iOS y Android avanzan en paralelo, en lugar de que Android vaya siempre detrás.
Aquí conviene una precisión: los números de conversión y de errores comparan la app anterior y la reconstruida en periodos diferentes, según aclara el propio caso. No es un experimento con grupo de control, así que sirven como señal, no como prueba.
¿Puede alguien que no es ingeniero construir software útil?
El caso más citado es el de un integrante del equipo de finanzas que fue contador durante décadas. En roles contables normalmente no hay mucho espacio para la creatividad, pero cuando entendió que podía construir, reconstruyó sistemas financieros internos que le costaban a la empresa "una cantidad ridícula de dinero" y los dejó mejor de como estaban.
Lo interesante de este enfoque es que no se trata de enseñarle a programar a un contador. Se trata de que ese contador ya sabe exactamente cómo debe funcionar el cierre contable, qué validaciones importan y dónde se pierde tiempo. Ese conocimiento operativo es el activo escaso; el código es cada vez más la parte barata.
Para que esto no termine en un desastre, Holiday Extras construyó su propia plataforma de despliegue interna, un lugar seguro donde cualquier persona puede publicar lo que armó. Los ingenieros mantienen los controles de seguridad y los flujos, y siguen en el circuito antes de que algo llegue a producción. Es decir, la apertura viene con rieles.
Mi lectura de este punto es que el modelo replicable no es "suelta a todos a programar". Es "quien conoce al cliente construye, ingeniería pone los guardarraíles". Sin esa segunda mitad, la primera se convierte en deuda técnica acumulada.
Lo que el caso no demuestra es si este modelo se sostiene cuando los no ingenieros pasan de prototipos a sistemas críticos de largo plazo. El propio análisis de StartupHub plantea esa duda abierta: queda por ver si la plataforma interna aguanta cuando el volumen y la complejidad crecen. Tampoco hay datos públicos sobre cuánto costó montar esa infraestructura ni cuántas horas de ingeniería se consumieron en revisar lo que otros construyeron.
¿Qué significa esto para una empresa en Perú o Latinoamérica?
La mayoría de las empresas medianas en Perú no tienen un equipo de producto de cientos de personas. Tienen un jefe de TI con tres o cuatro desarrolladores y una lista de pedidos que crece más rápido de lo que se puede atender. En ese contexto, la pregunta relevante no es si conviene adoptar agentes de IA, sino dónde ponerlos primero.
El caso sugiere tres condiciones que sí se pueden replicar sin ser una empresa de viajes británica. Primero, acceso amplio: que las personas de negocio puedan experimentar, no solo mirar. Segundo, un entorno controlado donde probar sin tocar producción. Tercero, ingeniería como revisora, no como cuello de botella.
En proyectos de desarrollo de software que he visto en la región, el patrón se repite: el área de negocio pide, TI prioriza, y entre esos dos mundos se pierden meses. La inteligencia artificial para empresas no elimina esa brecha por sí sola, pero sí puede acortarla si quien pide también puede prototipar.
Hay un matiz local importante. En una PYME peruana, el área de finanzas suele tener el conocimiento más profundo de los procesos internos, y también la mayor carga operativa. Darle a esa persona una herramienta para automatizar sus propias tareas puede rendir más que cualquier proyecto grande de transformación, simplemente porque el retorno se ve en el mismo mes.
Y hay un efecto menos obvio: cuando la cadencia de entrega sube, la conversación cambia de "¿podemos hacerlo?" a "¿cómo lo haríamos?". Ese cambio de pregunta es, probablemente, el activo más valioso del caso.
¿Cómo aplica esto en tu empresa?
Si quieres probar este enfoque sin apostar toda la operación, empieza por algo acotado y medible:
- Elige un proceso interno, no un producto. Un reporte que alguien arma a mano cada semana, una validación que se hace en Excel, un flujo de aprobación con pasos de más. El retorno debe ser visible en semanas, no en trimestres.
- Identifica a la persona que ya conoce ese proceso de memoria. No busques al más técnico del equipo, busca al que sabe dónde están los errores y por qué existen.
- Define un entorno de prueba separado de producción. Sin esto, cualquier experimento se vuelve un riesgo que nadie quiere autorizar.
- Mantén a ingeniería en la revisión final. El valor no está en que todos programen, sino en que todos propongan y alguien calificado valide.
- Mide la cadencia, no solo el resultado. Si antes entregabas una mejora al mes y ahora entregas una por semana, ese es el indicador que predice el resto.
Si quieres revisar qué procesos de tu empresa son buenos candidatos para este tipo de automatización, puedes conversar con nosotros sobre tu caso. También puedes revisar cómo funcionan nuestros flujos de automatización en ContentFlow.
Preguntas Frecuentes
¿Qué es Codex y en qué se diferencia de un asistente de código normal?
Codex es un agente de programación: no solo sugiere líneas de código, sino que lee el repositorio completo, edita varios archivos a la vez y ejecuta comandos y pruebas para verificar su propio trabajo. Esa capacidad de operar sobre el proyecto entero, y no sobre un fragmento, es lo que permite que alguien sin formación de ingeniero llegue a un prototipo funcional.
¿Cuánto tiempo tomó reconstruir la app de Holiday Extras con Codex?
Según el caso publicado por OpenAI, la versión anterior de la aplicación tomó más de un año de diseño, pruebas y desarrollo con ingenieros. La nueva versión se armó como prototipo en 2 días y llegó a producción en 2 semanas con apoyo del equipo de ingeniería. Es la quinta reconstrucción de la app en la historia de la empresa.
¿Los resultados de conversión del caso son confiables?
Deben leerse con cautela. El aumento de 32,5% en la conversión de apertura a reserva y la caída de la tasa de error de 19% a 9% comparan la app anterior y la reconstruida en periodos diferentes, no en un test controlado, y la fuente es un caso publicado por el propio proveedor. Sirven como señal de dirección, no como garantía de resultados replicables.
Conclusión: ¿vale la pena que tu equipo de negocio construya software?
El caso de Holiday Extras no dice que los ingenieros sobren. Dice que el cuello de botella se movió: pasó de la capacidad de escribir código a la claridad de lo que se quiere resolver. Cuando quien conoce el problema puede prototipar la solución, la lista de espera de TI deja de ser el límite del negocio.
La parte replicable no requiere ser una empresa de 44 años con presupuesto de innovación. Requiere elegir un proceso acotado, dar acceso a la persona correcta, montar un entorno de prueba y dejar que ingeniería valide. El resto es cadencia.
Si quieres identificar por dónde empezar en tu operación, conversemos sobre tu caso o revisa los recursos del blog de Consultoría TI.
Por Edgar Vásquez, Consultoría TI · actualizado el jueves, 12 de noviembre de 2026
Fuentes y Referencias
- OpenAI — What Codex Unlocks for Holiday Extras (YouTube)
- openai.com — Holiday Extras is rethinking what it can build with Codex
- startuphub.ai — Holiday Extras lets everyone build with Codex
- ceviu.com.br — Holiday Extras reconstruye su app con Codex
✨ Contenido generado con ContentFlow — Consultoría-Ti