Cult.fit traslada su desarrollo a Codex: red social en 2 meses en lugar de un año

Una escena conocida: un equipo usa un asistente, otro usa otro, y cada uno tiene sus propias reglas para repositorios y sus propios prompts. El conocimiento no se transfiere y las revisiones son distintas en cada lugar. Cult.fit, una de las mayores compañías de fitness de la India (708 centros en 77 ciudades, casi un millón de socios de pago), resolvió este problema de forma radical: eligió Codex como plataforma única.

Conviene advertir de entrada: se trata de un caso de estudio publicado en el sitio de OpenAI, las cifras las aporta la propia compañía y nadie las ha verificado de forma independiente. Aun así, el conjunto de prácticas que describe es muy concreto y útil.

Una sola herramienta en lugar de un zoo

Antes de la estandarización, los desarrolladores usaban una mezcla de agentes y asistentes. Por eso cada equipo tenía sus propias convenciones: estructura de repositorios, instrucciones para agentes, habilidades, procesos. Ahora todo es común: estructura, habilidades (skills), pruebas, revisión de código y bucles de retroalimentación.

Sobre esa base se construyeron agentes especializados. El agente SRE recopila datos de los sistemas de observabilidad y de los logs, investiga un incidente y, en muchos casos, crea por sí solo un pull request con una corrección propuesta, que luego revisa un ingeniero. Hay agentes de seguridad que buscan vulnerabilidades y agentes de guardia para problemas recurrentes en producción.

La compañía avanza también hacia el desarrollo guiado por especificaciones (spec-driven): la especificación lleva la tarea por todo el ciclo de vida hasta un PR que revisa una persona. Ejemplo: el feed social de la aplicación. El CTO Santosh Kumar estima que antes habría requerido más de un año; el equipo lo lanzó en dos meses. Es su estimación, no una medición.

Desarrollo para no ingenieros

El segundo paso es más interesante. La compañía hizo que sus datos fueran cómodos para Codex, y los equipos empezaron a responder por sí mismos a las preguntas rutinarias sin hacer cola ante los analistas centrales. RR. HH. montó un flujo de trabajo para las evaluaciones de desempeño: calendario, recopilación de feedback y consolidación de resultados. En los últimos meses, perfiles no ingenieros han creado más de 20 aplicaciones internas.

Los paneles son una historia aparte: cuando un servicio interno se encareció bruscamente, un ingeniero reprodujo en un fin de semana la funcionalidad necesaria con Codex. Ahora funciona como aplicación propia y ahorra más de 100 000 dólares al año.

Fíjese en cómo se implantó. No se limitaron a dar acceso. Hubo un gran hackatón, luego una sesión de un día para altos directivos, donde cada uno construyó algo para su área. Dos veces por semana hay horas de consulta (office hours), y se integró a ingenieros en distintos departamentos para dar apoyo técnico y de dominio.

IA en el producto y en el soporte

A través de la API de OpenAI, la compañía desarrolla AI Trainer, que usa cerca del 20 % de los visitantes de los gimnasios. La nueva versión es de voz: con GPT Realtime, el entrenador da indicaciones durante los ejercicios y ayuda a llevar el registro de entrenamientos. Dado que más de un 45 % de los socios acudió por primera vez a un gimnasio, apostar por el acompañamiento tiene sentido.

En soporte, los agentes resuelven tareas que antes requerían a una persona. Ejemplo: un socio pide que se le anule la penalización por faltar a una clase. El agente comprueba señales como el tiempo en la ciudad y la asistencia a esa clase concreta, y toma la decisión. Los agentes se integraron en la plataforma existente Sprinklr y se conectaron al backend. Según la compañía, los costes de soporte cayeron más de un 50 %.

Qué conviene llevarse

Primero: la estandarización importa más que elegir la mejor herramienta. Las convenciones comunes permiten reutilizar habilidades y hacen la revisión predecible. Segundo: si crece la factura de su SaaS interno, compruebe si no es más sencillo reconstruirlo usted mismo, pero tenga en cuenta el coste de mantenimiento, que el artículo no menciona. Tercero: la formación y los ingenieros integrados, al parecer, importaron tanto como el propio modelo.

Las limitaciones son evidentes. No hay datos sobre la calidad y la seguridad de las aplicaciones creadas por no ingenieros, sobre la solidez de las decisiones del agente en materia de penalizaciones ni sobre cuánto cuesta mantener estos sistemas caseros. Es material de marketing de un proveedor, así que las cifras deben tomarse como orientación, no como garantía.