Vibe coding para restringir modelo e conta de IA para o squad

Quando Thiago montou um time de agentes para rodar em paralelo, ele partiu o pedido em 2 metades, nesta ordem: primeiro a liberdade sobre a forma do trabalho, depois a trava sobre o recurso. Quantos agentes e quantos workers, o agente escolhe. De qual família de modelo isso sai e de qual conta paga o consumo é debitado, quem decide é ele.

A sacada é dele, e mora na divisão entre as 2 metades. Está também no que veio depois: terminado o pedido, ele voltou e pediu ao agente a lista do que tinha sido usado em cada frente. Essa terceira parte é a que costuma ficar de fora, e sem ela as outras 2 são só texto no prompt.

O que ele deixou aberto

"você pode escolher quantos agentes você precisar, quantos workers você precisar. Beleza? Fica à vontade."

Quantos agentes e quantos workers é a parte que o agente decide melhor que você, porque depende do trabalho que ele tem na frente. Uma tarefa que se quebra em 6 pedaços independentes pede um número. Uma que tem dependência em série pede outro, menor, e às vezes pede 1 frente só. Você, escrevendo o prompt antes de qualquer coisa começar, não sabe em qual dos casos está. Fixar esse número é palpitar sobre execução com menos informação do que quem vai executar.

O que ele fechou: família de modelo e conta

"não esquece de usar apenas eh a família GPT, beleza?"

"Os modelos que você pode usar são esses."

"E você só pode usar também da conta [...]"

O nome da conta sai corrompido na legenda, então ele fica de fora aqui. Essas 2 travas são de outra natureza que a primeira. Nenhuma delas muda o que vai ser feito: o trabalho entregue é o mesmo com uma família de modelo ou com outra, e é o mesmo saindo de uma conta ou de outra. O que elas mudam é quem paga e quanto custa. São escolhas de orçamento fantasiadas de detalhe técnico, com cara de configuração e efeito de fatura.

O agente não tem como acertar isso sozinho. A resposta depende de contrato, de saldo, de desconto e de qual fatura você prefere engordar neste mês, coisas que existem fora do repositório e fora do prompt. Ele mantém mais de uma conta paga ao mesmo tempo, e é isso que transforma "de qual conta sai" em pergunta real. Quem opera com uma conta só não encara essa pergunta. Ele opera com várias, então ou responde ou deixa o agente responder por ele.

A conferência, que é a parte que mais importa

"Lista para mim quais são os agentes e quais modelos você usou em cada um."

Uma restrição que ninguém confere continua valendo como pedido educado. Ela vira limite quando alguém volta depois e olha. Ele voltou, e a lista veio com furo:

"Ai, tem um branco."

"Vou conferir, meu amigo."

A legenda não deixa claro o que estava faltando ali nem se ele resolveu. Dá para dizer só isto: ele pediu a lista por agente, a lista voltou com alguma coisa vazia, e ele foi verificar. O formato do pedido já carrega metade do valor. Perguntar "quais modelos você usou" devolve uma frase que soa bem. Pedir a lista por agente devolve uma tabela, e é na tabela que você enxerga o campo vazio.

2 fronteiras do mesmo builder, com falhas opostas

Ele já apareceu aqui fazendo o movimento contrário, quando resolveu dar permissão pontual ao agente sem virar regra. Lá ele alarga a fronteira no meio do caminho, liberando uma ação privilegiada que o agente não tinha, e o risco é a permissão sobreviver à intenção que a criou. Aqui ele estreita a fronteira antes de começar, e o que está em jogo é consumo. Foi o mesmo caminho de vibe coding para ia aprender com o motivo da rejeicao. O mesmo problema apareceu em vies do orquestrador de ia no vibe coding. Vale ver como isso terminou em whisper ia.

Por isso as 2 falham de maneiras diferentes. Permissão alargada falha por não expirar. Restrição estreitada falha por não ser conferida. A primeira pede um prazo, a segunda pede um extrato, e o extrato foi o que ele pediu naquela live.

Por que essa conta chegou agora

Enquanto uma pessoa trabalhava numa coisa de cada vez, gasto e esforço andavam juntos. Para consumir o dobro você tinha que trabalhar o dobro, e o próprio cansaço servia de teto. Com 5 ou 6 agentes disparados em paralelo por 1 frase, o teto sumiu. A mesma frase, escrita do mesmo jeito, custa valores diferentes conforme escolhas feitas dentro da execução, sem você ver: qual modelo cada agente pegou, quantos workers ele abriu, quantas vezes ele repetiu a tentativa.

A segunda metade do pedido dele existe por causa disso. No vibe coding, o que sai caro é decidido em lugares que você não olha, e o prompt é onde dá para chegar antes.

Minha análise, e aqui já não é ele falando

Restrição escrita no prompt não é mecanismo. Ela depende de o agente obedecer e da plataforma respeitar o que ele obedeceu. O controle que não falha mora do outro lado, na conta e na chave: se a chave só dá acesso ao que você está disposto a pagar, não sobra instrução para desobedecer. O prompt é a versão barata dessa mesma ideia, e serve enquanto ninguém precisar de garantia.

A conferência que ele fez é do tipo certo, e ainda assim é autorrelato. O agente dizendo quais modelos usou é a mesma classe de resposta que um "salvei". Vale mais quando bate com o extrato de consumo da conta do que quando bate só com a boa vontade de quem respondeu.

Restringir família de modelo cobra um preço que só aparece depois. Você troca capacidade por previsibilidade, e nem toda tarefa do time precisa do mesmo nível: revisar um texto curto e desenhar a estrutura de um fluxo inteiro não pedem a mesma coisa. A pergunta melhor, quando houver tempo de fazer, é quais papéis do time realmente precisam do modelo mais forte, em vez de uma trava igual para todos.

O pedido em 2 partes, na sua próxima delegação

Da próxima vez que você espalhar trabalho por várias frentes, escreva o pedido em 2 partes separadas e visíveis. A primeira diz o que o agente decide: quantas frentes, quantos workers, como dividir. A segunda diz o que você decide: de qual recurso ele pode consumir, com qual família de modelo e a partir de qual conta. Depois peça a lista do que foi usado, por agente, e compare com o consumo real da conta em vez de comparar só com a resposta dele. Esse fechamento é o hábito que falta na maior parte do vibe coding em time, e dá para ver as 2 metades do pedido sendo ditas em sequência ao assistir à live.