Pepper-orchestrator montou três pacotes em 1 hora e 52 minutos sem código manual

Um único agente de IA monta um protótipo razoavelmente bem enquanto o projeto inteiro cabe na cabeça de uma pessoa. Depois começa uma dor conhecida: uma mudança de API afeta o repositório vizinho, dois executores editam um arquivo compartilhado e os testes confirmam exatamente as premissas com que o código foi escrito. Maxim Nikitin, do estúdio ITSalt, propõe resolver isso não com um prompt maior, mas dividindo a responsabilidade.

Seu plugin pepper-orchestrator para Claude Code e Codex transforma um objetivo grande em um programa de pequenos pacotes de trabalho. Cada pacote recebe seu próprio contexto, branch ou cópia de trabalho, caminhos permitidos, dependências e critérios de aceitação verificáveis. O próprio orquestrador não escreve o código dos módulos: ele mantém a visão geral, define a ordem de execução e entrega o resultado a um revisor independente.

Como isso se parece em um caso simples

A demonstração exigia criar um aplicativo para um especialista em compras. O usuário carrega contratos em texto e recebe uma tabela com número, fornecedor, valor e prazo de entrega. Os documentos continham armadilhas propositais: ao lado do preço havia um adiantamento, o limite «não mais que 600 000 rublos» parecia o valor total, e o prazo de pagamento podia ser confundido com o prazo de entrega.

O orquestrador dividiu o trabalho em três pacotes: o motor de análise de documentos, a interface com um sistema de design e uma nota explicativa. As partes independentes foram para cópias separadas do repositório. Os arquivos compartilhados deviam ser alterados em sequência, de modo que as sobreposições ficaram visíveis antes do início do trabalho, e não durante o merge.

Após 1 hora e 52 minutos, os três pacotes foram formalmente encerrados. O autor não escreveu código manualmente, mas tomou decisões de produto e resolveu ações controversas. É um esclarecimento importante: não se trata de uma fábrica autônoma de software, mas de um sistema em que a pessoa continua sendo a dona do programa e controla permissões, merge e publicação.

Por que testes verdes não bastaram

A primeira versão do motor passou nos próprios testes, mas um revisor independente reformulou as condições dos contratos com outras palavras e encontrou três erros cometidos com total confiança. O adiantamento era tomado como valor total, o limite como preço do contrato e o prazo de pagamento como prazo de entrega. O pacote foi devolvido para correção, e depois os valores duvidosos passaram a ser marcados como exigindo verificação.

Em seguida, o produto foi examinado por três «clientes» distintos: um usuário leal, um usuário deliberadamente descuidado e um concorrente em busca de casos extremos. Este último encontrou mais dois erros na interpretação do valor e de um aditivo contratual em vigor. Uma implantação limpa revelou timeouts que não apareciam na máquina do desenvolvedor e seis pontos pouco claros nas instruções.

A principal ideia de engenharia aqui é simples: a mensagem «pronto» de um agente é uma afirmação, não uma prova. O executor e o revisor não devem compartilhar o mesmo contexto, caso contrário o segundo herda as premissas do primeiro. Vale verificar não só o código, mas também o comportamento do produto: com dados parafraseados, em uma máquina limpa e em cenários de usuários com intenções diferentes.

Onde a abordagem é realmente útil

A orquestração se justifica quando a tarefa envolve vários módulos ou repositórios, o trabalho pode ser dividido por arquivos e o resultado é descrito por critérios observáveis. Para uma correção pequena, essa estrutura apenas acrescenta logs, cópias do repositório e o custo de sessões extras de agentes.

Há também um limite na evidência: os números foram obtidos pelo autor do plugin em seu próprio caso, sem comparação com o desenvolvimento convencional e sem medição independente de qualidade. Por isso, 1 hora e 52 minutos não pode ser considerada uma métrica universal de aceleração.

A conclusão prática para uma equipe: primeiro fixe um objetivo, os limites dos pacotes e as dependências; depois separe a execução da verificação; deixe as ações irreversíveis com uma pessoa. Um orquestrador é útil não pelo número de agentes, mas porque torna explícitos o estado, a responsabilidade e os critérios de aceitação.