"O pedido que economiza metade dos seus créditos"

"Gastou 5 mil reais em Lovable e GPT/Codex fritando na ideia de fazer um sistema na empresa sem contratar um profissional, e no fim foi tudo pro lixo."

É de um brasileiro num fórum, contando a conversa que teve com um conhecido. E tem outra, do mesmo tipo de fórum, que explica pra onde o dinheiro vai:

"No modo normal, eu teria levado 10 horas codando e 1 hora testando e corrigindo erros. Com vibe coding, levei 1 hora codando e 10 horas testando e corrigindo erros."

São dois relatos, não estatística. Mas eu vejo a mesma proporção invertida em quase todo projeto que chega em mim, e ela tem uma causa que quase ninguém aponta: não é a IA que é cara. É o pedido que deixa ela adivinhar. Cada adivinhação errada é uma rodada, e cada rodada é crédito. Este post é o molde de seis linhas que eu uso, e o mesmo pedido escrito do jeito ruim e do jeito bom, lado a lado.

O pedido que todo mundo faz primeiro

O primeiro pedido de quem começa é quase sempre uma linha: "faz uma página de agendamento". "Cria um sistema de orçamentos". "Quero um controle de alunos".

E a IA faz. Isso é o problema: ela entrega uma coisa que funciona e é diferente do que você imaginava. Você imaginava horário de trinta minutos; ela fez de uma hora. Você imaginava que o cliente escolhe o profissional; ela não perguntou e escolheu por ele. Aí você pede pra mudar o horário, ela muda e mexe no calendário. Pede pra devolver o calendário, ela devolve e quebra o botão de confirmar. Três rodadas depois, você gastou o triplo pra chegar no que uma frase a mais teria dito no começo.

Não é burrice sua. As ferramentas foram vendidas com o verbo errado: "descreva a sua ideia". Ideia não é pedido. Ideia é o que você tem na cabeça; pedido é o que está escrito. Tudo que está na sua cabeça e não está no texto, a IA preenche com a média do que ela viu na internet, e a média nunca é o seu negócio.

Um leitor de fórum brasileiro escreveu a frase que enterra a ilusão do outro lado:

"Não acredite no milagre de definir tudo e colocar para criar tudo esperando dar certo. Você terá de abrir, revisar, criticar... É quase uma troca."

Ele está certo, e é importante você não ler este post como "prompt mágico". Especificação não elimina a revisão. Ela encolhe a revisão: quanto mais claro o pedido, menor a distância entre o que voltou e o que você queria, e menos rodadas você paga pra fechar essa distância. É uma troca mesmo: você gasta dez minutos escrevendo pra não gastar uma tarde corrigindo.

Escrever pedido virou uma habilidade

A tese do post, com todas as letras: escrever especificação virou uma habilidade, e é a que mais economiza dinheiro de quem constrói com IA. Mais que escolher ferramenta, mais que escolher qual IA usar.

As próprias plataformas já dizem isso na documentação. A do Replit recomenda, antes de pedir, "definir exatamente o que você precisa: formatos de saída, restrições, casos de borda" (as entradas estranhas que o usuário vai fazer), e planejar as telas e os fluxos antes do primeiro pedido. A do Lovable manda dizer "o que mudar e o que deixar como está", e pedir uma mudança significativa por vez em vez de páginas inteiras. Não é dica de blog; é o fabricante. O que nenhuma delas te dá é um molde que caiba numa folha. Este é o meu.

O molde, em seis linhas

Toda funcionalidade que eu peço, pra IA ou pra programador, tem estas seis linhas, nesta ordem.

1. O que o usuário vê. A tela, descrita como você descreveria pra alguém no telefone. Quantos campos, quais, o que está escrito no botão. Se tem lista, o que aparece em cada linha.

2. O que ele faz. A ação. Preenche, escolhe, clica, arrasta. Uma ação principal por pedido.

3. O que acontece depois. O resultado visível e o invisível. Visível: pra que tela vai, que mensagem aparece. Invisível: o que é guardado e onde. Qual tabela, quais campos. Se você não sabe o nome da tabela, escreva "na lista de agendamentos, junto com nome, telefone, data e hora"; a IA traduz.

4. O que NÃO pode mudar. A cerca. Tudo que já funciona e que este pedido não tem licença pra tocar: o login, o cálculo do total, a tela do cliente. Você já viu o que acontece sem essa linha: conserta uma coisa e quebra outra, e a quebra não está onde você olha. Uma nuance que a documentação do Replit levanta e que eu concordo: escreva a cerca como afirmação, "mantenha o login exatamente como está", em vez de uma lista de "não faça". O que você quer é declarar a fronteira, não dar ordem negativa.

5. Como eu sei que acabou. A frase verificável: "vou saber que está pronto quando eu, fazendo X, vir Y". Escrita antes, não depois. Sem ela, "pronto" é a IA dizendo que está pronto.

6. O que fazer quando der erro. O que o usuário vê se o horário já foi ocupado, se o telefone está em branco, se a internet caiu no meio. Não precisa de todos os casos; precisa dos dois ou três que você já sabe que vão acontecer. Se você não escrever, a IA vai escolher entre "não fazer nada" e "mostrar erro em inglês", e vai escolher errado.

Seis linhas. Dez minutos. Se você fizer só a 4 e a 5, já corta a maior parte das rodadas que hoje você paga.

O mesmo pedido, dos dois jeitos

Uma funcionalidade só: o cliente marca horário numa assistência técnica de celular. É o tipo de mini app interno que um leitor de fórum descreveu ter feito sozinho ("o sistema me atende bem para a demanda atual"), e é exatamente o pedido que dá errado quando vem em uma linha.

O pedido ruim:

Faz uma página de agendamento pra minha assistência técnica.

Tudo que a IA vai decidir sozinha: duração do horário, dias de funcionamento, o que acontece se dois marcarem o mesmo horário, se pede telefone, onde salva, o que faz com a tela de orçamentos que já existe. Cada decisão diferente da sua é uma rodada de correção, com crédito.

O pedido bom:

FUNCIONALIDADE: cliente marca horário de atendimento

1. O que o usuário vê
   Uma tela com: nome, telefone (obrigatório), modelo do
   celular, e um calendário com os horários livres. Horários
   de 30 min, das 9h às 18h, de segunda a sábado. Botão
   "Confirmar horário".

2. O que ele faz
   Preenche os campos, escolhe um horário livre e clica em
   confirmar.

3. O que acontece depois
   Aparece "Horário confirmado: sábado, 14h" e o horário some
   da lista de livres. É guardado na lista de agendamentos com
   nome, telefone, modelo, data, hora e a data em que foi
   marcado.

4. O que NÃO pode mudar
   Mantenha a tela de orçamentos e o login exatamente como
   estão. Não crie uma tabela nova se já existir uma de
   agendamentos; use a que existe.

5. Como eu sei que acabou
   Vou saber que está pronto quando, marcando o sábado 14h
   num navegador e abrindo o app em outro, o sábado 14h não
   aparecer mais como livre no segundo.

6. O que fazer quando der erro
   Telefone em branco: mensagem "Informe o telefone", sem
   sair da tela. Horário que acabou de ser ocupado por outra
   pessoa: mensagem "Esse horário acabou de ser preenchido,
   escolha outro" e a lista atualiza.

Antes de mexer em qualquer coisa: me diga o que você vai
alterar e em quais arquivos. Se precisar tocar em algo fora
disso, pare e me pergunte.

É mais longo. Leva dez minutos. E repare que não tem uma palavra de programação nele. É o que você diria pra um funcionário novo no balcão. A diferença é que, escrito assim, a IA não precisa adivinhar nada que importa, e cada coisa que ela não adivinha é uma rodada que você não paga.

Por que eu digo "metade"

Honestidade sobre o número do título: eu não medi. Não existe estudo que eu possa citar dizendo que especificação corta 50% do crédito, e desconfie de quem citar. O que eu tenho é o padrão: em projeto que chega em mim com o pedido em uma linha, a maior parte das rodadas não é funcionalidade nova, é correção de coisa que a IA decidiu diferente do dono. Com seis linhas, essas rodadas somem quase inteiras. Se é metade ou um terço depende do seu app. A direção não depende.

Tem uma condição pra isso funcionar, e ela é a mesma da regra das duas tentativas: uma funcionalidade por pedido. O molde de seis linhas pra três funcionalidades juntas vira dezoito linhas que a IA vai misturar, e aí você não sabe qual mudança causou qual problema. Um molde, uma funcionalidade, uma rodada.

O que fazer hoje

Pegue a próxima coisa que você ia pedir pra IA. Antes de abrir o chat, escreva as seis linhas num bloco de notas e cole no pedido. Guarde o arquivo: ele vira a sua documentação sem você perceber. Daqui a três meses, quando alguém perguntar "como funciona o agendamento?", a resposta está lá, em português, escrita por você.

E note o que este molde é e o que ele não é. Ele é a parte de pedir direito, que na sequência que eu uso é a segunda etapa: definir o problema, ordenar a construção em fatia pequena, não aceitar sem prova, operar. O pedido bom não impede a IA de quebrar o que estava fora da cerca, e por isso existe o ponto de retorno. Não prova que a regra está certa, e por isso existe o teste. Não coloca no ar, não protege o dado, não diz quanto custa por mês. É uma parede de várias, e elas têm ordem.

Mas é a parede mais barata de atravessar, porque o material é uma folha e dez minutos. Comece por ela hoje. O crédito que sobrar já é seu.

Fontes

• Replit — Effective prompting ("define exactly what you need: output formats, constraints, edge cases"; planejar telas e fluxos antes; preferir afirmação a negação): https://docs.replit.com/tutorials/effective-prompting
• Lovable — Prompting best practices ("say what to change and what to leave alone"; uma mudança significativa por vez): https://docs.lovable.dev/prompting/prompting-one