Vibe coding para montar squad de agentes: quem revisa não constrói

Thiago montou o time de agentes que vai tocar a agência de marketing dele escolhendo cada modelo por uma propriedade, não pela marca. Quem orquestra fica com o modelo mais forte que ele tem, e quem pesquisa fica com o de contexto maior. O revisor é o critério que quase ninguém aplica: tem que ser um modelo diferente do que construiu.

A cena leva poucos minutos de live, e ele vai narrando o motivo de cada escolha enquanto clica.

esse é um squad que vai ter o orquestrador que é o piloto

O piloto leva o modelo mais forte porque o trabalho dele é decidir

No papel de piloto ele pôs a variante Sol, da família Codex GPT, e o motivo saiu logo atrás: "eu vou usar o mais forte que eu tenho aqui", "porque é ele que vai pensar e orquestrar tudo".

O orquestrador é quem lê o pedido, quebra em tarefas, decide quem faz o quê e julga o que voltou. Se o elo mais fraco do time estiver justamente aí, todo o resto vai executar com capricho uma decisão ruim, e você recebe o erro multiplicado pelo número de agentes que obedeceram sem reclamar.

O scout leva contexto grande porque pesquisar é ler muita coisa de uma vez

Para o scout, o pesquisador do squad, ele escolheu o Gemini, e a justificativa é de novo uma propriedade do modelo: "que ele tem um contexto grande, ele consegue pesquisar".

O trabalho do scout é chegar carregado de material antes de qualquer linha ser escrita: o que já existe no repositório e o que a estratégia de marketing pede. Isso é leitura em volume, e leitura em volume esbarra em quanto cabe na janela. Um modelo excelente que precisa esquecer metade do que leu para continuar lendo devolve uma pesquisa com buracos, e você não vai saber onde eles estão.

No vibe coding, quem revisa não pode ser quem construiu

O builder do squad é o Cursor. Para revisar, ele fez questão de pôr outro: a variante Terra, também da família Codex GPT, com uma razão bem pé no chão, já que é o Cursor que está construindo, "eu coloco o Terra para verificar, né, se ele fez alguma coisa errada".

Um modelo que revisa o próprio trabalho revisa com a mesma leitura que produziu o erro. Ele já decidiu que aquela abordagem era a certa, já resolveu as ambiguidades do pedido de um jeito só, e vai passar o pente fino dentro dessas mesmas escolhas. O que ele não enxergou na ida dificilmente aparece na volta, e o relatório volta dizendo que está tudo certo.

Um modelo diferente chega sem esse compromisso. Ele tem manias próprias e erra em outros lugares, e é a diferença entre os dois que faz o segundo par de olhos render alguma coisa. No vibe coding a tentação de pular essa etapa é grande, porque o builder sempre termina anunciando que ficou pronto. É a mesma régua de vibe coding com agente que implementa separado do agente que valida: a separação só vale se as duas pontas forem de fato independentes.

Desenhar o squad é uma coisa, conseguir subir é outra

Nada disso subiu de primeira. Ele clicou em iniciar e não veio nada: "Simplesmente não abriu". Na tentativa seguinte, os modelos que ele tinha escolhido para cada papel não pegaram e os painéis nasceram todos com o mesmo modelo, que não era o desenho dele. Depois um painel fechou sozinho no meio do caminho, na mesma live em que ele descobriu que Ctrl+C fecha o painel do agente em vez de copiar.

Ele foi contornando, reabrindo, trocando a ordem das coisas, até sair: "eu abri um squad aqui no overclock e pedi para ele criar um plano de verdade". A live não deixa claro se o squad que finalmente subiu ficou com a distribuição que ele tinha desenhado na tela. Essa distância entre o time que você projeta e o time que sobe é a experiência real de quem monta agente hoje, e ela merece entrar na sua estimativa de tempo. Para que o que sobe de fato corresponda ao que você desenhou, uma etapa de QA automático com uma segunda LLM pode evitar surpresas depois.

O elenco vence a validade, a régua não

Nenhum dos critérios dele depende de qual modelo estava melhor naquela semana. Mais forte para pensar e contexto maior para pesquisar são propriedades do modelo, e a regra do revisor é mais durável ainda, porque só pede que ele seja outro.

É por isso que este post não cita versão de modelo nenhuma. O nome que está no seu piloto hoje vai estar errado daqui a algumas semanas, enquanto a régua que colocou ele lá continua servindo.

Quando você for montar o seu, faça a pergunta que ele fez em voz alta, papel por papel: o que esse aqui precisa ter para dar conta do serviço? Se a única resposta que aparecer for o nome de um modelo, você ainda está escolhendo por preferência. E antes de mandar rodar, confira a peça que falta em quase todo squad, que é o revisor ser um modelo diferente do que escreveu. Essa régua é a parte do vibe coding que a ferramenta não monta no seu lugar. Mas tem outra: antes de desenhar o squad, responda um questionário de negócio para saber quantos clientes você aguenta e quanto caixa precisa entrar por mês. E tem mais: construa uma ferramenta de foco que mede além do tempo, para saber onde a tarde se perde. E quando o agente devolver o plano desse squad, leia tudo antes de disparar os pedidos. O mesmo problema apareceu em vibe coding para restringir modelo e conta de ia para o squad.

Vale assistir à live para ver a distribuição dos papéis acontecendo, com os travamentos no meio.