O Gemini Revisou o PR do Claude. Trinta e Seis Comentários Depois, Ficou Melhor.

Um revisor que sempre concorda com quem escreveu não é um revisor. Passe o código da sua IA por uma IA rival e os pontos cegos se iluminam — incluindo os bugs de segurança de thread que teriam sido entregues em produção.

O padrão ao qual eu sempre volto é aquele em que o Claude escreve o código e o Gemini o revisa. Treinamento diferente. Pontos cegos diferentes. Opiniões diferentes sobre o que é um padrão defensável e o que é um mau cheiro. Este sábado foi a demonstração mais concreta de por que acho que esse padrão é o certo.

Um lote de PRs de expansão de endpoints da Fase 2 tinha sido integrado na superfície da API ao longo da semana anterior. Oito subsistemas separados tiveram cada um sua superfície pública expandida. Claude tinha escrito a maior parte da implementação. Antes de integrar qualquer um deles, eu os passei pelo Gemini como uma passagem de revisão. O Gemini voltou com trinta e seis comentários específicos ao longo do lote.

Trabalhei em cada um deles. Este é o post sobre o que o Gemini pegou e o que significa que as pegadas foram do tipo que foram.

Quais eram os oito subsistemas

Os PRs cobriram os oito módulos de roteador de API que precisavam de expansão da Fase 2: animação, rede, áudio, percepção de IA, geometria construtiva sólida de cena, vinculação de ação de entrada e gamepad, tipos de pose de âncora XR, e ciclo de vida da VM Lua de scripting. Cada PR adicionou entre uma dúzia e quarenta endpoints, com schemas completos de requisição/resposta, auxiliares, e testes.

Os PRs não eram sutis. Cada um era uma expansão substancial da superfície pública. Juntos, eles representavam várias semanas de trabalho de design que os agentes implementaram ao longo de aproximadamente dois fins de semana.

O que o Gemini pegou

Quero ser específico porque as categorias importam.

Animação e rede: referências e auxiliares de árvore de mistura. O Gemini percebeu que os auxiliares de árvore de mistura na API de animação e os auxiliares de topologia na API de rede tinham convenções sutilmente diferentes para como lidavam com referências ausentes. Animação retornava um equivalente de None e deixava quem chama decidir. Rede lançava uma exceção. Ambos são padrões válidos. Eles estavam inconsistentes entre dois PRs integrados com um dia de diferença um do outro. A correção foi alinhá-los; escolhemos o caminho de exceção explícita porque ele revela a referência ausente no limite da API em vez de deixá-la se propagar como um nulo silencioso.

Áudio: valores padrão e auxiliares de modelo de resposta. O Gemini encontrou que vários modelos de resposta de áudio tinham valores padrão inconsistentes para campos opcionais. Alguns tinham como padrão strings vazias, alguns None, alguns um null explícito. A inconsistência teria produzido comportamento confuso na camada de binding de cliente (onde linguagens diferentes serializam cada opção de forma diferente). A correção foi escolher uma única convenção (None nos tipos Python, null na comunicação) e aplicá-la consistentemente.

Percepção de IA: mapas de handle e bindings. O Gemini sinalizou uma preocupação de segurança de thread no mapa de handles do subsistema de percepção: o mapa estava sendo modificado a partir de uma thread em segundo plano enquanto era lido a partir da thread de requisição da API, sem um lock. Sob carga, isso produziria bugs intermitentes de corrupção de mapa que seriam muito difíceis de diagnosticar. A correção foi um lock de leitor-escritor com o caminho de leitura otimizado para o caso comum (buscas superam em muito as inserções).

Cena: mapas de handle e respostas de CSG. Mesma família de bug da descoberta de percepção de IA. O Gemini pegou a mesma preocupação de segurança de thread no mapa de handles de CSG do subsistema de cena. A correção teve a mesma forma: um lock de leitor-escritor. Esse é o tipo de bug que um conjunto de olhos treinados sinaliza em todo lugar porque já viu o padrão; Claude tinha escrito o mesmo padrão em dois lugares e não tinha percebido.

Entrada: bindings de ação e gamepad. O Gemini encontrou que a API de binding de ação estava usando uma convenção de número mágico para IDs de ação inválidos (-1), enquanto a API de binding de gamepad usava um valor de struct sentinela. A inconsistência produziria bugs sutis quando um desenvolvedor trabalhando em ambas as APIs acidentalmente usasse o marcador de inválido errado. A correção foi introduzir uma constante tipada ActionId::Invalid em ambas as APIs e migrar todos os números mágicos para ela.

XR: tipos de pose de âncora e reuso de handler. O Gemini pegou que a API XR estava expondo dois tipos de pose sutilmente diferentes em endpoints diferentes: um em coordenadas de mundo e um em coordenadas locais de âncora. A diferença é real e importa para o consumidor, mas os endpoints não documentavam a diferença com clareza. O Gemini sugeriu dividir os tipos para que o sistema de tipos force a distinção. A correção foi introduzir WorldPose e AnchorPose como tipos distintos sem conversão implícita entre eles.

Scripting: ciclo de vida da VM Lua e vazamentos. O Gemini encontrou que a VM Lua estava sendo alocada por requisição sem um caminho claro de desmontagem. Sob carga sustentada, isso vazaria estado de VM para o espaço de endereçamento até o servidor de API cair. A correção foi introduzir um pool de VM por thread de servidor com semântica explícita de aquisição e liberação, e adicionar um caminho de desmontagem que roda ao final da requisição independentemente de sucesso ou falha.

O que percebi sobre as pegadas como categoria

Três observações.

A maioria das pegadas eram pegadas de consistência. Dois terços dos comentários do Gemini eram “essa convenção difere da convenção usada em outro subsistema que você acabou de integrar.” Esse é exatamente o tipo de pegada em que um único modelo é ruim, porque cada PR foi integrado isoladamente e o modelo que o escreveu não tinha os outros PRs no contexto. Um revisor trabalhando em todo o lote vê as inconsistências que quem escreveu não tinha na cabeça.

Algumas pegadas eram bugs de verdade. As descobertas de segurança de thread nos mapas de handle eram bugs reais. Teriam sido entregues. Teriam sido intermitentes e difíceis de diagnosticar. O Gemini pegou as duas instâncias no lote (uma em percepção de IA, uma em CSG de cena) porque tinha o reconhecimento de padrão para “mapa mutável compartilhado sem lock = preocupação de segurança de thread.” Modelo diferente, treinamento diferente, coisas diferentes para as quais foi calibrado a sinalizar.

Algumas foram estilísticas e viraram debate. Nem todo comentário do Gemini estava certo. Um punhado eram preferências estilísticas sobre as quais eu ou contestei ou pedi julgamento humano. O fato de que alguns comentários foram rejeitados não enfraquece o padrão; ele o fortalece. Um revisor que sempre concorda com quem escreveu não é um revisor.

O que isso faz e não faz

O que faz: pega uma classe de bugs que a revisão de modelo único perde. Especificamente os bugs de consistência entre PRs e as pegadas de reconhecimento de padrão onde um revisor treinado em dados diferentes sinaliza algo que o treinamento de quem escreveu não viu.

O que não faz: substituir a revisão humana. Os comentários do Gemini foram uma primeira passagem. Li cada um. Rejeitei alguns. Aceitei a maioria. A decisão final de integração foi minha. O padrão é “Claude escreve, Gemini revisa, o humano decide.” Não “o Gemini decide.”

O que isso sugere para laboratórios de IA: a métrica para otimizar não é “o próprio código do modelo passa na revisão do próprio modelo.” É “o código do modelo passa na revisão do modelo de um fornecedor diferente.” Os agentes que se saem bem na métrica entre fornecedores são os em que confio para trabalho sério.

O que parceiros e construtores devem tirar disso

Se você está rodando um fluxo de trabalho orientado por agentes e ainda não está rodando revisão de PR pelo modelo de um fornecedor diferente, experimente no próximo lote. O custo de configuração é pequeno. A taxa de captura de bugs não é trivial. O lote de hoje pegou dois bugs reais de segurança de thread que teriam sido entregues.

Se você é um laboratório de IA e ainda não otimizou seu agente de codificação para “revisão de PR contra o modelo de outro fornecedor” como um alvo, considere fazer isso. A métrica é honesta. O sinal é real. Os agentes que pontuam bem nisso são os que times sérios vão adotar.

Se você está avaliando um engine para parceria, o padrão de revisão multi-fornecedor é um dos sinais de disciplina que eu perguntaria. Um time que roda revisão entre fornecedores em todo PR significativo é um time diferente de um que não roda. A base de código reflete a diferença.

Trinta e seis comentários, oito subsistemas, um sábado. O lote está melhor do que estava esta manhã. O padrão mostra seu valor, de novo.

De volta a construir.