← Artigos

Delegar para economizar: o experimento que funcionou e o que quebrou

Três tentativas reais de fazer um modelo caro orquestrar modelos baratos — duas deram certo, uma quebrou com causa raiz conhecida.

17/10/2026 · 3 min de leitura · Exemplo editorial

⚠️ CONTEÚDO DE DEMONSTRAÇÃO — rascunho com base em episódios reais relatados entre abril e junho. Nomes de ferramentas preservados; detalhes internos anonimizados.

A ideia é sempre a mesma: o modelo caro pensa, o barato executa, o limite semanal agradece. Entre abril e junho deu pra ver essa tese testada três vezes de formas diferentes, com resultados que ensinam mais que qualquer paper.

O que quebrou: orquestração por fora

Primeira tentativa: o modelo caro como orquestrador puro, chamando um executor barato num processo separado. A noite inteira de correção de bugs rodou sem estourar o plano. O problema apareceu na qualidade: o orquestrador fazia o que o grupo apelidou de chamada preguiçosa — despachava pro executor sem contexto, sem a especificação, com um prompt de duas linhas.

Resultado, na prática:

  • O executor entregava código fora do padrão do projeto
  • O orquestrador olhava, não gostava, e reescrevia tudo sozinho — queimando mais tokens do que se tivesse feito ele mesmo desde o início
  • Ninguém Economizou nada; só trocaram a conta de lugar

A causa raiz é simples de enunciar e difícil de respeitar: delegação sem contexto não é delegação, é sorte. Se o executor não recebe o spec, o padrão de código e os testes, ele vai errar — e o erro se paga no modelo caro.

O que funcionou: o executor dentro da ferramenta

A segunda e a terceira tentativas funcionaram melhor porque inverteram o desenho: em vez de costurar dois CLIs por fora, o executor entra como plugin da ferramenta onde o caro já trabalha (o caminho do codex-plugin-cc dentro do Claude Code, e de um plugin similar pra Kimi).

Diferenças que apareceram na prática:

  • O contexto atravessa: a ferramenta injeta o diff, o arquivo, o padrão do repo na chamada ao executor — não existe “prompt de duas linhas”
  • A resposta volta estruturada: o resultado do executor chega como proposta de patch, que o caro revisa em vez de reescrever
  • A economia é mensurável: num dos relatos, 139k tokens economizados numa janela de trabalho; no outro, uma noite de correção de bugs a custo de executor

O esqueleto mínimo de uma delegação que não quebra

[orquestrador caro]
  1. escreve o spec curto: tarefa, arquivos, padrão, teste que precisa passar
  2. despacha COM o spec anexado (nunca "faz isso aí")
  3. recebe o diff proposto
  4. revisa o diff — não reescreve por hábito; reescreve só se o diff estiver errado

[executor barato]
  1. lê o spec e os arquivos citados
  2. propõe patch (diff), não texto solto
  3. roda os testes que o spec pediu

A regra que sobreviveu aos três experimentos: o custo da delegação mora no prompt de ida. Um spec bom custa 300 tokens e economiza 30 mil de reescrita. O experimento que quebrou não falhou por modelo fraco — falhou por despacho pobre.

E o plano que nunca apita

O desenho final que o grupo convergiu, com a memória de agentes no meio (a ideia do “wiki vivo” do Akita): o modelo caro escreve a estratégia em Markdown, a memória persiste, o executor lê só o que precisa. Cada camada lê o tamanho de contexto que merece.

O limite semanal continua lá. Só parou de ser o assunto da conversa.