Times de Agentes: Quando o Modelo Operacional Muda de Vez

Nicholas Carlini, pesquisador de segurança da Anthropic, publicou esta semana os resultados de um experimento que deveria mudar a forma como pensamos sobre desenvolvimento de software. Ele colocou 16 instâncias do Claude Opus 4.6 para construir, em paralelo, um compilador C escrito em Rust. O resultado: 100.000 linhas de código que compilam o kernel Linux 6.9, o QEMU, o FFmpeg, o SQLite, o PostgreSQL e o Redis. Com 99% de aprovação no GCC torture test suite.

Isso não é uma demonstração de laboratório. É engenharia de produção executada por agentes autônomos.

O Compilador Não É o Ponto

É tentador focar no artefato: um compilador C funcional, construído em duas semanas, que compila projetos reais em múltiplas arquiteturas (x86, ARM, RISC-V). Impressionante, sem dúvida. Mas o artefato é o resultado. A lição está no processo.

Carlini não escreveu prompts elaborados. Não passou horas refinando instruções. O maior esforço, segundo ele, foi no design do ambiente: construir a suíte de testes, definir os ciclos de feedback, configurar as restrições que mantinham os agentes produtivos.

Essa inversão é o insight central: o trabalho do engenheiro não foi escrever código, nem instruir quem escreve. Foi projetar o sistema dentro do qual agentes autônomos produzem código correto.

Design de ambiente, não design de prompt. Essa distinção parece sutil, mas é fundamental.

Testes Como Especificação

A suíte de testes do GCC não funcionou apenas como validação. Funcionou como especificação.

Quando agentes autônomos trabalham sem supervisão humana direta, a única definição confiável do que deve ser construído é o que os testes verificam. Se o teste passa, o comportamento está correto. Se não passa, não está. Não há espaço para interpretação, para “o que eu quis dizer foi…”, para ambiguidade de requisitos.

Isso inverte uma premissa antiga da engenharia de software. Tradicionalmente, especificações geram testes. No modelo de trabalho autônomo, testes são a especificação. A qualidade do software produzido é limitada pela qualidade dos testes que o definem.

A implicação prática é direta: se sua organização planeja delegar trabalho significativo a agentes de IA, a capacidade de escrever suítes de teste abrangentes e precisas deixa de ser uma habilidade complementar e passa a ser a habilidade central da equipe. Testes ruins não produzem apenas software com bugs — produzem software que faz a coisa errada com confiança.

De Pair-Programming para Gestão de Projeto

O Claude Code oferece dois modelos de trabalho com IA: subagentes e times de agentes.

Subagentes são o modelo já estabelecido. Você pede a uma instância que execute uma tarefa; ela delega subtarefas a instâncias menores; os resultados são consolidados e retornados a você. É pair-programming assíncrono. O controle permanece centralizado.

Times de agentes são algo diferente. Múltiplas instâncias do Claude Code trabalham como uma equipe coordenada, com um líder que distribui tarefas, membros que executam de forma independente, uma lista de tarefas compartilhada e uma caixa de mensagens para comunicação direta entre pares. Cada membro tem sua própria janela de contexto, opera de forma independente, e pode trocar mensagens com qualquer outro membro.

A diferença não é de escala. É de modelo operacional.

Com subagentes, você é o programador que usa assistentes. Com times de agentes, você é o gestor de um projeto autônomo. A habilidade necessária muda de “escrever código” e “revisar código” para “definir trabalho”, “projetar ambientes de execução” e “estabelecer critérios de aceitação”.

Carlini demonstrou isso na prática. As 16 instâncias não recebiam instruções detalhadas sobre como implementar cada feature do compilador. Recebiam testes que definiam o comportamento esperado e autonomia para encontrar a implementação. Quando uma abordagem falhava, tentavam outra. Quando um componente conflitava com outro, negociavam via lock files e task claiming.

A especialização emergiu naturalmente. Sem que ninguém designasse papéis, diferentes instâncias gravitaram para diferentes partes do compilador — otimização, parsing, geração de código — baseadas no histórico de sucesso em cada área.

O Problema de Coordenação

Dezesseis agentes trabalhando em paralelo sem coordenação produzem caos. Merge conflicts, trabalho duplicado, decisões arquiteturais contraditórias. Carlini resolveu isso com infraestrutura — lock files para evitar colisões, task claiming para evitar duplicação, testes de integração contínuos para detectar incompatibilidades cedo.

Isso é governança. Não no sentido corporativo abstrato, mas no sentido operacional concreto: regras que permitem que entidades autônomas produzam resultados coerentes sem supervisão constante.

A analogia com equipes humanas é direta e instrutiva. Uma equipe de 16 desenvolvedores trabalhando no mesmo repositório sem processos de branch, code review e integração contínua produziria resultados igualmente caóticos. A diferença é que, com humanos, construímos essa infraestrutura ao longo de décadas. Com agentes, precisamos construí-la agora — e os mecanismos não são necessariamente os mesmos.

Agentes não fazem política de escritório. Não protegem território. Não evitam tarefas desconfortáveis. Mas também não exercem julgamento arquitetural sem que alguém codifique esse julgamento em restrições testáveis. A governança de agentes precisa ser explícita e mecânica onde a governança de humanos pode ser implícita e cultural.

A Questão dos Vinte Mil Dólares

O experimento de Carlini consumiu aproximadamente 2.000 sessões ao longo de duas semanas. Dois bilhões de tokens de entrada, 140 milhões de saída. Custo total: cerca de US$ 20.000.

A pergunta imediata é: isso é caro ou barato?

Um compilador C funcional, com suporte a três arquiteturas, que compila projetos do porte do kernel Linux — quanto custaria com uma equipe humana? Um engenheiro sênior nos Estados Unidos custa, conservadoramente, US$ 200.000 por ano. Dois deles trabalhando por seis meses custariam US$ 200.000 em salários — sem contar infraestrutura, gestão, benefícios. E provavelmente não terminariam em seis meses.

O custo de US$ 20.000 representa uma fração. Mas a comparação bruta é enganosa por dois motivos.

Primeiro, Carlini não é um operador qualquer. Ele é um pesquisador de segurança com profundo conhecimento de compiladores, que sabia exatamente quais testes construir e como estruturar o ambiente. O custo de sua expertise não aparece na conta de tokens.

Segundo, o custo por token continuará caindo. O Opus 4.6 manteve o mesmo preço do Opus 4 — US$ 5 por milhão de tokens de entrada, US$ 25 por milhão de saída — mas com capacidades significativamente maiores. A janela de contexto expandiu para 1 milhão de tokens em beta. As capacidades em coding agêntico melhoraram substancialmente, com o modelo superando o GPT-5.2 em benchmarks como o Terminal-Bench 2.0. A tendência é clara: mais capacidade pelo mesmo preço, e eventualmente mais capacidade por menos.

A questão econômica real não é “custa US$ 20.000 hoje?”. É: quando o custo cair para US$ 2.000, e depois para US$ 200, o que muda na forma como organizamos o desenvolvimento de software?

O Novo Modelo Operacional

Junte as peças e o que emerge não é uma ferramenta melhor. É um modelo operacional diferente.

O engenheiro vira diretor de trabalho. A habilidade central deixa de ser escrever código e passa a ser definir o que deve ser construído, projetar ambientes que orientem a construção, e verificar que o resultado é correto. Isso se parece mais com gestão de projeto do que com programação.

Testes substituem especificações. Em trabalho autônomo, documentos de requisitos têm valor limitado. Testes executáveis são a única especificação que agentes respeitam de forma confiável. A qualidade dos testes determina a qualidade do software.

Governança se torna infraestrutura. Quando múltiplos agentes operam simultaneamente, as regras de coordenação precisam ser codificadas — não em políticas corporativas, mas em mecanismos técnicos. Lock files, task queues, testes de integração, critérios de merge automatizados.

Especialização emerge. Agentes gravitam para áreas onde têm mais sucesso, sem necessidade de designação explícita. Isso não é inteligência — é otimização por feedback. Mas o resultado prático é o mesmo: divisão de trabalho que emerge do ambiente, não de um organograma.

O Que Isso Significa Para Sua Equipe

Se você lidera equipes de tecnologia, três questões práticas merecem atenção imediata.

Seus testes estão prontos para serem especificação? Na maioria das organizações, testes são uma rede de segurança parcial — cobrem cenários críticos e ignoram o resto. Em um modelo de trabalho autônomo, testes precisam ser a definição completa do comportamento esperado. Se a cobertura de testes da sua base de código está abaixo de 60%, você não está pronto para delegar trabalho significativo a agentes.

Você sabe projetar ambientes de execução? Design de prompt é uma habilidade intermediária que já está sendo ultrapassada. A habilidade duradoura é design de ambiente: definir os ciclos de feedback, as restrições, os critérios de sucesso e os mecanismos de coordenação dentro dos quais agentes operam. Isso se parece mais com DevOps do que com engenharia de prompt.

Sua governança é mecânica ou depende de julgamento humano? Governança baseada em “o tech lead revisa tudo” não escala quando agentes produzem código em velocidade e volume que excedem a capacidade de revisão humana. Governança escalável é automatizada: testes que validam comportamento, linters que verificam padrões, pipelines que bloqueiam deploys que não passam nos critérios. Se sua governança depende de alguém “dar uma olhada”, ela não funciona com agentes.

O experimento de Carlini não é uma curiosidade acadêmica. É um preview do modelo operacional que está se tornando viável para equipes de engenharia que investem nas competências certas: design de ambientes, suítes de teste como especificação, e governança codificada em infraestrutura.

A ferramenta já existe. A questão é se sua organização sabe operá-la.

Fontes

Nicholas Carlini. Experimento de compilador C construído por 16 instâncias do Claude Opus 4.6. Fevereiro 2026.
Anthropic. Claude Opus 4.6 — lançamento com janela de contexto de 1M tokens, pensamento adaptativo e melhorias em coding agêntico. Fevereiro 2026.
Anthropic. Claude Code Agent Teams — recurso experimental para múltiplas instâncias coordenadas do Claude Code. Fevereiro 2026.