Vibe coding para economizar chamada de API: fale tudo de uma vez

No meio da leitura de um plano longo que o agente tinha devolvido, Thiago parou de despachar pedido. Ele ia descendo o documento item por item, e a cada trecho encontrava mais uma coisa para mandar: aqui dava para virar checklist, ali dava para criar um agente. Em vez de disparar uma mensagem por achado, ele decidiu terminar a leitura antes.

Vamos continuar lendo porque às vezes tem mais coisa, aí eu não fico mandando um monte de requisição

Depois de ler tudo, juntou os achados e mandou de uma vez. O nome que ele deu para o hábito, ali na live, foi falar "numa pancada". O gesto é gratuito: nada para instalar, nenhuma configuração nova. O ganho inteiro vem de segurar o dedo até a última linha do que você está lendo.

Por que a mensagem seguinte sai mais cara que a anterior

Uma conversa com agente não é uma sequência de perguntas independentes. Cada rodada nova reenvia o histórico acumulado, porque é assim que o modelo responde sabendo o que já foi dito. Quando você pica um mesmo pedido em várias mensagens, o mesmo contexto é processado de novo a cada rodada, e ele engorda no caminho, já que agora carrega também as respostas anteriores. Isso aparece também em vibe coding no modo de planejamento para economizar contexto.

Ele resumiu isso do jeito dele para quem estava assistindo:

você gasta uma requisição só, ele já pensa tudo, já te responde

A parte que costuma sumir quando alguém repassa essa dica vem logo depois. Ele disse que assim "economiza chamada API, economiza token" e emendou de onde tirou a conclusão: "pelo menos é isso que eu vejo aqui". É o que ele observa no acompanhamento do próprio uso, sem medição publicada e sem número na tela. Vale como pista de quem roda isso todo dia, com o peso que uma pista tem. O mesmo cuidado com chamada paga aparece também em vibe coding para confirmar antes de acao que gera custo. O mesmo problema apareceu em api gratuita. O mesmo problema apareceu em api instagram.

Juntar o pedido também muda a resposta, e não só a conta. Com tudo na mesma mensagem, o agente vê o conjunto: ele percebe que um item já resolve o outro, ou avisa que um pedido contradiz o vizinho antes de executar os dois. Picado, ele responde o primeiro sem saber que existe um último, e você recebe uma pilha de respostas que não conversam entre si.

A exceção que ele mesmo declarou, e ela não é detalhe

No mesmo fôlego, ele abriu a porta de saída: vale falar tudo de uma vez "a não ser que você esteja refatorando alguma coisa", ou "consertando algum bug". Essa ressalva é o que separa quem entendeu o mecanismo de quem decorou uma regra.

Refatorar e caçar bug têm uma característica em comum. O passo seguinte depende do que voltou do passo anterior. Você pede para renomear uma camada, olha o que quebrou e só então decide o que fazer com o que quebrou. Você pede o log, lê o log, e a próxima pergunta nasce do log. Não existe pacote fechado de instruções esperando para ser escrito, porque metade das instruções ainda não foi decidida por você.

Juntar tudo numa mensagem só nesse cenário é pedir para o agente adivinhar. Ele supõe qual era o erro e supõe o que ia acontecer depois da primeira mudança, depois executa em cima dessas suposições. Uma resposta longa construída sobre palpite sai mais cara que as idas e voltas que você evitou, porque agora você paga de novo para desfazer o que ela fez. Vale ver como isso terminou em vibe coding para calcular custo real de api de video antes de usar.

O caso dele era o oposto. Ele estava lendo um plano pronto, um documento parado que não muda enquanto ele lê. Todos os pedidos já estavam decididos quando a leitura acabou, e nenhum deles dependia da resposta do anterior. Material assim é feito para ir junto.

A régua que você aplica no seu vibe coding

Antes de apertar enter, a pergunta é uma só: o que eu tenho para dizer já está todo decidido, ou depende do que voltar. Se está decidido, junte. Se depende, mande um passo e espere.

Isso resolve boa parte do desperdício em vibe coding, porque a maioria das idas e voltas não vem de dependência real. Vem da ansiedade de mandar assim que se pensa numa coisa, já que escrever é mais fácil do que segurar a ideia até o fim da página. Várias mensagens depois, o que você tinha era um pedido só, escrito em pedaços, e o agente respondeu cada pedaço achando que era o assunto inteiro.

O mesmo raciocínio de evitar ida e volta desnecessária reaparece um nível acima, quando você vai cortar custo separando as partes de um sistema.

Para amanhã, sem mudar nada no seu setup: quando o agente devolver um plano ou uma revisão longa, leia até o fim antes de responder qualquer coisa. Vá anotando os pedidos em outro lugar, um bloco de notas resolve. No fim da leitura você tem uma lista, e a lista vira uma mensagem. Segurar o dedo enquanto lê não custa nada, e é uma das poucas coisas em vibe coding que melhoram o custo e a qualidade da resposta ao mesmo tempo.

Vale assistir à live para ver o momento como ele aconteceu, no meio da leitura do plano, com Thiago construindo em público no Overclock a agência de marketing com IA que está montando.