Reuniões gravadas são um ativo de conhecimento pouco aproveitado. É difícil pesquisá-las, revê-las leva tempo e elas ficam isoladas nos drives das equipes, fazendo com que insights valiosos muitas vezes passem despercebidos.
Em um hackathon de um dia, uma equipe de três pessoas criou o Callombia. Trata-se de uma plataforma interna que transcreve, classifica, resume e recorta automaticamente chamadas gravadas, reunindo-as em um repositório pesquisável, no estilo do YouTube, acessível a todos os escritórios no mundo.
A solução, criada inteiramente com o Codex, usa busca semântica baseada em embeddings da OpenAI e similaridade de cosseno para encontrar momentos relevantes mesmo sem o uso de palavras-chave exatas, além de contar com um chatbot RAG e um sistema de notificações.
O que antes levaria semanas foi entregue em sete horas, mostrando como o desenvolvimento nativo em IA com agentes de programação como o Codex pode reduzir drasticamente o ciclo de desenvolvimento de produtos e gerar valor real para o negócio em hackathons internos.
Se você é como eu, raramente tem tempo (ou capacidade de concentração) para ouvir novamente reuniões gravadas. Isso geralmente acontece porque é preciso vasculhar drives desorganizados das equipes, pular conversas triviais pouco interessantes e tentar ouvir de verdade enquanto se responde a e-mails e mensagens.
Mas talvez não precise ser assim. E se criássemos algo que transformasse completamente as reuniões gravadas? Essa foi a ideia por trás do nosso projeto recente de hackathon.
Em apenas um dia, 50 integrantes das nossas equipes de engenharia, entrega e operações enfrentaram diversos desafios identificados em toda a empresa, como escalar as operações de contratação, agilizar a criação de SoWs, entender a saúde dos projetos, gerar protótipos ao vivo e extrair insights de reuniões gravadas.
Nesse hackathon baseado no Codex, criamos o Callombia. O Callombia é o YouTube da nossa empresa: transforma cada chamada em um ativo vivo e pesquisável. Cada chamada é automaticamente transcrita, classificada e resumida antes de ser dividida em clipes temáticos e adicionada a um repositório organizado por canal (clientes) e tópicos (áreas de especialização em IA). Assim, qualquer integrante das equipes de Londres, Edimburgo, Singapura e Austrália pode acessar instantaneamente os momentos das chamadas que lhe interessam.
Uma interface familiar e alinhada à marca torna intuitiva a descoberta de conteúdo, enquanto a busca semântica — e, é claro, um chatbot de IA com RAG — ajuda as pessoas a encontrar exatamente o que procuram. A inclusão de um sistema de notificações também permite que nossos colegas acompanhem determinados tópicos e sejam avisados quando novos clipes relevantes forem publicados.
Mas o mais legal no Callombia não é o produto nem o prêmio de £2 mil por vencer o hackathon — só para ostentar —, e sim o fato de termos criado tudo isso em apenas sete horas, com dois engenheiros e um líder de entrega. Isso não era possível há um ano. Os avanços dos agentes de programação aceleraram enormemente todo o processo de desenvolvimento de produtos, e este hackathon foi um excelente campo de testes para entendermos seus limites irregulares. Então, como usamos o Codex?
Em vez de simplesmente escrever uma longa lista de requisitos, começamos compartilhando nossa visão coletiva — na forma de um prompt — sobre o problema e a visão para o Callombia. Ao sermos intencionalmente pouco específicos, deixamos o modelo trabalhar e pensar de forma criativa:
Após dez minutos de conversa, ativamos o Modo de Planejamento para refinar os requisitos e orientar a parte técnica do desenvolvimento. O Modo de Planejamento é como responder às perguntas daquele amigo irritante que, para nossa sorte, já pensou em todos os cenários possíveis. Depois de definirmos aspectos como a quantidade de vídeos, o uso de busca semântica ou por palavras-chave e a arquitetura, ele criou um arquivo Markdown que passou a servir de base para o projeto.
Com o plano pronto, a etapa seguinte foi desenvolver os principais componentes que fariam o Callombia funcionar de verdade. Isso significava criar um pipeline que transformasse chamadas gravadas em ativos pesquisáveis:
Ingerir vídeos e transcrições;
Dividi-los em momentos relevantes;
Enriquecê-los com resumos e tags;
Disponibilizá-los por meio de APIs que pudessem ser consumidas pelo frontend.
Ed se concentrou mais em transformar as gravações brutas e os dados das transcrições em um formato utilizável, enquanto Nico cuidou principalmente da camada de recuperação que permitiria encontrar esses momentos. Com o Codex, os dois conseguiram estruturar os modelos de dados, scripts de extração e toda a infraestrutura do backend muito mais rápido do que seria possível manualmente. Com isso, obtivemos muito mais do que uma transcrição anexada a um vídeo. Obtivemos momentos: o trecho sobre a Tesco, a atualização de estratégia, a discussão sobre contratações, aqueles 90 segundos específicos de uma chamada que alguém realmente quer assistir.
Foi nessa camada de recuperação que as coisas ficaram especialmente interessantes. Queríamos que alguém pudesse digitar algo como "desempenho financeiro", "roadmap da Tesco" ou "avaliações de conversas" e fosse levado aos clipes mais relevantes, mesmo que essas palavras exatas nunca tivessem sido ditas. Para isso, criamos trechos com marcações de tempo, resumos, texto da transcrição e metadados. Com uma arquitetura clara em mente e muita ajuda do Codex, combinamos tópico, resumo e transcrição em uma única entrada e usamos o modelo text-embedding-3-small da OpenAI para gerar embeddings de cada trecho. Armazenamos esses embeddings em nosso banco de dados e usamos a similaridade de cosseno para comparar a consulta do usuário com cada trecho, criando uma camada de recuperação semântica em vez de uma simples busca por palavras-chave.
Isso funcionou extremamente bem em termos de precisão e deu ao produto uma sensação de "mágica" durante a demonstração no hackathon. Ao mesmo tempo, sabíamos que essa abordagem não seria escalável para sempre caso a quantidade de vídeos continuasse crescendo, pois comparar cada consulta com todos os trechos acabaria ficando caro demais. O próximo passo natural seria adotar estratégias de recuperação mais eficientes, como Hierarchical Navigable Small World, para reduzir o número de comparações e manter baixa a latência à medida que o corpus aumentasse. Quando esse recurso começou a funcionar, o Callombia passou a parecer menos uma biblioteca de mídia e mais um sistema de conhecimento.
Como em todo bom hackathon, essa parte também precisou de ajustes: os limites iniciais dos trechos eram imprecisos, algumas marcações de tempo precisavam ser refinadas, certas tags eram amplas demais e os arquivos de transcrição e gravação nem sempre se alinhavam perfeitamente. Mas foi também aí que o valor se revelou. O Codex nos permitiu refinar o sistema rapidamente, em vez de ficarmos presos à configuração e ao retrabalho. Ao final, tínhamos um backend capaz de sustentar clipes, trechos e uma busca semântica realmente útil. Foi então que o Callombia começou a parecer um produto de verdade, e não apenas uma demonstração de hackathon.
Enquanto Ed e Nico desenvolviam a ingestão e a camada de inteligência, eu cuidava do frontend. Usando nosso template full stack, consegui colocar rapidamente no ar uma primeira versão do site sem escrever uma única linha de código. Depois de pedir que ele abrisse o site localmente no meu navegador, eu fornecia feedback simples em tópicos para ajustar o design até chegar ao que buscava.
Após cerca de uma hora de idas e vindas, cheguei a algo que me deixou bastante satisfeito — tudo isso sem qualquer experiência em interface ou design. Embora o produto final definitivamente não seja perfeito, é uma primeira versão muito boa que permite às pessoas entender o produto.
Para garantir que teríamos algo pronto ao fim do dia, dividimos o trabalho entre nós. É claro que, após algumas horas trabalhando de forma semindependente, todos tínhamos nossas próprias ramificações locais, com uma infinidade de conflitos.
Em vez de gastar o tempo que não tínhamos revisando e resolvendo cuidadosamente os conflitos, decidimos soltar o Codex nos repositórios e deixá-lo corrigir tudo sozinho. Embora ainda não recomendemos isso para o desenvolvimento de software padrão empresarial, foi incrível ver a eficácia em um ambiente de baixo risco — e isso nos poupou muitas horas.
A etapa final do hackathon foi gravar a demonstração do Callombia para os jurados. Nosso primeiro impulso foi abrir o Loom para fazer a gravação, mas pensamos que esse seria um verdadeiro teste para o Codex e algo um pouco além de suas capacidades atuais. Então... Escrevemos um prompt, fornecemos um link para o site do Callombia, anexamos uma gravação da minha voz na plataforma para desenvolvedores da OpenAI e pedimos que ele fizesse o restante.
A primeira tentativa foi impressionante: ele escreveu um roteiro para a demonstração, gravou a tela, adicionou minha narração e cumpriu praticamente tudo o que pedimos. A única coisa que não nos agradou de imediato foi a sincronização da narração com a gravação da demonstração. Por isso, pedimos: "MANDATORY: align the voiceover exactly with what is being shown in the demo. There was misalignment (e.g. on the chat page). Triple check alignment of voiceover and the screen-recorded demo at the end. Match it up through whichever means possible."
Em resposta, o Codex dividiu a narração e a gravação em trechos menores e executou a tarefa praticamente sem falhas, bem a tempo das 17h30 e da cerveja com pizza para comemorar.
Sabemos que o Callombia resolve um problema enfrentado pela maioria das empresas. É difícil participar de todas as chamadas de uma empresa em rápida expansão, mas os conhecimentos valiosos compartilhados nelas são inestimáveis. Agora só precisamos colocá-lo em produção.
Mas há aqui uma lição maior sobre ser nativo em IA e sobre os benefícios de aplicar o conhecimento de engenharia e produto à resolução de problemas comuns. Ao sairmos do nosso ciclo habitual de trabalho e colaborarmos entre equipes em um ambiente semicompetitivo, chegamos a várias soluções que, com alguns ajustes, poderiam entrar em produção. Fazendo isso regularmente, podemos garantir que nossos processos internos sejam tão eficientes quanto as soluções que criamos para os clientes.