Fui dormir. O Claude Code entregou a feature.
TL;DR: Descrevi o ticket JIRA-98 para o Claude Code, fechei o notebook e fui dormir. Quando acordei, dois repos tinham branches novas: backend-agent e frontend-agent tinham rodado em paralelo durante a noite, entregando entidades, migrations, CreditRequestService, DTOs, endpoints, modal e wizard de 7 etapas. Este post conta o que aconteceu, como o sistema funcionou tecnicamente e o que isso muda na prática.
Era quase meia-noite. Eu tinha na frente o JIRA-98: o fluxo completo de solicitação de crédito. Entidades novas, migrations de banco, um service com lógica de negócio, DTOs, endpoints de API, um modal de solicitação e um wizard com 7 etapas no frontend.
No passado, isso seria dois dias de trabalho. Talvez três.
O ticket era a visão de produto: a história detalhada do que o usuário precisava fazer, escrita do ponto de vista de quem usa o sistema. Nada de especificação técnica, nada de DTOs ou entidades. Só o fluxo, a necessidade, o contexto. Iniciei o Claude Code, mandei o ticket e fui dormir.
A última mensagem que recebi antes de apagar a tela: "Vou te notificar quando ambos terminarem. Pode dormir que amanhã tem código novo te esperando."
De manhã, tinha.
O que é multi-agent no Claude Code
O Claude Code pode instanciar múltiplos agentes em paralelo usando a ferramenta Agent. Cada subagente roda com sua própria janela de contexto, suas próprias ferramentas e seu próprio escopo de atuação. O agente orquestrador coordena tudo: decide o que delegar, para quem e quando.
Três características tornam isso útil de verdade:
- Paralelismo real: tarefas independentes rodam ao mesmo tempo, não em fila.
- Especialização: cada subagente recebe um prompt focado no seu domínio, sem ruído do restante do projeto.
- Coordenação por resultado: o orquestrador só avança quando os subagentes reportam conclusão, e pode usar o output de um como input de outro.
A pesquisa de autonomia da Anthropic mostra que o 99,9° percentil de duração de execução quase dobrou entre outubro de 2025 e janeiro de 2026, passando de menos de 25 minutos para mais de 45 minutos. O agente ficou mais capaz de sustentar trabalho longo sem intervenção humana.
A arquitetura por trás da noite: personas especializadas
O que rodou naquela noite não é o Claude Code padrão. É uma arquitetura custom que construí em cima do Claude Code, com personas especializadas que assumem papéis fixos dentro de cada execução. A ideia foi inspirada pelo harness que o Northon Torga montou, que me mostrou como vale a pena estruturar o trabalho do agente em funções bem definidas em vez de deixar tudo solto numa instrução gigante.
As personas são:
maestro: o orquestrador central. Lê o ticket, monta o plano de execução e coordena tudo o que acontece depois.architect: recebe o briefing do maestro e produz um plano técnico detalhado antes de qualquer linha de código ser tocada.contextualizer: lê e processa o codebase para montar o contexto que os coders vão precisar.coder: executa o código. Nessa noite, dois coders rodaram em paralelo: um focado no frontend, outro no backend.reviewer: entra após os coders terminarem e revisa o que foi gerado antes de qualquer commit.tester: cuida dos testes.
Além das personas, o sistema tem skills que automatizam partes específicas do fluxo: plan-from-jira para ler o ticket direto do Jira, dispatch para disparar os agentes em paralelo, update-jira para fechar o card ao final, e um conjunto de skills de infraestrutura como task-tracking, agent-memory, boot e context-maintenance.
Como o agente dividiu o trabalho
O fluxo real daquela noite foi este:
Primeiro, o maestro leu o JIRA-98 diretamente do Jira usando a skill plan-from-jira. Sem copiar e colar, sem prompt manual: o ticket entrou no sistema como estava.
Com o ticket em mãos, o maestro chamou o architect. O architect produziu um plano técnico detalhado: quais entidades criar, qual o contrato do CreditRequestService, quais endpoints expor, como o wizard divide o fluxo nas 7 etapas. Só depois desse plano aprovado a execução começou.
O maestro então usou a skill dispatch para disparar dois coders em paralelo. O coder de backend ficou com as entidades do domínio de crédito, as migrations, o CreditRequestService, os DTOs e os endpoints. Também implementou HMAC para autenticar as requisições da feature: cada chamada ao serviço de crédito é assinada e verificada no servidor, garantindo que só requisições legítimas do frontend chegam à camada de negócio. O coder de frontend ficou com o modal de solicitação, o wizard de 7 etapas, os hooks de API e os formatters.
Os dois rodaram ao mesmo tempo. Enquanto o backend construía a camada de dados, o frontend já estruturava os componentes com os tipos corretos, porque o architect tinha passado o contrato de dados para ambos antes do dispatch.
Quando os coders terminaram, o reviewer entrou em ação. Revisou o código gerado, apontou ajustes e liberou para commit.
Por fim, o maestro abriu os PRs nos dois repos e usou a skill update-jira para atualizar o card JIRA-98 automaticamente. De manhã, o Jira já mostrava o card fechado com os links dos PRs.
Por que isso funcionou: o trabalho real aconteceu antes
A parte mais contraintuitiva: o trabalho mais importante não foi o que o agente fez. Foi o que eu fiz antes de dormir.
O ticket era uma user story bem escrita. Não uma especificação técnica. O architect é que traduziu isso em plano técnico: quais entidades criar, quais as responsabilidades do CreditRequestService, como o wizard divide o fluxo. Meu trabalho foi descrever o que o usuário precisa. O trabalho do sistema foi descobrir o como.
Sem essa clareza, o agente teria produzido algo tecnicamente correto e funcionalmente errado. O agente executa bem quando o "o quê" está claro. Ele não decide o "o quê" por você.
É o mesmo princípio que descrevi quando o Claude Code construiu este blog: o orquestrador só consegue coordenar bem quando recebe um contrato claro entre as partes. A diferença aqui foi escala. Um repo virou dois, um contexto de janela virou oito leituras em paralelo, um agente virou dois com escopo definido.
O que o auto mode muda nesse cenário
Em março de 2026, a Anthropic lançou o auto mode para o Claude Code: um classificador que avalia cada ação antes de executar e aprova automaticamente as operações seguras, sem pedir confirmação do desenvolvedor.
O efeito prático para trabalho noturno é direto. Sem auto mode, o agente para em cada ponto de permissão e espera aprovação humana. Com auto mode, ele segue, porque o classificador já fez a avaliação. A sessão pode durar horas sem interrupção.
A pesquisa da Anthropic mostra que usuários experientes com mais de 750 sessões já usam aprovação automática em mais de 40% dos casos. A confiança no agente cresce com o uso, e as ferramentas estão acompanhando isso.
O que ainda depende de você
Seria desonesto deixar só a parte boa.
O agente não sabe o que você não disse. Se o prompt omitiu um caso de negócio, ele não vai inventar. Se a descrição do CreditRequestService foi ambígua, o comportamento gerado vai refletir essa ambiguidade. Você colhe o que planta no ticket.
A revisão continua sendo necessária. Não linha por linha de cada arquivo, mas uma revisão de comportamento: a feature faz o que precisa fazer? Os edge cases estão cobertos? Os testes testam o que importa? A pesquisa da Anthropic aponta que 80% das tool calls incluem pelo menos uma salvaguarda e apenas 0,8% envolvem ações irreversíveis, mas revisão de comportamento após a execução continua sendo necessária.
E há uma camada que o agente não alcança: o julgamento sobre o que deve existir. Decidir que esse fluxo de solicitação de crédito é o fluxo certo, que essas 7 etapas fazem sentido para o usuário, que essa é a hora certa de construir isso. Isso continua sendo trabalho humano.
O gargalo mudou de lugar
O que mudou com essa experiência não é "agora a IA escreve código por mim". É algo mais específico: a execução deixou de ser o gargalo.
Antes, eu serializava tudo. Terminar o backend antes de começar o frontend era uma estratégia para manter controle. Com dois agentes rodando em paralelo em repos separados, essa serialização virou opcional.
Mas o gargalo novo não é só escrever um bom ticket. São três coisas que se tornaram o trabalho real do time.
A primeira é a revisão do código gerado. O agente entrega, mas alguém precisa revisar. Para que essa revisão seja viável em escala, o time construiu uma esteira de testes e2e robusta no projeto. Sem cobertura de testes confiável, revisar o output de um agente vira um processo manual lento e sujeito a erro.
A segunda é construir e manter os próprios agentes. Grande parte do esforço está em criar os agentes, dar contexto para eles, corrigir quando erram e continuar melhorando continuamente. O sistema que rodou naquela noite não existia pronto: foi construído, ajustado e refinado ao longo do tempo.
A terceira é ensinar os agentes sobre o projeto. Os agentes são como desenvolvedores júniors: chegam sem saber nada do seu codebase, das práticas que o time quer usar ou de como o produto funciona. Precisam ser ensinados. Esse onboarding contínuo é trabalho real, e ele nunca termina completamente.
Se você quiser acompanhar como isso evolui no dia a dia, incluindo os erros e as limitações que aparecem ao longo do caminho, o Builders Hub é o melhor lugar para isso.
Perguntas Frequentes
O que é o JIRA-98 e qual era o escopo real da feature?
JIRA-98 era um ticket de produto cobrindo o fluxo completo de solicitação de crédito. O escopo incluía a camada de dados (entidades, migrations), a camada de negócio (CreditRequestService, DTOs, endpoints) e a camada de interface (modal, wizard de 7 etapas, hooks e formatters). Uma feature que em desenvolvimento tradicional levaria dois a três dias.
Como o Claude Code coordena dois agentes em repos diferentes ao mesmo tempo?
O agente orquestrador dispara os subagentes com a ferramenta Agent, passando para cada um o contrato de dados compartilhado e o escopo do seu domínio. Cada subagente roda em thread separada com janela de contexto isolada, sem interferir no outro. O orquestrador aguarda a conclusão de ambos antes de continuar. Branches separadas (feat/JIRA-98) nos dois repos garantem que o trabalho paralelo não cria conflitos.
O que precisa estar no ticket para o agente entregar uma feature completa?
Uma boa história de usuário: o que a pessoa precisa fazer, por que precisa e qual o resultado esperado. O architect traduz isso em plano técnico. Quanto mais claro o fluxo do usuário, menos margem para o sistema tomar decisões erradas. Você define o problema. O agente descobre como resolver.
É seguro deixar o agente rodar em dois repos sem supervisão? Depende do escopo e da maturidade do codebase. Para implementação de features novas em repos que você conhece bem, com testes cobrindo o comportamento esperado, o risco é gerenciável. O auto mode da Anthropic usa um classificador que avalia cada ação antes de executar e bloqueia operações arriscadas. Revisão de comportamento após a execução continua sendo necessária, especialmente para lógica de negócio crítica.
Isso muda o que é possível para um desenvolvedor solo? Sim, no sentido de que o gargalo muda de lugar. A execução de código se automatiza progressivamente. O julgamento sobre o que construir, para quem, quando e por quê continua sendo trabalho humano. O que muda é a capacidade de rodar múltiplas frentes de trabalho ao mesmo tempo sem precisar de um time. Para um desenvolvedor solo, isso equivale a ter a capacidade de paralelização que antes era exclusiva de times de engenharia.