O viés do orquestrador de IA no vibe coding: o último modelo testado

Peça ao orquestrador para testar um modelo em uma tarefa e talvez você tenha escolhido o modelo das tarefas seguintes também. O pedido de teste fica na conversa e continua pesando depois que o teste terminou, então a escolha de modelo precisa ser reafirmada a cada tarefa, em vez de assumida.

Guilherme Saraiva descreveu esse puxão no meio da live, com vários agentes trabalhando em paralelo no sistema de RPG que ele está construindo. O pedido dele tinha escopo estreito, testar um modelo "em alguma dessas tarefas aqui", uma entre as que já estavam na fila. Mais tarde, olhando a distribuição, ele contou o que vinha percebendo:

Eu sinto que eu peço para ele fazer assim, ó. Eh, testa esse aqui.

Depois de um pedido desses, na leitura dele, o orquestrador segue mandando tudo para aquele modelo sem ninguém pedir de novo.

O pedido de teste não morre junto com a tarefa

O que ele digitou foi "faz o teste", com o modelo nomeado e o alvo limitado a uma das tarefas em andamento. A pergunta era pontual: como esse modelo se sai neste código.

Só que esse pedido entra na mesma conversa que distribui o trabalho. Ele não chega marcado como experimento, chega como a informação mais recente sobre qual modelo você quer ver rodando. Daí em diante o orquestrador tem um motivo para continuar escolhendo aquele, e sobra para você lembrar de dizer o contrário.

A regra dele de qual modelo usar em cada tipo de trabalho já estava escrita antes disso. O teste não estava nela, e foi o modelo do teste que ele sentiu voltando.

O "eu sinto que" aparece 2 vezes

Ele repetiu a ressalva 2 vezes. Abriu com "eu sinto que" e, algumas frases depois, disse de novo: "Eu sinto que eu falo assim". Ele não mediu isso, chamou de sensação. Quem está falando é um builder que passa o dia distribuindo tarefa entre agentes, relatando o que percebe no próprio uso.

Você tem o mesmo histórico na sua máquina para conferir. Abra a última rodada de vibe coding, ache o pedido em que você mandou testar um modelo e leia qual modelo executou as tarefas que vieram depois daquela. Se o modelo do teste aparecer nas seguintes sem você ter pedido, o padrão está no seu histórico também. O mesmo problema apareceu em vibe coding para restringir modelo e conta de ia para o squad. Foi o mesmo caminho de glm no vibe coding. Isso aparece também em vicio em ia.

Por que esse viés passa batido no vibe coding com agentes em paralelo

Enquanto ele falava, um dos agentes estava há 19 minutos na mesma tarefa, e ele comentou que já tinha visto código passar dos 40 minutos. Com tarefas desse tamanho rodando ao mesmo tempo, ninguém fica olhando qual modelo pegou o quê, você olha o resultado quando ele chega.

Em outro momento ele reparou num trabalho que nem tinha acompanhado: "Não entendi que que é esse menu de rolagem aqui", e deixou seguir, "mas tá bom, vai rodando". Foi por isso que ele mandou o orquestrador reportar: "sempre me fala o código do trabalho que tá rodando isso e o pen que tá fazendo isso". Depois disso, cada resposta trazia o identificador do trabalho e o agente que o executou. Vale ver como isso aparece também em crm open source.

Reafirme o modelo dentro do próprio pedido

Escreva o modelo no pedido, toda vez, junto do que a tarefa tem que fazer. Quando o pedido for um teste, diga o alvo e o fim do teste na mesma frase, algo como testar naquela tarefa e voltar ao critério anterior depois. Peça também o relatório de execução do jeito que ele pediu, com o código do trabalho e o agente que executou, porque sem isso você não sabe quem executou o quê. Vale ver como isso aparece também em teste de custo de modelo no vibe coding.

Construir com a tela aberta e dizer o palpite em voz alta antes de ter prova é o que o movimento cobra de quem constrói em público, e está escrito nas leis. Dá para assistir à live e ver o momento em que ele descreve o padrão com os agentes ainda rodando atrás.