Três agentes entram num bar: meu experimento para programar mais e gastar menos

Chega um momento na vida de todo programador com copilotos em que você olha a fatura mensal e pensa: “Tudo bem, mas tem mais assinatura aqui do que no meu plano da academia do bairro”.

Esse momento chegou para mim com uma combinação bastante séria: Claude Max 5, Codex Plus e a tentação de experimentar Z.AI com OpenCode para os trabalhos mais baratos. A ideia parecia ótima. Mas o problema é outro: se você coloca três agentes no seu fluxo sem regras, acaba como aquele chefe de obra que tem todo mundo correndo de um lado para outro, mas ninguém segurando o projeto.

Minha conclusão inicial é muito simples: antes de automatizar o routing, vale fazer um experimento manual. Por umas duas semanas. Com regras simples, mas claras.

O problema não é o preço. É a bagunça

Pagar 23 euros, 90 euros ou 10 dólares individualmente parece ser tranquilo.

A confusão começa quando cada ferramenta começa a competir com as outras. Você pede para uma pensar, para outra implementar, volta à primeira para revisar, e finaliza com a terceira para um trabalho mecânico. Em vinte minutos, você já nem sabe mais se está otimizando custo, qualidade ou só se entretendo trocando de janela.

Traduzindo: o custo real não é só a mensalidade. Também é a mudança constante de contexto.

É como ter uma cozinha com uma faca japonesa, uma Thermomix e uma fritadeira de ar. Todas têm utilidade. Todas fazem coisas diferentes. Mas se você usar a Thermomix para fritar batatas, de jeito nenhum vai funcionar.

Minha hipótese: pensar, executar, limpar

A política que quero testar cabe em três linhas:

• Claude para pensar
• Codex para executar
• GLM/Z.AI para limpar

Não é uma teoria acadêmica. É uma regra de oficina.

Quando uma tarefa vem mal definida, envolve arquitetura, traz riscos ou exige julgamento, o lógico é entregá-la ao agente que melhor raciocina. No meu caso, Claude.

Quando a tarefa já está bem clara e o que precisa ser feito é entrar no repositório, mexer nos arquivos, rodar testes e iterar sobre os erros, aí entra o Codex.

E para aquele trabalho mecânico que ninguém quer fazer, mas alguém precisa resolver — como testes simples, documentação, pequenos scripts, renomeações ou refatorações automáticas — quero testar o GLM com OpenCode.

O que eu NÃO quero fazer agora

Eu não quero criar um roteador automático.

Não quero uma camada mágica que leia o prompt, classifique a tarefa, escolha o fornecedor, troque de modelo de acordo com o horário e ainda me traga um gráfico bonitinho para justificar toda a complexidade.

Isso parece um projeto superdivertido. Também parece um grande erro feito cedo demais.

O erro clássico aqui é construir uma torre de controle antes de saber se realmente há tráfego aéreo. Primeiro, é preciso observar. Depois, veremos se vale a pena colocar semáforos.

A política manual de duas semanas

O experimento que vou fazer é bem menos glamouroso, mas provavelmente será muito mais útil.

1. Claude para tarefas difíceis

Começo com Claude se qualquer uma das seguintes situações ocorrer:

• eu não tenho clareza sobre como começar
• envolve decisões de design
• há risco de quebrar algo crítico
• preciso revisar argumentos, não apenas código

Traduzindo: se a tarefa exige julgamento, não economizo aqui.

2. Codex para o trabalho principal no repo

Eu uso Codex quando a tarefa está estruturada:

• implementar mudanças reais
• corrigir testes
• refatorar com validação
• iterar até que o projeto volte ao estado funcional

Aqui é onde um bom agente de execução vale o investimento. Não pelo modelo em si, mas pelo fluxo que ele organiza.

3. Z.AI para trabalho barato e substituível

A regra para o Z.AI seria:

• boilerplate
• rascunhos
• documentação
• testes simples
• pequenos scripts
• renomeações
• mudanças mecânicas fáceis de revisar

Se houver falhas, isso não importa muito. Dá para descartar e refazer em outro lugar.

Essa é a chave. Não quero pedir precisão ao GLM. Quero pedir peças simples.

A regra mais importante: se falhar duas vezes, escalo

Aqui está a parte mais valiosa e a mais ignorada por muita gente.

Quando uma ferramenta barata falha, a tentação é insistir. “Só mais uma tentativa.” “Agora vai.” “Faço uns ajustes no prompt.” “Dou mais contexto pra ver se funciona.” E meia hora depois você ainda está negociando com o modelo como se fosse uma impressora HP endiabrada.

Minha regra para este experimento é:

• se Z.AI falhar em 1-2 tentativas, a tarefa escala
• se o problema for de execução, sobe para o Codex
• se o problema for de entendimento ou design, sobe para o Claude

O barato deixa de ser barato quando rouba vinte minutos do seu tempo.

O que quero medir de verdade

Não me interessa fazer benchmark theatre.

Não vou montar uma tabela com tokens por segundo, latência média e outras métricas que parecem impressionantes, até lembrar que meu problema real era renomear quarenta símbolos sem perder a tarde.

O que quero medir nas próximas duas semanas é isso:

Se o experimento funcionar, ótimo.

Se der errado, melhor descobrir logo e gastar dez dólares nisso do que construir um mini aeroporto sem necessidade.

Ferramentas reais, não imaginárias

A peça barata do experimento não saiu do nada. OpenCode existe e foi criado exatamente para trabalhar com provedores e agentes direto do terminal. A Z.AI documenta seu coding plan e como usa seus modelos GLM para ferramentas de programação.

Isso não significa que vou substituir Codex ou Claude diretamente. Significa que há uma base sólida para testar sem inventar histórias.

As referências oficiais que consultei para evitar escrever ficção:

• OpenCode: https://opencode.ai/docs
• Z.AI DevPack: https://docs.z.ai/devpack/overview

Meu palpite hoje

Minha aposta, hoje, é nada épica:

• manter o Claude Max 5
• manter o Codex Plus
• testar o Z.AI Lite para trabalho simples
• não automatizar o routing por enquanto
• revisar em duas semanas se isso reduz a cota de verdade ou só adiciona complicação

A política mental cabe em um post-it:

Se há confusão, Claude.
Se é pra construir, Codex.
Se é pra limpar, GLM.
Se GLM falhar duas vezes, acabou a brincadeira.
---

Não é elegante. Não tem YAML. Não tem _MCP_. Nem precisa de um painel com luzes piscando. E, justamente por isso, acho que pode funcionar.

Porque às vezes a diferença entre um sistema útil e um trambolho desnecessário não está em adicionar mais inteligência.