AI Engineering Orchestrator: como usar melhor o modelo de IA caro no desenvolvimento de jogos

Na programação com ajuda de IA, o recurso mais caro costuma ser a cota de uso do modelo mais forte: quando o limite estoura, o trabalho para. O AI Engineering Orchestrator, de código aberto, reserva esse modelo caro para pensar, decidir e revisar e delega a escrita do código a um modelo de acesso mais barato, com o objetivo de render mais trabalho com a mesma cota.

Resumindo

• Claude Code ou Codex assume o papel de "líder da equipe"; quem faz as alterações de código de fato é o Gemini (via Antigravity) ou, como reserva, o Cursor.
• O líder delega cada tarefa com um contrato de implementação por escrito, confere pessoalmente o código que volta com git diff e testes e então decide: APROVADO ou MUDANÇAS NECESSÁRIAS.
• Na medição do próprio projeto, em uma única tarefa, o tempo de API do modelo caro caiu de 8 min 54 s para 3 min 39 s; o desenvolvedor deixa claro que foi um único teste e que não há garantia de economia.
• Tem licença MIT, instala com um único comando via npm e só mexe nas configurações do projeto em que é instalado.

Para que serve o AI Engineering Orchestrator?

Hoje muitos desenvolvedores têm dois tipos de acesso a IA. O primeiro é um modelo caro, mas com raciocínio forte: faz diferença em decisões de arquitetura, depuração e revisão de código, só que o limite da assinatura ou a conta de tokens se esgota rápido. O segundo é um modelo de acesso mais barato, às vezes parado sem uso dentro de um plano que já está pago. O problema: a maioria das pessoas manda o modelo caro fazer tudo, inclusive a escrita rotineira de código.

O AI Engineering Orchestrator (AEO, para encurtar) tenta resolver esse desequilíbrio com uma divisão de trabalho. Nas palavras do próprio projeto, a tese é simples: o modelo caro decide, o barato escreve. Tecnicamente, são duas peças. Uma ponte MCP dá ao modelo líder a capacidade de chamar outro modelo; um arquivo de política adicionado ao CLAUDE.md ou ao AGENTS.md define quando essa capacidade deve ser usada. A ideia central da ferramenta é justamente essa distinção: "não se usa porque a ferramenta existe, usa-se porque a regra manda".

Como aproveitar mais o modelo caro com um acesso barato?

Aqui, "barato" é relativo. A documentação do AEO insiste nesse ponto: um modelo pode sair barato para você por causa do plano de assinatura, de preço para estudantes ou empresas, de preço regional, de uma promoção ou de capacidade não usada em um pacote que você já paga. O mesmo modelo pode ser um mau negócio para outra pessoa. Por isso a ferramenta não declara nenhuma empresa como "a mais barata"; ela só garante que você use o caminho de implementação mais conveniente e suficientemente capaz que tiver à mão.

O fluxo funciona assim. O modelo caro entende o pedido, examina o repositório o suficiente e decide se a tarefa é trivial ou um trabalho real de implementação. Se for trabalho real, escreve um contrato com escopo definido, contendo objetivo, restrições, critérios de aceitação e os testes a rodar, e o envia ao modelo implementador. Escrever o código, adicionar os testes e fazer as rodadas de correção acontece no modelo barato. O que o modelo caro gasta passa a ser leitura e decisão, não escrita de código. Para quem trabalha com uma assinatura com limite de uso, isso significa concluir mais tarefas com a mesma cota.

Se a cota acabar do lado do Antigravity, a ponte primeiro tenta os outros modelos Gemini configurados; se isso também falhar, a política redireciona o mesmo contrato ao Cursor. O objetivo é evitar que, quando o canal de implementação trava, o trabalho volte silenciosamente para o modelo caro.

Como isso ajuda quem desenvolve jogos?

Projetos de jogos se encaixam naturalmente na divisão de trabalho que o AEO propõe. O código de um jogo tem poucas decisões, mas caras (arquitetura de rede, autoridade do servidor, sistema de salvamento, regras de economia), e muito trabalho repetitivo (uma nova tela de menu, uma variante de regra de um modo de jogo, chaves de localização, testes que faltam, refatoração). Na lógica do AEO, o primeiro grupo fica com o modelo líder e o segundo vai para o implementador.

• Equipes pequenas e estúdios de uma pessoa só: Um dev indie é, ao mesmo tempo, designer, programador e responsável pelos testes. Guardar a cota do modelo caro para arquitetura e depuração e delegar o trabalho rotineiro de funcionalidades reduz o risco de o limite acabar no fim do mês.
• Código multiplayer e de servidor: Em temas como concorrência, sessão e permissões, a política recomenda acionar um agente de revisão independente (reviewer). Nessas áreas, onde um erro sai caro, um segundo olhar é mais seguro do que um único modelo aprovando o próprio trabalho.
• Lógica de jogo com testes: Motores de regras, cálculo de pontuação, matchmaking e validação no servidor podem ser testados de forma headless. É aí que o portão de qualidade do AEO funciona melhor, porque o modelo líder não se apoia na frase "os testes passaram", e sim no teste que ele mesmo rodou.
• Trabalho em paralelo: Duas tarefas que não se tocam, por exemplo um modo de jogo e uma tela de estatísticas, podem ir ao mesmo tempo para dois implementadores, em git worktrees separados. As alterações só são aplicadas à árvore de trabalho principal, uma a uma, depois que o líder aprova.

Uma observação honesta: sensação visual, tempo de animação ou a pergunta "o jogo é divertido?" não se capturam com testes. O portão de qualidade do AEO verifica o código em relação ao contrato; a qualidade da jogabilidade você ainda precisa medir jogando. A própria documentação da ferramenta reconhece um limite parecido: se o contrato tiver um erro de design, o código que implementa esse erro ao pé da letra passa pelo portão.

Por que o portão de qualidade importa?

O risco conhecido de passar trabalho a um modelo barato é o relatório de "pronto" não corresponder à realidade. Por isso o AEO trata o relatório do implementador como evidência, não como aprovação. Antes de começar, o modelo líder registra um estado inicial com git status; quando o trabalho volta, ele mesmo examina a diferença, os arquivos alterados e os testes. Um teste que o implementador não conseguiu rodar por bloqueio de permissão não conta como "aprovado". A decisão tem duas opções: APROVADO ou MUDANÇAS NECESSÁRIAS. No segundo caso, as constatações são devolvidas ao mesmo implementador, junto com as evidências.

Essa disciplina tem mais um benefício: graças ao registro inicial, as alterações do próprio usuário que ainda não foram commitadas ficam protegidas; o líder não toca em uma alteração cuja autoria não consegue comprovar. Os exemplos de permissão padrão também bloqueiam comandos git difíceis de desfazer, como push, reset, rebase, merge e commit.

O que mostra uma medição real?

No README do projeto, a correção de um bug de refresh token em uma API Laravel foi medida duas vezes: uma com delegação e outra em uma execução de controle sem as ferramentas de delegação. Foram usados o mesmo commit e o mesmo prompt.

Métrica	Com delegação	Sem delegação
Tempo de API do modelo caro	3 min 39 s	8 min 54 s
Custo calculado	US$ 3,60	US$ 4,32
Custo do modelo implementador	Em assinatura à parte, não somado à conta	Nenhum
Tempo total de espera	Cerca de 30% mais longo	Mais curto
Fonte	README do projeto, outubro de 2026	Uma execução por braço (n=1)

O desenvolvedor não exagera o resultado: a diferença em dólares é de 17% e só existe porque o implementador foi coberto por uma assinatura separada. O ganho real está no tempo de uso do modelo caro: cerca de 59% menor. E, numa assinatura com limite de uso, essa é justamente a restrição que pesa. Em compensação, o trabalho levou cerca de 30% mais tempo por causa das idas e vindas com o implementador, e as duas execuções produziram uma correção de qualidade parecida. De uma única medição não se tira uma taxa geral de economia; o projeto também oferece um script e um método para você medir o seu próprio caso.

Como instalar?

Os requisitos são Node.js 20 ou superior, a ferramenta de linha de comando do Antigravity (agy) com login feito e, como líder da equipe, Claude Code ou Codex. A instalação começa com uma simulação (dry run), que mostra o que vai mudar sem gravar nenhum arquivo. Depois, o comando npx ai-engineering-orchestrator@latest install --target . --claude (ou --codex) adiciona ao projeto a política, as definições de agentes e o servidor MCP; o comando doctor verifica a instalação. Cópias de segurança dos arquivos compartilhados alterados ficam guardadas na pasta do usuário, e as configurações globais só são tocadas se você pedir explicitamente com --global.

Nota de transparência: o AI Engineering Orchestrator é um projeto open source de Akif Şen, desenvolvedor da GAMEAREA, e também é usado no próprio processo de desenvolvimento da GAMEAREA. Os números de medição deste texto vêm da documentação do próprio projeto; não se trata de um teste independente. Explicamos como usamos IA no blog na página dos nossos princípios de uso de IA.

Perguntas frequentes

O AI Engineering Orchestrator é pago?

Não. O projeto tem licença MIT e é instalado gratuitamente via npm. As assinaturas ou taxas de uso dos serviços de IA que você usar (Claude, Codex, Gemini, Cursor) continuam valendo à parte.

Ele garante economia de dinheiro?

Não. O projeto diz claramente que não mede nem garante uma taxa de economia. O ganho depende de quão barato é o seu acesso ao modelo implementador.

Com quais engines de jogo ele funciona?

A ferramenta não é um plugin de engine; ela trabalha no nível do repositório. Em princípio, o mesmo fluxo pode ser aplicado a qualquer base de código que os modelos usados consigam entender, seja Unity, Godot ou um jogo para web; já a força da verificação depende dos testes do projeto.

E se o modelo implementador quebrar o meu código?

O trabalho não é considerado concluído sem aprovação. O modelo líder examina a diferença e os testes e pode responder MUDANÇAS NECESSÁRIAS; em tarefas paralelas, as alterações ficam em um worktree separado e só são aplicadas à árvore de trabalho principal depois da aprovação. Operações como commit e push são proibidas por padrão.

Fontes

1. akifsen / GitHub — AI Engineering Orchestrator (README) Fonte oficial
2. akifsen / GitHub — Cost-aware routing Fonte oficial
3. akifsen / GitHub — Quality gate Fonte oficial
4. npm — ai-engineering-orchestrator Fonte oficial