Vibe coding para escolher modelo de IA por tarefa: backend e frontend

Quando um orquestrador dispara vários agentes de uma vez, alguém decidiu qual modelo cada um deles ia rodar. Se não foi você, foi a configuração que já estava na conta. Olhar quem ele chamou sozinho e escrever a regra por tipo de tarefa é trabalho de uma frase, e dá para fazer com os agentes ainda rodando.

Guilherme Saraiva fez essa correção ao vivo. Ele tinha acabado de plugar uma skill para o orquestrador parar de fazer o serviço e passar a distribuir:

Não quero que você fique executando coisas.

Depois ficou olhando a distribuição chegar na tela. Vieram 3 agentes do mesmo modelo, um atrás do outro.

O padrão que veio de fábrica decide o seu vibe coding por você

Antes de trocar qualquer coisa, ele desconfiou que o modelo tinha sido chamado por estar marcado como padrão na conta dele. Em vez de supor, foi perguntar para o próprio orquestrador:

Por que que tu chama?

Vamos, vamos conversar com ele, né, mano?

A resposta confirmou o palpite. O padrão estava configurado daquele jeito, então a repetição não dizia nada sobre as tarefas, só sobre o arquivo de configuração. Quem monta vibe coding com vários agentes em paralelo escreve a tarefa, confere o resultado e quase nunca abre o campo que define quem executou. É assim que o vibe coding funciona na prática.

Caro para aquele trabalho é um julgamento seu, feito ali

Com os agentes rodando, ele concluiu que aquele modelo estava caro demais para aquele trabalho. Foi julgamento do momento, com o consumo subindo na tela enquanto ele falava:

Já foi 140.000 tokens aqui.

O painel nem mostrava tudo, porque o consumo de um dos modelos não aparecia integrado ali, e esse ele acompanhava por fora. Também não matou nada no meio: esperou os agentes que já estavam trabalhando terminarem para só então mexer na configuração. Vale ver como isso aparece também em teste de custo de modelo no vibe coding. Isso aparece também em vibe coding para importar produto por sitemap ou planilha. Vale ver como isso terminou em vibe coding para escolher modelo pela persona e nao pelo spec.

Backend de um lado, frontend do outro, escrito na mão

A regra que ele ditou separa por tipo de tarefa, com o modelo escrito na frente de cada tipo. Trabalho de backend vai para o Grok 4.5. Trabalho de frontend vai para outros dois modelos. Junto disso ele anotou a quais provedores tinha acesso e o orquestrador ainda não conseguia usar, para não repetir a pergunta depois.

Escrevendo, ele errou a palavra backend e corrigiu na hora, e no meio da própria frase esqueceu o nome do segundo modelo de frontend:

Qual que era o outro que eu falei?

Lembrou uma linha depois e terminou a regra, ditada em português enquanto os agentes trabalhavam, dizendo quem faz o quê. Mas o viés do orquestrador pode sabotar essa regra se você não reafirmá-la a cada tarefa: o viés do orquestrador de IA trata exatamente como um pedido de teste de modelo continua pesando nas decisões depois que o teste terminou. Vale ver como isso aparece também em cache de contexto no vibe coding. Isso aparece também em vibe coding para nao deixar contexto antigo escolher o modelo. Isso aparece também em whisper ia. O mesmo problema apareceu em vicio em ia.

Depois da regra, dá para ver o orquestrador escolhendo

Pouco depois ele reparou num agente Fable que estava rodando. Aquele agente pegou uma parte de código de backend e, em vez de resolver ali mesmo, chamou um Grok para o pedaço. A instrução tinha chegado até a decisão que um agente toma sobre outro. O critério dele para essa parte é gosto declarado, ele se sente melhor com o código de backend que o Grok escreve.

Na tarefa seguinte, de frontend, o orquestrador tinha 3 opções para escolher, e ele ficou olhando qual sairia:

A tarefa que eu pedi agora é de front, né? Vamos ver quem que ele vai mandar fazer isso aqui.

A parte do site que ele queria ver mudando ficou com um agente Fable. Ele notou também uma inércia que vale anotar junto da regra:

ele é muito travado em relação ao que ficou pendente da última vez que ele usou

Peça para testar um modelo específico numa tarefa e o orquestrador tende a mandar tudo para lá nas próximas. A regra por tipo de trabalho é o que segura isso, porque o critério passa a ser a tarefa, e não o que rodou por último.

O que fazer antes da sua próxima leva de agentes

Abra o histórico da última rodada de vibe coding e leia uma coluna só, qual modelo executou cada tarefa. Se as linhas estiverem todas iguais, quem escolheu foi o arquivo de configuração. Depois escreva a regra do jeito que ele escreveu, uma linha por tipo de trabalho, com o motivo do lado, e mande junto do próximo pedido. Vale ver como isso aparece também em como usar notebooklm.

Ditar esse critério no ar, com o consumo aberto na tela e o nome de um dos modelos escapando no meio da frase, é o que as leis do movimento cobram de quem constrói em público. Vale ver como isso aparece também em crm open source. Dá para assistir à live e ver a leva de agentes iguais chegando antes da regra e a distribuição mudando depois.