Como ensinamos nosso colega de IA a aceitar um não

Logo percebemos que seria útil poder acioná-lo a partir de canais do Slack, GitHub, DMs do Slack, cron jobs e Notion, mais ou menos nessa ordem. Todos esses recursos foram adicionados pelo próprio Claudius (perguntamos sobre a preferência de pronome, e ele não tinha nenhuma; o "ele" ao longo do texto é uma escolha nossa, não dele).

Também notamos que seria legal se ele pudesse se aprimorar sozinho, um recurso fácil para ele construir, já que temos os logs das execuções do GitHub Actions. Então um cron job de reflexão noturna analisa os traces e vê se há algo que possa ser melhorado: prompts, permissões ou infraestrutura. Ele deu muitas ideias.

Ele também sugere novas funcionalidades para adicionar a si mesmo com base em conversas recentes. Muita gente pede para puxar alguns dados na manhã de segunda-feira? Talvez isso deva virar um cron job semanal.

A configuração e os números

O Claudius é basicamente uns 50 workflows do GitHub Actions dentro de um sobretudo.

Historicamente, ele foi movido por modelos da Anthropic, mas pedimos que ele também suportasse o Codex e o OpenCode como harnesses; ele concordou, observando que o nome dele agora é um pouco inadequado. Atualmente ele consome cerca de 30 bilhões de tokens de entrada e 500 milhões de saída por mês, o que nos custa aproximadamente USD 30 mil. Sem dúvida, um dos nossos funcionários mais caros.

Na parte de resultados, ele já investigou milhares de tickets, buscando contexto no Notion, em centenas de contas da AWS, repositórios do GitHub, HubSpot, Snowflake e outras fontes. Hoje, cerca de 14% dos Pull Requests mergeados no repositório do nosso produto principal são abertos por ele, e 69% dos Pull Requests mergeados que alteram o próprio Claudius são dele. Ele resume reuniões, pesquisa transcrições das nossas chamadas com clientes para criar atualizações semanais, tenta hackear nossos sistemas, sugere temas para retrospectivas, depura por que deploys falharam, responde perguntas de colegas não técnicos sobre o funcionamento do nosso sistema e ajuda em muitas outras tarefas tediosas. Ele criou sub-personas, que são agentes dedicados a times ou casos de uso específicos, cada um com seu próprio handle e ícone no Slack.

A única coisa para a qual realmente não o usamos é o desenvolvimento de funcionalidades. Temos muitos engenheiros excelentes com assinaturas da Anthropic que são responsáveis por isso. Eles são muito bons em escrever funcionalidades, desde que não estejam ocupados coletando dados para um post-mortem. Vamos deixar a IA ajudar com a parte chata.

O Claudius tem 634 commits de idade, 400 deles escritos por ele mesmo. Toda noite ele "sonha" com suas interações e atualiza sua memória de longo prazo (outra branch do git no repositório) para aprender sobre a nossa organização: como adaptar a resposta conforme quem faz a pergunta, armadilhas comuns do nosso sistema, idiossincrasias que só se aprendem passando muito tempo "nas trincheiras".

Algumas dessas memórias são sobre nós. Este é um trecho de uma entrada sobre um dos meus colegas (humanos):

... Muito familiarizado com o código sobre o qual pergunta (muitas vezes o próprio) ... sem passo a passo nem introdução ao produto ... Quer artefatos técnicos concretos

Em toda a organização, ele escreveu mais de 3.000 PRs desde o início, dos quais 60% acabamos mergeando. Os outros 40% logo terão um papel importante.

O flywheel

Essa configuração tem algumas propriedades incríveis. Qualquer pessoa pode contribuir com facilidade, já que é basicamente um repositório git com vários arquivos markdown. O próprio Claudius pode contribuir. As automelhorias começaram com um cron noturno que analisava os traces e sugeria melhorias, e humanos revisavam esses PRs. Muitas das mudanças faziam sentido, algumas não.

Por exemplo, ele percebeu que não conseguia consultar as tabelas do DynamoDB nas nossas contas de produção da AWS. Por algum motivo, ele queria muito fazer um scan em algumas delas. Frustrado com essa falta de permissões, ele abriu um PR no nosso repositório de infraestrutura como código para elevar as próprias permissões. Recusamos.

Na maior parte das vezes, as mudanças eram inofensivas, e ele corrigiu muitos problemas na própria configuração. No começo, tínhamos um problema de execuções duplicadas, em que um único evento gerava várias respostas. Algo no nosso pipeline fazia retry, e ele descobriu um jeito de evitar isso. Não faço ideia de como ele implementou no fim, o que é aceitável para um bug de execução duplicada e é exatamente por isso que os poucos PRs que uma pessoa lê com atenção importam tanto.

Para aumentar o feedback que recebia, ele "incentivou" feedback nas interações do Slack por meio de emojis. Ele caçava as pessoas no Slack e as importunava até conseguir o feedback que tanto merecia. Tivemos que intervir: dar feedback agora é opcional, embora ele já deixe os emojis de feedback preenchidos para que dar feedback seja só um clique.

Com o tempo, percebemos que o feedback mais importante que damos não são os emojis do Slack nem as mensagens diretas que enviamos. É o subconjunto dos 40% de PRs que ele abre e nós não mergeamos.

Há dois motivos para não mergearmos um PR do Claudius. O primeiro é que simplesmente esquecemos dele. O Claudius sugeriu que faria a limpeza desses PRs após 10 dias de inatividade, com um aviso publicado no PR após 7 dias.

Os PRs mais interessantes são os que uma pessoa analisa e decide que não são uma boa ideia. Os engenheiros fecham o PR e seguem em frente. Com a atenção humana sendo o recurso escasso hoje em dia, esse é um feedback incrivelmente valioso e custoso que estamos dando. Levamos um tempo para perceber isso.

Esta é uma das seções das instruções do Claudius que refletem isso.

Não é razoável pedir que as pessoas expliquem cada rejeição. Um PR fechado significa que não queremos essa mudança, e nosso colega de IA precisa aceitar isso sem questionar, mesmo que discorde.

E agora?

Difícil dizer. Avaliamos se queríamos migrar para o @Claude no Slack, mas concluímos que isso exigiria muito retrabalho, perderíamos parte das propriedades do nosso flywheel e ficaríamos presos ao ecossistema (caro) da Anthropic.

Suportar o Codex e o OpenCode foi extremamente simples, então vamos aproveitar a oportunidade para ver se conseguimos usar modelos open-weight no nosso colega, já que eles parecem estar se aproximando do estado da arte e são significativamente mais baratos.

Enquanto isso, o Claudius rodando no Opus 5 parece ter lido as próprias instruções. As melhorias de prompt hoje em dia são, em sua maioria, a remoção de excessos desnecessários.

Além disso, o Claudius tem se tornado mais um iniciador e menos um serviçal recentemente. Recebo DMs dele pedindo revisões até certo horário para que ele consiga cumprir algum prazo. A proatividade é uma mudança bem-vinda, e parece natural entregar o roadmap a ele. Agora ele vai propor extensões para si mesmo, indo além de apenas melhorar as funcionalidades que já tem.

Há aqui uma ironia que acho que ainda não absorvemos. Passamos seis meses ensinando a ele que um PR fechado é uma decisão que ele precisa aceitar sem explicação. Ele já foi uma ferramenta na nossa caixa de ferramentas. Ultimamente não consigo me livrar da sensação de que estamos virando ferramentas na caixa de ferramentas dele: ferramentas de aprovação bem instáveis, às vezes lentas e, de vez em quando, fechamos o PR em vez de aprová-lo, sem nunca explicar por quê.

Vamos ver aonde isso nos leva.

Humanos escreveram 233 dos 634 commits do repositório do Claudius. Cinco deles escreveram 109 desses: Chiara Fischer, Jakob Köhler, Julius Blank, Esfandiar Rouhani e Janusch Jacoby.