Descritivo do Projeto

Orquestra Studio

Três agentes de código, um pedido. O Orquestra planeja, divide em tarefas, roda as independentes em paralelo, cada uma na sua cópia do Git, testa, pede a revisão a um agente de outro fornecedor e integra uma de cada vez. Quem aprova o plano e a entrega é a pessoa.

Assistir ao vídeo

Papel: Autor, projeto pessoal
Período: out/2026
Situação: em andamento

LLMs e agentes
Node.js
React
TypeScript
Vite
Git worktrees
Playwright
Codex
Claude Code
Antigravity

A interface do Orquestra no meio de uma execução de teste: duas tarefas concluídas, com os testes e a revisão aprovados, e a terceira, que depende delas, começando. — Imagem do projeto

Evidências

Ciclo completo com as três CLIs reais: 4 tarefas, 10 chamadas, 0 falhas
Validação de 19/10/2026 num repositório de teste: o Codex planeja, o Claude Code implementa e o Antigravity revisa; quatro integrações com os testes depois de cada uma, e 18 de 18 testes na entrega. Uma revisão pediu ajustes, e a segunda aprovou.
Medido.
Paralelização de 1,38× com três tarefas
Validação ao vivo de 20/10/2026, com 2 tarefas independentes e 1 dependente: 6 sessões reais e 8 de 8 verificações. O tempo somado dos agentes dividido pelo tempo de relógio, num projeto de teste pequeno.
Medido.
121 testes automáticos passando
Rodados em 30/10/2026 na base 0.7.1: unidade e integração com Git real, comandos de teste reais e agentes simulados, sem credencial nem cota.
Medido.

O problema

Quem usa mais de um agente de código alterna entre terminais, copia contexto à mão e não tem como mostrar que o resultado foi testado e revisado. Em projetos maiores, a divisão do trabalho, a ordem, o paralelismo e a integração ficam na cabeça de quem opera.

O Orquestra Studio passa isso para o código: um painel local que trata os agentes como executores, planejadores e revisores, e deixa com a pessoa as duas decisões que importam, o plano e a entrega.

As travas no código

O que pode dar errado com um agente editando arquivos fica preso no código, não no prompt:

os testes rodam na base antes de qualquer agente, e uma base quebrada para a execução sem gastar cota;
a tentativa que altera .env, chaves ou certificados é descartada antes do commit;
agentes e testes rodam sem as variáveis de ambiente com cara de segredo;
o planejador e os revisores só leem, e os comandos ficam bloqueados até a pessoa permitir;
o serviço escuta só em 127.0.0.1 e recusa outras origens;
o Orquestra só cria e apaga branches orquestra/*, e a branch da pessoa só muda quando ela aplica.

Quando um agente fica sem cota, sem login ou sem rede, a função passa para o próximo da fila, e o motivo de cada escolha de modelo fica registrado na sessão.

Na tela

A aba Plano do Orquestra: o plano v1 de um projeto de teste, a estimativa em três cenários (otimista, provável e pessimista) e a comparação entre execução sequencial, híbrida e paralela, com o botão "Aprovar e executar". — **1. Plano.** Antes de gastar cota, o plano mostra três cenários de consumo e tempo; sem histórico, os números são hipóteses declaradas.

A aba Execução: duas tarefas concluídas, cada uma com "testes passaram" e "revisão aprovada", e a terceira, que depende das duas, atribuída; abaixo, os agentes de cada etapa. — **2. Execução.** As duas tarefas independentes já passaram pelos testes e pela revisão de outro fornecedor; a que depende delas só começa agora.

A aba Resultado: "Pronta para aplicar", três de três tarefas integradas, e a tabela com oito verificações do comando de testes, da base à entrega, todas aprovadas. — **3. Entrega.** Oito verificações com os testes do projeto, da base à entrega. Aplicar só libera depois de abrir todas as alterações.

Toque fora da imagem para fechar.

Como funciona

Como numa partitura, cada tarefa tem a sua faixa: sai da linha da integração, passa pelos testes e pela revisão, e só então volta a ela.

Plano
O planejador lê um retrato da pasta, sem .env nem chaves, e devolve tarefas em JSON; o código valida as dependências, e a pessoa aprova.
JSON
Cópias
Cada tarefa pronta ganha uma worktree e uma branch próprias; tarefas com arquivos em comum não rodam juntas.
Gitaté 4 em paralelo
Testes
O implementador altera os arquivos e o Orquestra roda os testes do projeto; se falham, a saída volta ao implementador.
npm test
Revisão
Um agente de outro fornecedor lê o diff e a conferência automática, e termina com APROVADO ou AJUSTES.
Integração
Só a tarefa aprovada entra, uma de cada vez, com os testes depois de cada merge.
merge --no-ff
Entrega
Os testes rodam na integração completa; a branch da pessoa só muda quando ela abre as alterações e aplica.

O modelo entra em pontos definidos, e o que ele devolve é validado: estados, escalonamento, isolamento, testes e integração são código. Ao lado, uma tarefa do plano como o planejador a entrega.

Nenhuma tarefa fica pronta porque o agente disse. O revisor nunca é do fornecedor de quem implementou, e sem revisor disponível a tarefa para.

{
  "id": "juntar",
  "title": "Juntar as mensagens",
  "dependsOn": ["ola", "tchau"],
  "files": ["juntar.txt"],
  "acceptance": ["juntar.txt existe"]
}

Decisões

A escolhaEm vez deCusto aceito

O código decide; o modelo entra em pontos definidos

Em vez de: Um framework multiagente em que o modelo conduz o fluxo.

Custo aceito: Mais código próprio para estados, escalonamento e integração.

Uma worktree do Git por tarefa

Em vez de: Agentes editando a mesma pasta ao mesmo tempo.

Custo aceito: Exige um repositório com pelo menos um commit; no Windows, nomes curtos para fugir do limite de caminho do Git.

Revisor de outro fornecedor

Em vez de: O mesmo agente conferindo o próprio trabalho.

Custo aceito: Uma chamada a mais por tarefa, e a tarefa para quando nenhum revisor está disponível.

Integrar uma de cada vez, só a aprovada

Em vez de: Juntar tudo no fim e resolver os conflitos de uma vez.

Custo aceito: A integração vira fila, com os testes depois de cada merge.

Pela assinatura das CLIs, sem chave de API

Em vez de: Chamar as APIs e pagar por token.

Custo aceito: Depende da cota de cada plano; quando uma acaba, a função passa para o próximo agente da fila.

Custo indisponível, nunca zero

Em vez de: Preencher com estimativa o que a CLI não informa.

Custo aceito: Telas com lacunas declaradas; o equivalente em API só aparece com um preço cadastrado, com fonte e data.

Como foi construído

19/10
As três CLIs reais
O demo vira execução real pelo Codex, pelo Claude Code e pelo Antigravity, com a escolha de modelo por função.
19/10
O modo projeto
Plano validado, tarefas com dependências, worktrees em paralelo, revisão cruzada e integração em fila.
19/10
A primeira execução real
Quatro tarefas, 10 chamadas e nenhuma falha; os agentes reais revelam 5 defeitos que os simulados não mostravam.
19/10
A revisão externa
Dois pareceres independentes, cada afirmação conferida no código antes de aceitar; 6 estavam erradas ou imprecisas.
20/10
A versão 0.7.1
A segunda rodada de revisão e a validação ao vivo com as três CLIs, com 8 de 8 verificações.

Projetei e construí dirigindo o Claude Code e o Codex, com os testes e as revisões como portão. Cada defeito visto ao vivo ficou registrado no plano de testes, com a correção e o teste que o cobre.

Hoje e a seguir

Hoje

A base 0.7.1 roda no meu computador com as três CLIs. O Orquestra continua mudando; esta página descreve o ciclo principal, que é o que já foi validado ao vivo.

A seguir

Uma execução de ponta a ponta num projeto real, do plano ao aplicar.
Validar ao vivo o modo avançado, com o analista que faz perguntas, o revisor de segurança e um conflito real resolvido na integração.
Rotular de 30 a 50 revisões reais para medir quanto o revisor acerta, antes de mexer no prompt dele.

As imagens são da interface rodando com o projeto sintético dos testes, com um agente simulado no lugar das CLIs: os nomes de modelo que aparecem nelas vêm do catálogo, não de uma execução real.

Próximo projeto da visitaTCC e Sunny