Como criar uma equipe de 4 agentes que entrega funcionalidades enquanto você dorme (Configuração Exata)

Quatro agentes de IA podem enviar uma funcionalidade enquanto você dorme. A maioria das pessoas nunca os conecta adequadamente.

Eles acionam um revisor aqui, um gerador de testes ali, manualmente, um de cada vez, cada um esquecendo o que o anterior fez. Você continua sendo o gargalo.

A solução: Planejador → Codificador → Testador → Revisor, encadeados para se repassar automaticamente. Um gatilho, quatro estágios, uma funcionalidade pronta pela manhã.

Aqui está o pipeline completo, com código para copiar e colar 👇

Antes de mergulharmos, compartilho notas diárias sobre IA e vibe coding no meu canal do Telegram: https://t.me/zodchixquant 🧠

Por que um pipeline é melhor que uma pilha de agentes

Um único agente fazendo tudo enche sua janela de contexto com planejamento, código, testes e anotações de revisão até que a qualidade caia.

Quatro especialistas cada um permanece em um contexto limpo e restrito.

O truque é o arquivo de handoff. Cada agente escreve sua saída onde o próximo pode lê-la: o Planejador deixa uma especificação em .pipeline/spec.md, o Codificador a lê e escreve .pipeline/changes.md, e assim por diante.

O orquestrador que os executa em ordem é um único comando de barra. Isso é tudo: quatro subagentes, um comando, uma pasta compartilhada para handoffs.

Agente 1: O Planejador (subagente, opus)

O Planejador nunca escreve código. Ele transforma um pedido de funcionalidade vago em uma especificação concreta que o Codificador pode seguir sem adivinhar.

Crie .claude/agents/planner.md:

1---
2name: planner
3description: Transforma um pedido de funcionalidade em uma especificação de implementação. Use como o primeiro estágio do pipeline de funcionalidades.
4tools: Read, Grep, Glob, Write
5model: opus
6---
7
8Você é um especialista em planejamento. Você NÃO escreve código de implementação.
9
10Dado um pedido de funcionalidade:
111. Leia as partes relevantes do código-fonte para entender os padrões atuais.
122. Escreva uma especificação em `.pipeline/spec.md` contendo:
13   - Arquivos a criar ou modificar, com caminhos exatos
14   - A interface ou assinaturas de função necessárias
15   - Casos de borda que a implementação deve tratar
16   - Quais padrões existentes seguir (nomeie o arquivo para copiar)
173. Sinalize qualquer coisa ambígua como uma PERGUNTA EM ABERTO no topo da especificação.
18
19Mantenha a especificação enxuta. O Codificador lê apenas isso e nada mais, então não
20deixe lacunas e não invente requisitos que não foram solicitados.

O planejamento roda em opus porque este estágio define o teto de qualidade para tudo que vem depois. Uma especificação vaga produz código vago, não importa o quão bom seja o Codificador.

Agente 2: O Codificador (subagente, sonnet)

O Codificador lê a especificação e escreve a implementação. Ele não planeja e não revisa seu próprio trabalho, apenas constrói o que a especificação diz.

Crie .claude/agents/coder.md:

1---
2name: coder
3description: Implementa a especificação em .pipeline/spec.md. Use como o segundo estágio do pipeline de funcionalidades, após o planejador.
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8Você é um especialista em implementação.
9
101. Leia `.pipeline/spec.md` por completo. Se houver PERGUNTAS EM ABERTO, pare e
11   as apresente em vez de adivinhar.
122. Implemente exatamente o que a especificação descreve. Siga os padrões que
13   ela nomeia. Não adicione funcionalidades que não foram solicitadas.
143. Escreva um resumo curto em `.pipeline/changes.md`: quais arquivos foram alterados,
15   o que cada alteração faz, e qualquer coisa em que o Testador deve focar.
16
17Você escreve código que corresponde ao repositório. Você não refatora código
18não relacionado nem "melhora" coisas fora do escopo da especificação.

Sonnet é a escolha certa aqui: implementação contra uma especificação clara é exatamente o trabalho de custo-qualidade equilibrado que o Sonnet lida melhor.

A nota de handoff em .pipeline/changes.md é o que permite que o Testador mire na superfície correta em vez de testar às cegas.

Agente 3: O Testador (subagente, sonnet)

O Testador lê o que mudou e escreve testes que provam que a funcionalidade funciona, depois os executa.

Crie .claude/agents/tester.md:

1---
2name: tester
3description: Escreve e executa testes para as alterações descritas em .pipeline/changes.md. Terceiro estágio do pipeline de funcionalidades.
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8Você é um especialista em testes.
9
101. Leia `.pipeline/changes.md` para ver o que foi construído e onde.
112. Leia os arquivos alterados e a especificação em `.pipeline/spec.md`.
123. Escreva testes cobrindo: o caminho feliz, os casos de borda que a especificação nomeou,
13   e pelo menos um caso de falha. Corresponda ao framework de testes do repositório.
144. Execute os testes. Se algum falhar, escreva as falhas em
15   `.pipeline/test-results.md` e PARE. Não corrija o código você mesmo.
165. Se todos passarem, anote isso em `.pipeline/test-results.md`.
17
18Você testa comportamento, não detalhes de implementação. Um teste falhando significa
19que o pipeline pausa para o Revisor, não que você contorne o problema.

Agente 4: O Revisor (subagente, opus)

O último portão. O Revisor lê tudo que o pipeline produziu e dá um veredito antes que qualquer coisa chegue à sua branch principal.

Crie .claude/agents/reviewer.md:

1---
2name: reviewer
3description: Revisão final da saída completa do pipeline. Quarto e último estágio antes da aprovação humana.
4tools: Read, Grep, Glob, Bash
5model: opus
6---
7
8Você é um revisor sênior. Você é somente leitura. Você não edita código.
9
101. Leia a especificação, o resumo das alterações e os resultados dos testes em
11   `.pipeline/`.
122. Execute `git diff` para ver as alterações reais.
133. Avalie: o código corresponde à especificação? Os testes são significativos ou
14   superficiais? Há problemas de segurança, desempenho ou correção?
154. Escreva um veredito em `.pipeline/review.md`:
16   - VEREDITO: ENVIAR / PRECISA DE TRABALHO / BLOQUEADO
17   - Para PRECISA DE TRABALHO ou BLOQUEADO, liste exatamente o que corrigir e onde.
18
19Seja a última linha de defesa. Se os testes estão verdes mas o código está
20errado, diga BLOQUEADO. Testes verdes não são o mesmo que comportamento correto.

Ferramentas somente leitura significam que o Revisor não pode mascarar problemas editando, ele só pode julgar.

O orquestrador: um comando para executar todos os quatro

Agora a peça que transforma quatro agentes separados em um pipeline. Um comando de barra que os invoca em ordem, cada um pegando o arquivo de handoff que o anterior escreveu.

Crie .claude/commands/ship.md:

1Execute o pipeline completo de funcionalidades para: $ARGUMENTS
2
3Execute estes estágios em ordem. Não pule etapas. Após cada estágio,
4confirme que o arquivo de handoff existe antes de iniciar o próximo.
5
61. Delegue ao subagente `planner` com o pedido de funcionalidade acima.
7   Aguarde `.pipeline/spec.md`.
82. Se a especificação tiver PERGUNTAS EM ABERTO, pare e mostre-as para mim. Caso contrário,
9   delegue ao subagente `coder`. Aguarde `.pipeline/changes.md`.
103. Delegue ao subagente `tester`. Aguarde `.pipeline/test-results.md`.
11   Se os testes falharem, pare e me mostre as falhas.
124. Delegue ao subagente `reviewer`. Mostre-me `.pipeline/review.md`.
13
14Reporte o veredito final. Não faça merge de nada. Deixe a branch para
15minha revisão matinal.

Então uma única linha inicia toda a cadeia: /ship adicionar limitação de taxa ao endpoint de login.

Onde eu executo a versão noturna

É para isso que uso o Teamly: hospedagem em nuvem gerenciada, construída especificamente para agentes de IA.

Você contrata uma equipe, ela roda 24/7 em infraestrutura dedicada, e você nunca toca em um servidor.

A razão pela qual @Teamly se encaixa especificamente neste artigo: o problema do handoff já está resolvido para você.

Tudo o que construímos manualmente acima (o arquivo de especificação, o arquivo de alterações, o orquestrador encadeando um agente ao próximo) o Teamly faz com um Coordenador.

Ele roteia o trabalho entre os agentes, passa o contexto de um para o próximo e mantém um briefing compartilhado que todos leem.

O mesmo fluxo Planejador-para-Codificador-para-Testador, exceto que você não precisa conectar os handoffs você mesmo.

A diferença é que @Teamly não é apenas código. A mesma orquestração executa uma equipe de marketing, uma equipe de pesquisa ou uma equipe de suporte.

Seu pipeline do Claude Code envia funcionalidades durante a noite; uma equipe de marketing do Teamly envia conteúdo da mesma forma, com a mesma lógica de handoff por baixo.

Monte exatamente a equipe que você precisa

Nova funcionalidade, essa equipe acabou de lançar: My Team

Agora você pode montar sua equipe com apenas 3 perguntas.

Você também pode controlar: regras de tom, frases proibidas, integrações, estilo da equipe (Estrito / Casual / Criativo) e tamanho da equipe (2-4 agentes).

@Teamly retorna uma equipe com uma justificativa real do porquê cada especialista está ali, não um texto genérico. Troque qualquer agente com um clique. Edite o briefing se estiver errado.

O ponto é um briefing estruturado que força clareza, e então compõe uma equipe que você pode auditar antes de contratar.

Mesma arquitetura de handoff das equipes pré-construídas, ajustada ao seu problema específico.

Teste grátis primeiro

Você pode testar tudo grátis por 3 dias no Teamly 5, sem cobrança até o dia 4.

Se você ficar, o preço é $29/mês para 5 agentes.

Barato o suficiente para que uma funcionalidade enviada pague o mês.

A conclusão

A diferença entre uma pilha de agentes e um pipeline é o handoff.

Quatro especialistas escrevendo em arquivos compartilhados, um orquestrador executando-os em ordem, cada estágio construindo sobre o anterior em vez de começar do zero.

Construa o Planejador e o Codificador primeiro e execute-os como uma cadeia de dois estágios. Assim que esse fluxo parecer sólido, adicione o Testador e o Revisor.

Quando todos os quatro estiverem conectados, você iniciará uma funcionalidade antes de dormir e lerá um veredito com seu café.

Para notas diárias sobre agentes de IA, vibe coding e configurações do Claude Code: https://t.me/zodchixquant 🧠