A odisseia da palestrante virtual

Este post é o segundo de uma série de três. Você pode ler a primeira parte aqui. Nesta segunda parte eu conto um pouco sobre o processo de condução do projeto.

Introdução

Dia 20 de julho de 2026, segunda-feira. Como de costume, abri a minha agenda para verificar os compromissos da semana. E lá estava uma sessão de Mob Programming alocada para a sexta-feira da mesma semana. Àquela altura não fazia a menor ideia qual seria o tema do Mob.

Na sexta-feira, quase todos os membros do time se reuniram. Alguns remotamente e outros presencialmente. Eu estava no escritório. A sessão iniciou com o Palladino explicando o que seria desenvolvido a partir daquela sessão de Mob Programming: uma palestrante virtual para se apresentar no Seniortec que aconteceria em dois meses!

A ideia foi proposta pelo CTO da Senior, organizadora do Seniortec, e chegou até o Diego, CEO da Dati. O Diego topou o desafio e confiou a execução ao time do Dati Labs. Uma vez que o desafio foi aceito, seguiram-se então duas reuniões coordenadas pelo Palladino junto ao cliente. A primeira para alinhamento de expectativas e a segunda para definir a entidade da palestrante virtual. Ambas as reuniões foram transcritas automaticamente com auxílio de ferramentas de inteligência artificial e tornaram-se artefatos do projeto. Aliás, os arquivos com as transcrições estão no repositório da aplicação até hoje, bem como as mensagens trocadas entre o Diego e o Leonardo, CTO da Senior.

Desenvolvimento dirigido por especificações

Em termos de negócio nós sabíamos exatamente o resultado que desejávamos alcançar. Mas ainda não sabíamos como. Também haviam muitos detalhes e surpresas que estavam nas entrelinhas do projeto e que não era possível enxergar naquele momento. Tudo que tínhamos à disposição eram as transcrições das primeiras reuniões.

Iniciamos a sessão de Mob Programming definindo a ordem de pilotagem. Para isso, usamos o Claude Code para sortear a ordem de revezamento dos pilotos. Curiosamente, o Claude Code gerou uma lista ordenada alfabeticamente. Não houveram contestações. Cada piloto ficaria 30 minutos no controle antes de passar o bastão para o próximo. Todo o processo foi apoiado em um conjunto de agent skills que usamos com auxílio do Claude Code. O primeiro piloto começou acionando uma skill que faz uma série de perguntas, um verdadeiro interrogatório, sobre o projeto. O piloto realizava a leitura da pergunta e das opções e, com a ajuda dos co-pilotos, discutiam sobre a questão para decidir em equipe a melhor alternativa. O piloto só avançava para a próxima questão quando todos da equipe alcançavam um entendimento comum sobre o tema.

Quando o tempo de controle de um piloto findava, esse piloto usava uma skill para fazer a passagem de bastão. Essa skill transcrevia para um arquivo as decisões tomadas naquela sessão até o momento. O próximo piloto assumia o controle a carregava o contexto gerado pelo piloto anterior. Esse processo se repetiu até que obtivemos um entendimento completo do projeto. Bom, pelo menos era nisso que acreditávamos naquele momento.

No final do dia, nós havíamos gerado um total de 21 arquivos de ADR (Architecture Decision Record) e um glossário com os termos que seriam usados no projeto doravante.

Uma vez que o entendimento do projeto estava concluído e a arquitetura definida, era momento de transformar todo esse conteúdo em tarefas executáveis. Criamos um card no ClickUp e dentro desse card, adicionamos tarefas e subtarefas.

Mão na massa e cabeça nas nuvens

Agora que as tarefas estavam documentadas era o momento de iniciar a implementação. Eu fui o escolhido para essa tarefa. Para tal, eu usava uma agent skill que encontrava a primeira tarefa sem bloqueio no ClickUp para então implementá-la.

Eu acionava a skill e confiava cegamente no código que o Claude Code me entregava. Paralelamente eu estava resolvendo outros problemas da minha rotina de trabalho. Eu lia por cima o resumo do agente de codificação. Mas na verdade, eu não fazia a menor ideia do que estava acontecendo. Meu foco não estava ali.

Então, numa das reuniões com o Palladino, ele me fez alguns questionamentos sobre o projeto. Esses questionamentos eram um sua maioria baseados nas premissas que ele havia lido nas mensagens dos pull requests do repositório. Eu não era capaz de responder qualquer pergunta técnica sobre o projeto. Foi constrangedor mas foi necessário. Depois de uma conversa franca, concluímos que a minha falta de entendimento do projeto estava relacionada ao fato de eu estar dividindo meu foco com outras tarefas.

Trabalhar com um agente de codificação como o Claude Code não significa que você deve simplesmente negligenciar o entendimento do projeto, especialmente no que diz respeito às decisões de arquitetura.

Depois desse episódio, passei a focar totalmente no projeto da palestrante virtual. As coisas começaram a andar e os primeiros resultados apareceram.

As primeiras telas e reuniões com o cliente

Após aproximadamente duas semanas de trabalho, já era possível ver algumas funcionalidades como o modo de criação, painel de controle, a tela de projeção, renderização do avatar e troca automática de slides.

No modo de criação, um curador, com auxílio de agentes de IA, monta a apresentação e o roteiro da palestra.

O painel de controle permite acompanhar o funcionamento da palestrante virtual ao vivo, incluindo um botão de pânico para interromper a palestrante em caso de mau funcionamento.

A projeção exibe o avatar da palestrante e os slides da apresentação. Nesta primeira versão usamos um avatar com fundo verde para aplicar chroma key sobre uma página preta.

No dia 6 de agosto aconteceu a primeira apresentação para o cliente. Foi possível visualizar a tela de projeção com o avatar e a passagem automática dos slides, mas a palestrante ainda estava muda. O cliente ficou impressionado com o que viu nessa primeira reunião. Mas estávamos cientes que poderíamos ter entregue mais.

As reuniões com o cliente seriam recorrentes. Todas as quintas-feiras. Além disso, também realizamos reuniões internas todas as sextas-feiras. Enquanto as reuniões com o cliente eram focadas em apresentar as funcionalidades dos sistema, as reuniões internas serviam para colocar todo o time na mesma página. Nesta reunião, falávamos sobre metodologias, processos e dificuldades enfrentadas. Era uma boa oportunidade para que os demais membros do time colaborassem com o projeto, apresentando sugestões, pontos de vista e compartilhando conhecimento.

Na segunda reunião com o cliente conseguimos então apresentar a palestrante funcionando do início ao fim, ou seja, a palestrante falou, fez a troca de slides e entrou no modo de perguntas e respostas. A partir desta reunião, começamos uma série de ajustes finos no sistema, como melhorias no visual dos slides, visual da aplicação, autenticação, entre outros.

O sistema em produção quebrado

Em uma das apresentações, o cliente queixou-se de que a palestrante parecia muito robótica. Até certa medida essa era uma limitação do modelo de voz e também do fornecedor do avatar, sobre os quais falarei no terceiro e último post desta série. De qualquer forma, acreditávamos que seria possível fazer a palestrante soar mais natural, mesmo com as limitações conhecidas.

Com apoio de dois colegas de equipe, iniciamos uma nova sessão de levantamento de requisitos com auxílio de agent skills. Essa sessão resultou em novos arquivos ADR que se somaram àqueles que já existiam no repositório. É importante ressaltar que durante todo o processo de desenvolvimento com auxílio do Claude Code, os documentos de ADR eram lidos pelo modelo e suas decisões eram respeitadas. Às vezes eu não entendia certas decisões tomadas pelo Claude Code, mas todas essas decisões estavam calcadas em premissas registradas em documentos ADR presentes no repositório.

Após geração dos documentos ADR, iniciei a implementação do código que daria mais naturalidade à palestrante. Àquela altura eu estava trabalhando com uma branch main. Toda nova implementação era codificada em uma feature branch e depois mesclada à branch main. Havia apenas um ambiente produtivo e uma única stack do CloudFormation em uma conta AWS. Tudo estava correndo bem até então.

Numa das reuniões de equipe, decidi apresentar o avanço do projeto até aquele momento. Mas quando tentei iniciar a palestrante, o áudio não saiu. O código que eu havia implementado para adicionar naturalidade à palestrante quebrou o que estava funcionando. Felizmente isso aconteceu numa apresentação interna.

Depois desse episódio, em reunião com o Palladino, ele expressou sua preocupação com o fato de que a implementação de um novo recurso quebrou o funcionamento daquilo que estava rodando em ambiente produtivo. De fato, eu não deveria ter realizado o deploy de um recurso não homologado em ambiente produtivo. Foi um erro.

Sim, eu sei da importância de manter dois ambientes distintos, um para homologação e outro para produção. Mas, por algum motivo, eu não tinha preparado esse ambiente. E não tenho nenhuma desculpa para tal. Eu apenas não fiz. Nós cometemos erros e o primeiro passo é reconhecer isso. Mas apenas reconhecer não é o suficiente. É necessário discutir em equipe esses erros e encontrar mecanismos para mitigar as falhas. Porém, lembre-se que não existe processo infalível. Em algum grau, tudo depende da disciplina de um ser humano. E a disciplina deve ser reforçada com treinamentos, reuniões, conversas e documentação.

Após mais esse deslize, fiz os ajustes necessários no ambiente e continuei a implementação das funcionalidades, correções de erros e rotina de apresentações. Agora, tudo parecia estar nos trilhos.

Reconhecendo os limites

O que mais me tomou tempo neste projeto foi a implementação da naturalidade da palestrante virtual. Como comentei anteriormente, o cliente notou nas primeiras apresentações que a palestrante soou muito robótica.

Tentar fazer a palestrante parecer mais natural e fluída foi um tremendo desafio. E preciso confessar que não consegui alcançar o ideal, segundo os meus próprios conceitos. Talvez meu erro tenha sido comparar com tecnologias mais avançadas àquilo que eu poderia fazer com as ferramentas e recursos que eu tinha à minha disposição.

Qualquer um que assistisse a palestra notaria que a palestrante não é uma pessoa real. Isso até mesmo foi anunciado no palco no dia do evento! O objetivo principal não era tentar surpreender as pessoas com uma fala natural. Mas sim mostrar que uma palestrante dotada de inteligência artificial é capaz de preparar e fazer uma apresentação em um grande palco, além de responder perguntas. Era algo pioneiro e experimental.

Sim, foi o cliente que pediu para adicionar mais naturalidade à palestrante virtual. Mas é necessário reconhecer os limites, expor isso para o cliente e saber negociar.

Mesmo assim, eu insisti. Passei vários dias testando diferentes abordagens para fazer a fala da palestrante soar mais natural. Mas cada vez que eu tentava uma nova abordagem, nenhuma ou quase nenhuma diferença eu notava em relação à versão anterior.

O meu erro foi insistir em algo que não ficaria melhor. E isso me tomou um precioso tempo que poderia ser usado na preparação da minha própria apresentação. A semana que antecedeu a semana da apresentação foi atribulada. Montei um esboço da apresentação em slides, o roteiro e fiz uma apresentação interna.

É verdade que no final deu tudo certo, mas tudo poderia ter sido bem mais tranquilo.

Se você está preso em uma tarefa ou problema, não insista! Primeiro respire e depois busque ajuda. Às vezes a melhor saída é reconhecer os limites e desistir. Primeiro, foque na entrega de valor e depois na excelência. A sua saúde mental agradece!

O resumo do processo

Desde o primeiro contato do cliente com a Dati até a apresentação no Seniortec foram exatamente 71 dias. Nós conhecemos a ideia no dia 14 de julho, iniciamos o desenvolvimento em 27 de julho e apresentamos no palco em 23 de setembro.

Abaixo eu apresento alguns números do projeto:

• 427 commits
• 117 pull requests integrados
• 62 documentos de ADR
• 3144 testes no backend
• 408 testes no frontend
• 33 cards do ClickUp entregues
• 30 cards do ClickUp cancelados

Todo o processo de desenvolvimento foi conduzido com auxílio do Claude Code. No começo eu usava o modelo Fable 5.1 com esforço no ultracode de forma indiscriminada em todas as tarefas. Mas meus tokens eram consumidos muito rapidamente, então mudei a estratégia. Passei a usar o Fable com esforço max para clarificação de entendimento e geração dos documentos de ADR. Para implementação, o modelo escolhido foi a última versão disponível do Opus com esforço no ultracode.

Durante os 71 dias, meu tempo não foi alocado exclusivamente para este projeto. As duas primeiras horas da minha segunda-feira são sempre dedicadas à auto desenvolvimento. Também haviam algumas reuniões semanais recorrentes, além de agendas esporádicas com clientes para tratar de outros temas. Eventualmente dediquei parte do meu tempo para atividades de outros projetos. E a semana que precedeu a semana do Seniortec foi quase toda dedicada à preparação da minha apresentação.

Houveram também algumas mudanças de rota durante o desenvolvimento do projeto. Por exemplo, na primeira versão da palestrante nós aplicamos chroma key sobre o avatar. Mas essa ideia foi descartada, pois entendemos junto com o cliente que exibir o ambiente do avatar adicionaria mais naturalidade.

Também tentamos criar o nosso próprio avatar customizado usando a imagem de uma colega de trabalho. Mas todas as nossas tentativas foram frustradas. Por fim, escolhemos um modelo de avatar que já estava disponível no catálogo do fornecedor.

A princípio, a minha própria apresentação no Seniortec não estava prevista. O desejo inicial do cliente era que a palestrante virtual se apresentasse por 20 minutos. Mas, depois dos primeiros testes, o cliente entendeu que ouvir um robô falando por 20 minutos poderia ser entediante e que o público não conseguiria manter o foco na apresentação.

Projetos são assim. Eles nunca terminam como idealizamos no começo. Podemos observar isso pela quantidade de documentos de ADR que foram adicionados após a sessão de Mob Programming. O projeto nasceu com 21 ADRs e terminou com 62. Novos documentos de ADR eram adicionados à medida que novas situações surgiam no projeto.

O código fonte de um software é um organismo vivo que está em constante evolução. Ao escrever um código, a mensagem de um commit ou um pull request, lembre-se que outra pessoa o lerá. Lembre-se também que você mesmo precisará reler o que fez em algum momento. A forma como você encara o processo de desenvolvimento de um software também diz muito sobre você.

Lições aprendidas

Ao refletir sobre tudo que aconteceu, eu consigo entender que os erros cometidos durante a condução do projeto têm explicação. Na verdade, tudo tem uma explicação, uma razão de ser. Eu não quero ser filosófico. Apenas quero trazer algumas de minhas percepções que acredito que explicam em partes os meus erros.

Em primeiro lugar, eu queria entregar rápido. Ou melhor, eu achava que deveria entregar rápido por pressão externa criada na minha própria mente. Eu tinha à minha disposição o Claude Code na sua versão mais avançada. Portanto, eu pensava que deveria entregar o projeto o mais rápido possível. E assim, comecei a negligenciar boas práticas no processo de desenvolvimento.

Além disso, na maior parte do tempo eu estava trabalhando sozinho no projeto e por isso abri mão de práticas de desenvolvimento colaborativas. Se algum imprevisto ocorresse e eu não pudesse continuar trabalhando no projeto, algum colega meu teria muita dificuldade de continuar do ponto em que parei.

Lembre-se, mesmo quando você está trabalhando sozinho num projeto você ainda faz parte de um time. É necessário senso de coletivo, isto é, pensar no bem maior. Isso envolve muitas vezes abrir mão de suas preferências pessoais. Nem tudo que é bom pra você é bom pra todo mundo.

Neste projeto eu também percebi os princípios do Manifesto Ágil aplicados na prática:

• Indivíduos e interações mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano

Eu ainda não acabei. Você deve estar super curioso para saber mais sobre a parte técnica do projeto. Esse será assunto para o terceiro e último post desta série. Nele, vamos falar sobre a arquitetura do projeto e o fluxo de funcionamento da palestrante virtual. Até breve!