Melhor de três: ataque um problema difícil de três jeitos

Quando usar uma squad melhor de três?

Use quando a abordagem certa não é óbvia e errar o primeiro palpite sai caro. Em vez de conduzir um agente por três ideias seguidas, você recebe três implementações reais lado a lado e uma comparação que dá para conferir.

• Performance com uma meta numérica: latência, tamanho de bundle, memória.
• Bugs difíceis, com causa raiz incerta e várias correções plausíveis.
• Design em aberto, como o formato de uma API nova ou a estratégia de uma migração de dados.
• Não serve para trabalho que dá para dividir em partes. Para isso existe a squad de entregar uma feature.

Como montar a squad?

Abra Squads → Nova squad e escolha 3 tentativas, escolhe a melhor. O template já vem com um membro, "Resolve o objetivo inteiro de forma independente", com Quantos = 3, então as três tentativas usam o mesmo agente. Para misturar agentes, troque por três membros com essa mesma função, cada um com Quantos = 1.

Qual objetivo colar?

Dê uma meta que o líder consiga medir. Melhor de três só funciona se "melhor" for algo concreto: um benchmark, uma suíte de testes, um limite de tamanho.

Reduzir a latência p95 do checkout para menos de 300 ms.

Como medir
- pnpm bench checkout mostra p50/p95 contra o banco de fixtures local.
- Registrar a linha de base no branch atual antes de mudar qualquer coisa.

Restrições
- Sem novas dependências de runtime. Sem mudança de schema.
- Todos os testes de checkout existentes precisam passar.

No relatório, para cada tentativa
- p95 antes e depois, tamanho do diff, o que mudou e por quê.

As Instruções do líder do template já dizem "Dê a mesma tarefa para cada tentativa e deixe-os trabalhar de forma independente. Compare os resultados e recomende o melhor, explicando o porquê." Pode manter.

Quais limites definir?

Coloque 3 membros ao mesmo tempo, para as três tentativas começarem juntas, e 3 rodadas. Quase todo o trabalho acontece na primeira; o resto cobre um ajuste depois da sua resposta ou uma nova medição.

Teste no seu endpoint mais lento: três tentativas, uma recomendação.

Baixar o Tallos →

Como a execução acontece?

Esta é uma execução de exemplo. Os números de latência abaixo são ilustrativos; não são benchmarks de nenhum agente nem do Tallos.

1. 1

   O líder distribui

   Mesmo objetivo, três tentativas, três worktrees filhos novos. Ele informa o benchmark que cada tentativa precisa rodar.

2. 2

   Três tentativas em paralelo

   No exemplo: a tentativa 1 memoiza o cálculo de imposto (p95 341 ms), a 2 agrupa queries e adiciona cache (268 ms), a 3 faz as consultas de preço em paralelo (297 ms).

3. 3

   O líder compara

   Primeiro correção, depois testes, depois qualidade do diff, e só então o número. Só a tentativa 2 fica abaixo da meta.

4. 4

   Uma pergunta para você

   O cache da tentativa 2 guarda preços por 60 segundos. O líder pergunta se esse atraso é aceitável. Você responde: não, no máximo 10 segundos.

5. 5

   Ajustar e medir de novo

   O líder repassa sua resposta para a tentativa 2, que reduz o TTL e roda o benchmark de novo.

6. 6

   Relatório

   O líder recomenda a tentativa 2, com os motivos, e entrega o relatório com tallos squad report.

O que o líder pode te perguntar?

Numa melhor de três, o líder costuma perguntar sobre trade-offs que o benchmark não resolve. A execução mostra Precisa da sua resposta; você escolhe uma opção ou escreve a sua.

• "A tentativa 2 adiciona um cache de 60s. Preço desatualizado por 60 segundos é aceitável?"
• "As tentativas 1 e 3 estão a 5% uma da outra. Prefere o diff menor ou a mais rápida?"
• "A tentativa 3 muda a assinatura de uma função pública. Isso é permitido?"

O que você recebe no final?

• Relatório final: o que cada tentativa fez, qual o líder recomenda e por quê, e o que conferir. No exemplo: a tentativa 2 é a única abaixo de 300 ms, TTL do cache reduzido para 10s, tentativas 1 e 3 mantidas nos seus worktrees.
• Resultados por worktree: as três tentativas, cada uma com Ver alterações. A recomendada leva o selo Recomendado.
• Aceitar ou Descartar: Aceitar transforma a linha recomendada em Abrir para criar PR. Descartar mantém os worktrees, ou apaga os dos membros se você marcar essa opção.

A recomendação é a opinião do líder, não um merge. Abra qualquer tentativa, compare os diffs na revisão de diff e entregue a que te der mais confiança.

Quais variações funcionam bem?

• Force abordagens diferentes. Nas instruções do líder, cite três estratégias e dê uma para cada tentativa, para não receber três versões da mesma ideia.
• Um agente, três configurações. Mesmo agente com três modelos ou níveis de esforço, para ver o que o esforço extra realmente entrega no seu código.
• Explore, depois construa. Use a melhor de três para escolher a abordagem e depois passe a vencedora pela construir e revisar.

Quais são os erros mais comuns?

• Sem meta mensurável. Sem benchmark ou teste, o líder compara no gosto.
• Medir em paralelo. As três tentativas dividem a sua máquina, então os tempos interferem entre si. Peça ao líder para refazer as medições finais uma de cada vez.
• Menos de 3 membros ao mesmo tempo. As tentativas entram na fila em vez de correr juntas.
• Jogar fora as perdedoras. Uma tentativa que perdeu muitas vezes tem uma boa ideia. Leia antes de descartar.

Primeira squad? Comece por sua primeira squad e depois veja como funcionam as squads e os agentes em paralelo.