Claude Escreve, Gemini Revisa, ChatGPT Serve de Rubber-Duck

IA de fornecedor único parece mais fácil no papel e entrega fragilidade na prática. A RakuAI é construída por um loop de agentes multi-fornecedor - e construída para que o modelo de qualquer fornecedor consiga dirigi-la. O processo de desenvolvimento espelha a tese do produto.

Sábado de manhã, café, e o fluxo de trabalho antes de mudar de novo. Quando conto às pessoas que estou construindo um motor ao lado de agentes de codificação autônomos, a primeira pergunta é “qual agente.” A resposta honesta é “vários, em papéis diferentes, e as divisões de trabalho importam.” Este post é a resposta mais longa.

Agora mesmo o fluxo de trabalho de desenvolvimento envolve pelo menos três fornecedores distintos de IA desempenhando partes distintas do loop. A razão não é lealdade ou implicância. É que cada modelo é genuinamente melhor em um formato diferente de trabalho, e tentar fazer um único modelo fazer tudo produz código mensuravelmente pior.

Os papéis, hoje

O Claude escreve a maior parte do código do runtime. Raciocínio de contexto longo através de uma grande base de código, planejamento antes de editar, mantendo muito estado em uma única cabeça. Este é o modelo que rodo na fila de issues para trabalho substancial de subsistema. Quando uma issue diz “implementar um gerenciador de camadas de composição OpenXR e espaços de ação,” o Claude é quem entrega o PR.

O Gemini revisa a maioria dos PRs. Treinamento diferente, pontos cegos diferentes. Quando o Claude entrega um PR, o Gemini lê o diff e questiona. Os tipos de comentário que o Gemini revela são diferentes dos tipos que eu revelaria manualmente. Alguns são ruído. Alguns são úteis. A relação sinal-ruído é boa o suficiente para eu confiar no Gemini como a primeira passada de revisão em todo diff.

O ChatGPT é onde eu faço rubber-duck. Quando estou travado em uma decisão arquitetural e ainda não sei para que lado ela deveria ir, penso em voz alta com o ChatGPT. O modelo não escreve código nesse papel. Ele me questiona sobre suposições, sugere três enquadramentos alternativos, e me deixa discutir com ele. É o papel que um colega sênior desempenharia se eu tivesse um. Atualmente não tenho. O ChatGPT é a simulação.

O Copilot está no editor. Este é o papel de autocompletar. Quando estou escrevendo código à mão (o que acontece menos vezes do que as pessoas pensam, mas acontece), o Copilot é o modelo cujas sugestões vejo na IDE. Ele é bom no trabalho de contexto local, próximas-quatro-linhas.

Esse é o fluxo de trabalho. Quatro modelos, quatro papéis. Cada um é melhor no seu papel do que os outros seriam.

Por que multi-fornecedor importa

Três razões.

O teto de capacidade é diferente por fornecedor. Se eu estivesse rodando um único modelo para todo papel, toda fraqueza desse modelo apareceria como uma fraqueza no processo de desenvolvimento. O Claude é excelente em escrever. Menos excelente em achar bugs na própria escrita. O Gemini é excelente em achar bugs mas não é o modelo que eu deixaria planejar uma refatoração sem supervisão. O ChatGPT pensa bem sobre perguntas arquiteturais abertas mas o código dele em subsistemas reais não é o que eu quero lançar. Cada um é a melhor ferramenta para um encaixe.

Independência na revisão é estrutural. A regra mais importante de todas à qual cheguei é que o modelo que escreve um PR não pode ser o modelo que o revisa. Autorrevisão não é revisão. Ter o modelo de um fornecedor diferente fazendo a primeira passada de revisão produz independência de arquitetura, de dados de treinamento, de modos de falha. Os bugs que o Gemini pega no código do Claude são bugs reais que teriam entrado de outra forma.

Nenhum aprisionamento a um único fornecedor. O motor está sendo construído para receber direção de qualquer LLM em nuvem (coberto mês passado no trabalho do XRAssistantService). O fluxo de trabalho de desenvolvimento que constrói o motor deveria corresponder a essa postura. Não quero que a engenharia deste runtime dependa de um fornecedor permanecer competitivo pelos próximos cinco anos. Nenhum deles vai. Os que são bons agora vão ser bons de jeitos diferentes depois. Rodar um fluxo de trabalho multi-fornecedor na camada de desenvolvimento mantém a engenharia portável.

Os custos honestos

Alguns.

A sobrecarga de coordenação é real. Trocar entre fornecedores no meio de uma tarefa carrega sobrecarga cognitiva. A correção é manter cada tarefa dentro da faixa de um único fornecedor e deixar a passagem de bastão acontecer entre tarefas, não dentro delas.

As contas se acumulam. Rodar quatro assinaturas de modelo não é de graça. O custo é significativo, e estou pagando pessoalmente por enquanto. O retorno sobre isso é mensurável em subsistemas lançados, então a conta fecha nesta fase. Nem sempre vai fechar.

Desvio de qualidade entre fornecedores é uma questão real. Quando o Gemini fica melhor em um tipo de tarefa que o Claude vinha fazendo, a resposta certa é mover essa tarefa para o Gemini. A resposta errada é continuar fazendo do jeito antigo porque o jeito antigo é o que o documento de fluxo de trabalho diz. O documento de fluxo de trabalho tem que ser revisado a cada poucas semanas porque o panorama de modelos se move debaixo do fluxo de trabalho.

Os fornecedores não sabem uns dos outros. Quando o Claude escreve um pedaço de código que vai ser revisado pelo Gemini, o Claude não sabe disso. Quando o ChatGPT discute uma decisão arquitetural comigo, a implementação eventual pelo Claude não vê essa discussão. A integração entre os fornecedores está na minha cabeça. Esse é um lugar frágil para a integração viver, e é uma das coisas que eu gostaria de consertar se estivesse construindo infraestrutura para ajudar outros a rodar esse fluxo de trabalho.

E o lado do runtime?

Esta é a parte onde a história do fluxo de trabalho de desenvolvimento e a história do motor convergem.

O XRAssistantService que entrou duas semanas atrás no runtime é agnóstico de modelo por design. A razão é exatamente a mesma razão pela qual esse fluxo de trabalho de desenvolvimento é multi-fornecedor. A interface é construída para que qualquer um dos modelos desses labs consiga dirigir uma experiência de RA através do runtime. O lab cujo modelo é o melhor em qualquer tarefa dada consegue fornecer a intenção dessa tarefa em qualquer experiência dada.

Essa é a aposta mais ampla: a era do “este produto é construído sobre este modelo deste fornecedor” é curta. A era em que estamos entrando é “este produto é construído em torno de capacidades em formato de modelo, e qual modelo específico preenche qual encaixe de capacidade em qualquer momento dado é uma escolha de configuração.” O motor tem que estar pronto para isso. O fluxo de trabalho de desenvolvimento que constrói o motor deveria refletir isso.

O que eu quero que construtores e labs tirem disso

Se você é um fornecedor de agente de codificação e está lendo isso, a métrica que eu otimizaria é “com que frequência o PR deste agente sobrevive à revisão por um agente de um fornecedor concorrente.” Autoconsistência não é a régua. Sobrevivência à revisão entre fornecedores é a régua. Os agentes que se saem bem nessa métrica vão ser os usados para trabalho sério.

Se você é um desenvolvedor pensando em adotar um fluxo de trabalho assistido por IA para uma base de código séria, não escolha um modelo e pare por aí. Escolha um para escrever. Escolha um diferente para revisar. Use um terceiro para fazer rubber-duck das decisões arquiteturais em aberto. O prêmio de custo é real e a diferença de qualidade é maior.

Se você é um líder empresarial pensando em IA na sua organização de desenvolvimento, o padrão multi-fornecedor é o que vai escalar. A adoção de fornecedor único parece mais fácil no papel. Na prática produz fragilidade, tanto técnica quanto estratégica.

Sábado tranquilo. O motor ganhou um fim de semana de trinta e cinco commits. A maioria desses commits vai ser invisível daqui a seis meses. O fluxo de trabalho que os produziu não vai.