Vibe coding para distinguir falha de worker redundante de bug real

Quando o agente pergunta se você quer abrir mais workers para terminar mais rápido, a resposta parece óbvia, e você autoriza. O que ninguém avisa é que boa parte das falhas que vão aparecer daqui a pouco não vem do seu código. Vem da sobreposição entre os workers que você acabou de ligar, e ela chega junto com a velocidade que você pediu.

Thiago autorizou exatamente isso na live de 4 de agosto, fechando as pendências do plano do dia. O agente perguntou se podia usar mais workers, ele liberou, e logo o painel reportava coisa quebrada mais rápido do que ele conseguia acompanhar. Ele disse isso com todas as letras:

"eu tô aceitando várias permissões aqui e não sei como que tá [...] essa parada, porque você tá falando para mim que várias coisas não tá dando certo aí"

O estrago desse estado é a perda de leitura: chega uma lista de erro e você não consegue dizer qual deles é seu.

O custo do paralelismo que só aparece depois de ligado

Um custo do paralelismo se paga antes de delegar. Ele está em planejar antes de delegar, onde outro builder segura os workers até o escopo estar fechado, porque delegar em cima de escopo instável multiplica retrabalho. O outro custo só chega depois, com o motor já ligado: é o ruído que o paralelismo produz mesmo com escopo bom, e ele aparece na sua tela como falha.

Sem triagem, esse ruído gera o pior tipo de trabalho que existe. Você manda o agente consertar coisa que não está quebrada, queima ciclo e ainda mexe em código que estava bom. Ignorar tudo também cobra caro, porque quem se acostuma a passar por cima da lista para de enxergar o erro que importa, e um defeito real acaba passando batido porque virou paisagem.

O relatório que separou ruído de defeito

Thiago parou, pediu o fechamento e pediu o status. A resposta que ele recebeu é o modelo a copiar:

"Fechei os três panes restantes. A missão foi marcada como concluída."

"Nenhum push foi feito. As falhas mencionadas eram de work[er]s redundantes, não da implementação."

"Não houve publicação nem alteração externa."

"Os únicos erros [restantes] são dois problemas pré-existentes em testes fora da home."

3 panes fechados, nada publicado, as falhas atribuídas à redundância entre workers, e 2 erros reais que já existiam antes da rodada. O painel continuava igual; o que mudou foi que agora dava para decidir o que fazer com ele.

As perguntas certas depois de uma rodada de vibe coding

Repare no que esse status responde, porque é uma lista de perguntas certas. Ele começa pelo que saiu da máquina, e essa é a pergunta mais importante depois de uma rodada de agente. "Deu certo?" aceita qualquer resposta e não muda o que você faz em seguida. "O que mudou fora daqui?" tem consequência: enquanto não houve push, publicação nem alteração externa, tudo o que aconteceu na última hora é reversível e pode esperar até amanhã de manhã.

Depois ele diz de onde vieram as falhas, e atribuí-las à redundância, não à implementação, transforma uma tela cheia de vermelho numa lista de nada a fazer. Por último ele separa erro novo de erro velho: sobraram 2 problemas pré-existentes, em testes fora da parte que estava sendo mexida. Sem essa separação você herda como seu um defeito que já estava lá antes de você abrir o editor, e passa a tarde caçando causa numa mudança que não causou nada. É esse tipo de triagem que sustenta o vibe coding quando o agente trabalha em paralelo e você só vê o resultado.

Um relatório organizado ainda é uma afirmação

O relatório vem do próprio agente que fez o trabalho, então ele é parte interessada, e boa estrutura não é evidência. O que salva esse aqui é que as 3 respostas dele podem ser checadas por fora, sem depender dele. Você olha o repositório remoto e vê se existe commit novo publicado. Você roda a suíte de testes no commit anterior e vê se aqueles 2 erros já estavam lá. Um relatório que afirma coisa verificável é melhor exatamente por isso, e a checagem custa minutos.

O que fazer na próxima lista de falhas

Quando uma rodada com vários workers devolver uma lista de coisas quebradas, não comece consertando. Peça o fechamento dos workers ainda abertos e um status que diga o que saiu da sua máquina (push, deploy, publicação), quais falhas vieram de redundância entre workers e quais vieram da implementação, e quais erros já existiam antes da rodada. Confira as 2 afirmações fáceis, o log do remoto e a suíte no commit anterior, e só então abra a fila de conserto. Ela vai ser bem menor que a lista original, e vai ser toda de coisa sua. Dá para assistir à live e ver essa passagem inteira, do painel virando barulho até o status devolver o chão.