Cult.fit move o desenvolvimento para o Codex: rede social em 2 meses em vez de um ano

Um cenário familiar: uma equipe usa um assistente, outra usa outro, e cada uma tem suas próprias regras para repositórios e seus próprios prompts. O conhecimento não se transfere e as revisões são diferentes em cada lugar. A Cult.fit, uma das maiores empresas de fitness da Índia (708 centros em 77 cidades, quase um milhão de membros pagantes), resolveu esse problema de forma radical: escolheu o Codex como plataforma única.

É importante ressalvar de início: trata-se de um estudo de caso no site da OpenAI, os números são apresentados pela própria empresa e ninguém os verificou de forma independente. Ainda assim, o conjunto de práticas descrito é bastante concreto e útil.

Uma ferramenta em vez de um zoológico

Antes da padronização, os desenvolvedores usavam uma mistura de agentes e assistentes. Por isso, cada equipe tinha suas próprias convenções: estrutura de repositórios, instruções para agentes, habilidades, processos. Agora tudo é comum: estrutura, habilidades (skills), testes, revisão de código e ciclos de feedback.

Sobre essa base foram construídos agentes especializados. O agente SRE coleta dados de sistemas de observabilidade e de logs, investiga o incidente e, em muitos casos, cria sozinho um pull request com a correção proposta, que um engenheiro então revisa. Há agentes de segurança que procuram vulnerabilidades e agentes de plantão para problemas recorrentes em produção.

A empresa também caminha para o desenvolvimento orientado por especificações (spec-driven): a especificação conduz a tarefa por todo o ciclo de vida até um PR que uma pessoa revisa. Exemplo: o feed social do aplicativo. O CTO Santosh Kumar estima que antes levaria mais de um ano; a equipe o lançou em dois meses. Essa é a estimativa dele, não uma medição.

Desenvolvimento para não engenheiros

O segundo passo é mais interessante. A empresa tornou seus dados acessíveis para o Codex, e as equipes passaram a responder sozinhas às perguntas rotineiras, sem entrar na fila dos analistas centrais. O RH montou um workflow para avaliações de desempenho: agendamento, coleta de feedback e consolidação de resultados. Nos últimos meses, não engenheiros criaram mais de 20 aplicativos internos.

Os dashboards são uma história à parte: quando um serviço interno ficou muito mais caro, um engenheiro reproduziu a funcionalidade necessária no Codex em um fim de semana. Hoje ela roda em um aplicativo próprio, com economia de mais de US$ 100 mil por ano.

Observe como isso foi implantado. Não se limitaram a liberar o acesso. Houve um grande hackathon, depois uma sessão de um dia para executivos seniores, em que cada um construiu algo para sua área. Duas vezes por semana há office hours, e engenheiros foram alocados em departamentos específicos para dar suporte técnico e de domínio.

IA no produto e no suporte

Por meio da API da OpenAI, a empresa desenvolve o AI Trainer, usado por cerca de 20% dos frequentadores das academias. A nova versão é por voz: com o GPT Realtime, o treinador dá dicas durante os exercícios e ajuda a manter o registro de treinos. Considerando que mais de 45% dos membros foram a uma academia pela primeira vez, apostar no acompanhamento faz sentido.

No suporte, os agentes resolvem tarefas que antes exigiam uma pessoa. Exemplo: um membro pede o cancelamento da multa por faltar a uma aula. O agente verifica sinais como o clima na cidade e a frequência naquela aula específica e toma a decisão. Os agentes foram integrados à plataforma existente Sprinklr e conectados ao backend. Segundo a empresa, os custos de suporte caíram mais de 50%.

O que aproveitar

Primeiro: padronizar importa mais do que escolher a melhor ferramenta. Convenções comuns permitem reutilizar habilidades e tornam a revisão previsível. Segundo: se a conta do seu SaaS interno está crescendo, verifique se não é mais simples recriá-lo por conta própria, mas considere o custo de manutenção, que o artigo não menciona. Terceiro: o treinamento e os engenheiros alocados nas áreas, pelo visto, importaram tanto quanto o próprio modelo.

As limitações são óbvias. Não há dados sobre a qualidade e a segurança dos aplicativos criados por não engenheiros, sobre a robustez das decisões do agente quanto às multas nem sobre quanto custa manter esses sistemas caseiros. Trata-se de material de marketing de um fornecedor, então os números devem ser vistos como referência, não como garantia.