Prompts de código que funcionam: 7 padrões que uso todo dia

Existe uma frustração muito comum com IA para programar: a pessoa testa, recebe código ruim, conclui que "a IA não serve pro meu caso" e abandona. Na maioria das vezes que acompanhei isso de perto, o problema não era o modelo. Era o pedido.

"Prompt engineering" virou uma palavra pomposa para algo simples: descrever a tarefa com a mesma precisão que você usaria para pedir a um colega que não conhece o projeto. É isso. Não tem mágica nem palavra secreta. Mas tem padrão — formatos de pedido que funcionam consistentemente. Estes são os sete que eu uso.

1. O padrão "contexto, tarefa, restrição"

É a base de tudo o resto. Todo pedido bom tem três partes, nessa ordem:

• Contexto: o código real, a stack, as versões.
• Tarefa: o que você quer, em uma frase, com verbo.
• Restrição: o que não pode mudar.

Compare. Ruim: "otimiza essa função". Bom: "Esta função (colada abaixo) roda a cada tecla digitada na busca e está travando a interface em listas de mais de 500 itens. Reduza o custo por chamada. Restrição: a assinatura da função não pode mudar, porque três componentes a chamam."

O segundo pedido não é mais longo por perfeccionismo. Cada parte remove uma decisão que a IA teria que chutar — e cada chute é uma chance de o resultado não servir.

2. O padrão "me dê três opções, com trade-off"

Quando você ainda não decidiu o caminho, pedir uma solução é desperdiçar a maior força da IA: ela conhece muitas abordagens. Peça: "me dê três formas de resolver isso, da mais simples à mais robusta, e para cada uma: quando vale a pena e qual é o custo."

O ganho é duplo. Você vê alternativas que não tinha considerado, e — mais importante — você continua sendo quem decide. Aceitar a primeira sugestão de uma IA é como aceitar a primeira ideia de uma reunião de brainstorm: às vezes é a melhor, mas você nunca vai saber.

Pedir uma resposta te dá código. Pedir opções com trade-off te dá critério — e critério você reusa.

3. O padrão "explique antes de escrever"

Para tarefas complexas, peça o plano antes do código: "antes de escrever qualquer linha, me explique em passos o que você vai fazer e por quê. Só escreva o código depois que eu confirmar."

Isso resolve o pior desperdício de tempo com IA: receber 200 linhas construídas em cima de um mal-entendido que teria sido pego na primeira frase. Corrigir um plano custa uma frase. Corrigir uma implementação inteira custa a implementação inteira.

Tem um efeito colateral bom: modelos costumam produzir código melhor depois de explicitar o raciocínio. Ao escrever o plano, o modelo "se compromete" com uma abordagem coerente em vez de improvisar a cada linha.

4. O padrão "aja como o cético"

Este é para revisar, não para criar. Depois de ter o código (seu ou dela), peça: "aja como um revisor sênior que precisa achar problema. O que quebra aqui? Liste em ordem de gravidade e não seja gentil."

A instrução de não ser gentil não é dramática, é funcional. Modelos têm um viés forte de concordar com o que você mostrou — pergunte "está bom?" e você quase sempre ouve que sim. Dar a ele o papel de crítico muda a resposta de forma bem perceptível.

Variações úteis: "que entrada faz isso explodir?", "o que acontece se essa chamada de rede falhar no meio?", "que suposição esse código faz sobre os dados que pode não ser verdade?".

5. O padrão "exemplo de entrada e saída"

Para qualquer transformação de dados — parse, formatação, conversão — descrever é pior do que mostrar. Em vez de explicar a regra em português, dê dois ou três exemplos concretos:

"Escreva a função que faz esta conversão:
entrada "2026-07-14T15:30:00Z" → saída "14 de julho, 15h30"
entrada "2026-01-02T09:05:00Z" → saída "2 de janeiro, 09h05""

Os exemplos carregam, sem você perceber, todas as decisões chatas: mês por extenso e minúsculo, dia sem zero à esquerda, hora com zero à esquerda, o "h" em vez de dois-pontos. Descrever tudo isso em prosa levaria um parágrafo e ainda esqueceria algo.

6. O padrão "não me dê o arquivo inteiro"

Um dos comportamentos mais irritantes é pedir uma mudança pequena e receber o arquivo todo reescrito — com mudanças que você não pediu enfiadas no meio. A instrução que resolve: "me mostre só o trecho que muda, com três linhas de contexto antes e depois. Não reescreva o resto."

Isso não é só conforto. Diff pequeno é diff revisável. Quando o modelo devolve 300 linhas para uma mudança de 4, você vai ler por alto — e é exatamente aí que passa a alteração silenciosa que quebra outra coisa.

7. O padrão "primeiro o teste"

Inverta a ordem: "escreva primeiro os testes que descrevem o comportamento esperado, incluindo os casos-limite. Vou revisar os testes; depois você implementa para passar neles."

Funciona bem por um motivo específico: é muito mais fácil você verificar se um teste descreve o comportamento certo do que verificar se uma implementação está correta. Você revisa a especificação — que é curta e legível — e a implementação passa a ter um alvo objetivo em vez de "o que o modelo achou que você queria".

Três coisas que não funcionam (e todo mundo tenta)

• Mandar ser especialista. "Você é um engenheiro sênior com 20 anos de experiência" faz muito menos diferença do que prometem. Dar o código real faz. Prefira gastar as palavras em contexto.
• Insistir com "agora faz direito". Se a segunda tentativa não melhorou, a terceira não vai. Volte e reescreva o pedido — provavelmente falta um dado que você acha óbvio e não disse.
• Conversa longa demais. Depois de muitas idas e vindas, o modelo começa a se confundir com as versões antigas do código que estão no histórico. Abra uma conversa nova, cole o estado atual e recomece limpo. Custa 30 segundos e resolve.

O teste que vale para qualquer prompt

Antes de mandar, releia o seu pedido e pergunte: "se eu mandasse isso por mensagem para um desenvolvedor competente que nunca viu meu projeto, ele conseguiria fazer sem me perguntar nada?"

Se a resposta é não, a IA também não vai conseguir — ela só não tem o bom senso de perguntar. Cada dúvida que o colega imaginário teria é um ponto onde o modelo vai chutar. E o chute dele é sempre a opção mais comum, que raramente é a sua.

É por isso que quem escreve boa documentação e boas issues costuma se dar muito bem com IA logo de cara: a habilidade é a mesma. Descrever um problema com precisão sempre foi útil. Agora, além de ajudar o time, ajuda a ferramenta.