Prompts para programador em 2027: 15 prompts testados para legado, testes, debug e SQL

Estes são 15 prompts para programador que funcionam no dia a dia de um time de produto e de um freela: entender legado, escrever teste, depurar, revisar o próprio PR, acelerar SQL e falar com cliente. Cada um tem quando usar, o texto para copiar e, em cinco deles, a saída real que a IA devolveu. Rodam no ChatGPT, no Claude, no Gemini e no chat do Copilot.

Uma regra antes de copiar qualquer um: nada de segredo, token, .env ou dado real de cliente no prompt. Troque por valores fictícios.

Por que estes prompts funcionam

Prompt de código que dá certo tem quatro coisas: stack e versão (PHP 7.2 e PHP 8.3 são linguagens diferentes na prática), o código ou o erro de verdade, o formato da resposta e o que a IA não pode fazer (inventar biblioteca, mudar comportamento, mexer em arquivo que você não pediu). A última parte é a que mais falta. Sem ela, você pede para explicar uma função e recebe a função reescrita.

Entender código que não é seu

1. Explicar legado separando certeza de suposição

Quando usar: ticket em arquivo antigo, sem teste e sem ninguém que lembre por que é assim.

Explique a função abaixo para um dev que vai alterá-la amanhã. Linguagem: [LINGUAGEM E VERSÃO].
Responda em 4 partes:
1. O que ela calcula, em 3 frases
2. Entradas e saída, com o tipo provável de cada uma
3. Comportamentos estranhos ou perigosos (conversão de tipo, ordem das regras, valores mágicos)
4. Perguntas que eu preciso responder antes de mexer
Marque com [CERTEZA] o que está no código e com [SUPOSIÇÃO] o que você deduziu pelo nome. Não reescreva a função.

[CÓDIGO]

Saída real, para uma função de frete em PHP 7.2:

function calcFrete($p, $cep, $tp) {
  $f = 0;
  if (substr($cep,0,1) < 4) { $f = 15; } else { $f = 28; }
  if ($p > 30) $f = $f + ($p - 30) * 0.8;
  if ($tp == 2) $f = $f * 1.6;
  if ($f > 120) $f = 120;
  return round($f, 2);
}

1. O que calcula. O valor do frete a partir de peso, CEP e tipo de envio. Há uma base por região, um adicional por excesso de peso, um multiplicador para o tipo 2 e um teto de 120. [CERTEZA]

2. Entradas e saída. $p: peso, provavelmente em kg (o corte em 30 sugere isso) [SUPOSIÇÃO]. $cep: string com o CEP; só o primeiro dígito importa [CERTEZA]. $tp: tipo de envio, e o valor 2 parece ser expresso [SUPOSIÇÃO]. Saída: float com 2 casas [CERTEZA].

3. Pontos perigosos. (a) Os primeiros dígitos 0 a 3 cobrem SP, RJ, ES e MG, que pagam 15; o resto paga 28 [CERTEZA no código, SUPOSIÇÃO sobre a intenção]. (b) CEP vazio: substr('', 0, 1) retorna string vazia e a comparação com 4 dá verdadeiro, então um CEP vazio paga a tarifa mais barata [CERTEZA]. (c) O teto é aplicado depois do multiplicador, então expresso pesado custa o mesmo que normal pesado [CERTEZA]. (d) 0.8, 30, 1.6 e 120 são números soltos, sem constante [CERTEZA].

4. Perguntas antes de mexer. O teto de 120 vale também para expresso? CEP chega com hífen e sem validação? Existem outros valores de $tp além de 1 e 2? Quem mais chama essa função (carrinho, painel admin, API de parceiros)?

O item (b) é bug que ninguém procura. Vale um teste.

2. Mapa de impacto antes da mudança

Quando usar: com um agente que enxerga o repositório (Claude Code, Codex, Copilot no modo agente), antes de abrir qualquer arquivo.

Vou alterar [FUNÇÃO/CLASSE] para [MUDANÇA]. Sem editar nada, liste:
- todos os pontos do repositório que chamam ou dependem dela, com arquivo e linha
- testes existentes que cobrem esse comportamento
- o que pode quebrar em cada ponto
Termine com um plano de alteração em passos pequenos, cada um com o teste que prova que funcionou.

Testes

3. Casos de borda antes do teste

Quando usar: função de regra de negócio (dinheiro, data, permissão) que vai ganhar teste.

Liste 6 entradas que podem quebrar a função abaixo, da mais provável para a menos provável. Para cada uma: a entrada, o resultado esperado e por que ela é perigosa. Depois escreva os testes em [FRAMEWORK DE TESTE], um por caso, com nomes descritivos em português. Não altere a função.

[CÓDIGO]

Saída real, para uma função JavaScript parcelar(valor, n) que divide uma compra em parcelas com Math.round(valor / n * 100) / 100:

1. Divisão que não fecha: parcelar(100, 3) deve somar 100,00 e devolver 33,33 + 33,33 + 33,34. Hoje devolve três de 33,33 e some 1 centavo.

2. Ponto flutuante: parcelar(0.3, 3) deve devolver três de 0,10. Soma de números quebrados em float não fecha sem trabalhar em centavos inteiros.

3. Valor menor que o número de parcelas: parcelar(0.05, 10) geraria parcelas de 0,005. Esperado: erro de validação ou regra de parcela mínima.

4. n igual a zero: divisão por zero devolve Infinity. Esperado: erro.

5. n negativo ou não inteiro: parcelar(100, -2) e parcelar(100, 2.5). Esperado: erro.

6. Parcela única: parcelar(99.99, 1) deve devolver exatamente [99,99].

test('a soma das parcelas é igual ao valor quando a divisão não fecha', () => { const p = parcelar(100, 3); expect(p.reduce((a, b) => a + Math.round(b * 100), 0)).toBe(10000); expect(p[2]).toBe(33.34); }); (e mais cinco, um por caso)

Os casos 1 e 2 são bug real da função original.

4. Teste de caracterização

Quando usar: você vai refatorar legado e precisa travar o comportamento atual, certo ou errado.

Escreva testes de caracterização para a função abaixo em [FRAMEWORK]. O objetivo é registrar o comportamento ATUAL, inclusive o que parece bug. Para cada comportamento estranho, deixe um comentário "comportamento atual, confirmar com o negócio". Cubra todos os ramos do código.

[CÓDIGO]

Debug

5. Stack trace vira hipóteses

Quando usar: erro novo no Sentry e nenhuma pista.

Erro em produção, [LINGUAGEM/FRAMEWORK E VERSÃO]. Abaixo o stack trace e o trecho do código.
Me dê 3 hipóteses de causa, da mais provável para a menos provável. Para cada uma: por que pode ser, como confirmar em menos de 10 minutos e a correção. Não sugira try/except ou checagem de null que só esconda o erro sem tratar a causa.

STACK TRACE:
[COLE]

CÓDIGO:
[COLE]

Saída real, para um KeyError: 'cpf' numa view Django que recebe webhook de pagamento, na linha cpf = payload["customer"]["cpf"]:

Hipótese 1 (mais provável): cliente pessoa jurídica ou estrangeiro. O gateway manda cnpj ou um campo de documento genérico quando o comprador não é pessoa física, e a chave cpf não vem. Confirmar: registre payload["customer"].keys() nos próximos webhooks com erro, ou procure no painel do gateway uma venda para CNPJ. Correção: ler o documento pelo campo que o gateway documenta para os dois casos e tratar CNPJ como caso válido, não como erro.

Hipótese 2: mudança de versão do webhook. O gateway passou a mandar document com type e number. Confirmar: compare um payload antigo que funcionou com um de hoje. Correção: fixar a versão do webhook e adaptar o parser.

Hipótese 3: evento diferente na mesma URL. Eventos como reembolso ou disputa chegam sem o bloco completo de cliente. Correção: filtrar pelo tipo de evento antes do parser e responder 200 aos que a view não processa.

Repare que nenhuma das três correções é payload.get("cpf"). Esse é o conserto que esconde o erro e deixa o pedido sem documento no banco.

6. Bug que só acontece às vezes

Quando usar: erro intermitente, teste que falha 1 vez em 20, problema que some quando você põe log.

Tenho um bug intermitente: [SINTOMA], acontece [FREQUÊNCIA], só em [AMBIENTE]. Liste as causas típicas desse padrão (concorrência, cache, fuso horário, ordem de teste, dependência externa) que se encaixam no código abaixo e, para cada uma, um experimento que prove ou descarte a causa. Não proponha correção ainda.

[CÓDIGO]

Revisão e PR

7. Revisar o próprio diff antes de abrir o PR

Quando usar: freela solo, ou antes de pedir revisão para o sênior e passar vergonha com o óbvio.

Revise este diff como um sênior chato, mas justo. Procure só: falha de segurança, bug provável, query ruim e teste faltando. Ignore estilo e formatação. Para cada problema: arquivo, linha, gravidade (bloqueia, importante, sugestão) e a correção. No máximo 8 itens. Se não houver nada sério, diga isso em uma linha.

[DIFF]

Em time, esse mesmo texto vira o revisor automático do agente de IA para programador, rodando em todo PR sem você pedir.

8. Descrição de PR que o revisor lê

Escreva a descrição deste PR a partir do diff e do ticket. Seções: Por que (2 frases, a partir do ticket), O que mudou (lista curta), Como testar (passos que outra pessoa consegue seguir), Riscos e o que não foi feito. Sem frases genéricas como "melhorias gerais".

TICKET: [COLE]
DIFF: [COLE]

Banco de dados

9. Query lenta com EXPLAIN

Quando usar: tela que demora, alerta de query lenta, relatório que trava o banco no fim do mês.

Banco: [POSTGRES/MYSQL E VERSÃO]. A query abaixo está lenta. Seguem o schema das tabelas, os índices existentes e a saída do EXPLAIN ANALYZE.
Explique por que está lenta, proponha a query reescrita e os índices que você criaria, e diga o custo de cada índice (escrita, espaço). Não invente coluna que não está no schema.

QUERY: [COLE]
SCHEMA E ÍNDICES: [COLE]
EXPLAIN ANALYZE: [COLE]

Saída real, para SELECT * FROM pedidos WHERE DATE(criado_em) = '2026-10-20' AND status = 'pago' ORDER BY criado_em DESC no Postgres 16, com índice só em criado_em e 4 milhões de linhas:

Por que está lenta: DATE(criado_em) aplica uma função na coluna, então o índice em criado_em não pode ser usado para o filtro e o plano faz leitura sequencial da tabela inteira. O SELECT * ainda traz colunas que a tela não usa.

Query reescrita: SELECT id, cliente_id, total, criado_em FROM pedidos WHERE criado_em >= '2026-10-20' AND criado_em < '2026-10-21' AND status = 'pago' ORDER BY criado_em DESC;

Índice: CREATE INDEX CONCURRENTLY idx_pedidos_status_criado ON pedidos (status, criado_em DESC); Ele atende o filtro por status e já entrega a ordem. Custo: um pouco mais de escrita em cada pedido novo e algumas dezenas de MB.

Atenção: se criado_em for timestamptz, o "dia 20" depende do fuso da sessão. Passe o intervalo já no fuso de São Paulo ('2026-10-20 00:00-03') para não perder pedidos da noite.

10. Migration que não derruba produção

Preciso [MUDANÇA NO SCHEMA] na tabela [TABELA], que tem [N] linhas e recebe escrita o tempo todo, em [BANCO E VERSÃO]. Monte o plano em etapas que não travem a tabela: migrations em ordem, o que muda no código entre cada etapa, como reverter cada uma e o que monitorar no deploy.

Documentação

11. README de onboarding

Com base nos arquivos de configuração abaixo (package.json, docker-compose, .env.example, Makefile), escreva o README que um dev novo precisa no primeiro dia: como subir o projeto do zero, como rodar os testes, variáveis de ambiente e para que serve cada uma, e os 3 problemas mais prováveis na primeira execução. Não invente comando que não esteja nos arquivos.

[COLE OS ARQUIVOS]

12. Registro de decisão (ADR)

Escreva um ADR curto sobre a decisão de [DECISÃO]. Contexto, opções consideradas ([OPÇÃO A], [OPÇÃO B], [OPÇÃO C]) com prós e contras concretos para o nosso caso ([TAMANHO DO TIME, VOLUME, PRAZO]), decisão, consequências e quando revisar. Uma página no máximo.

Cliente e carreira

13. Orçamento de freela sem esquecer metade

Quando usar: o cliente mandou "quero um app tipo o do iFood, só que para o meu bairro" e pediu preço até amanhã.

Um cliente pediu: [PEDIDO DO CLIENTE, COM AS PALAVRAS DELE]. Quebre em módulos e subtarefas. Para cada subtarefa: estimativa em horas com faixa (mínimo e máximo) e o risco que pode estourar o prazo. Depois liste o que o cliente NÃO falou mas vai precisar (login, recuperação de senha, e-mail transacional, painel admin, LGPD no cadastro, hospedagem, manutenção). Não dê preço em reais.

14. Avisar o cliente de atraso sem parecer desculpa

Escreva uma mensagem de WhatsApp para um cliente não técnico avisando que a entrega de [ENTREGA] vai atrasar [PRAZO]. Motivo real: [MOTIVO]. Explique o motivo em linguagem simples, diga o que já está pronto, a nova data e o que eu preciso dele (se precisar). Sem jargão, sem pedir desculpa três vezes, até 90 palavras.

Saída real, para um atraso de 4 dias porque a integração com o gateway de pagamento exigiu aprovação da conta do próprio cliente:

Oi, Marcos! Passando para te atualizar sobre a loja. Cadastro, catálogo e carrinho estão prontos e testados. O que travou foi o pagamento: a empresa de cartão precisa aprovar a sua conta antes de liberar as vendas, e essa análise ainda está em andamento. Por isso a entrega passa de sexta para a terça, dia 3. Para não atrasar mais, preciso que você responda o e-mail deles com o documento da empresa ainda hoje. Qualquer dúvida, me chama.

15. Júnior estudando com o código do trabalho

Quando usar: você aceitou uma sugestão da IA, funcionou e você não sabe por quê.

Sou dev júnior. O código abaixo funciona, mas eu não entendo [TRECHO]. Explique como se fosse um colega sênior do meu lado: o que cada parte faz, por que foi escrito assim, uma alternativa mais simples (se existir) e o que daria errado se eu removesse cada linha. No fim, me faça 2 perguntas para eu ver se entendi.

[CÓDIGO]

No guia de IA para programação tem a conversa completa sobre como júnior e sênior usam IA de jeitos diferentes.

Erros comuns com prompts de código

• Não dizer a versão. Sem "Python 3.12" ou "React 19", a IA mistura sintaxe de versões diferentes.
• Pedir correção sem pedir causa. Você recebe um if que esconde o sintoma. Peça hipóteses primeiro (prompt 5).
• Aceitar pacote novo sem conferir. Se a resposta manda instalar uma biblioteca, confira no npm ou no PyPI se ela existe, quem mantém e quando foi a última versão.
• Usar a primeira resposta. "Agora critique a sua resposta e aponte o ponto mais fraco" melhora quase tudo.

Quer mais? O pack em PDF tem mais de 50 prompts que não estão aqui, de arquitetura, DevOps, segurança, entrevista técnica e conversa com cliente.

Quer pular essa parte?

Agentes de IA prontos para devs e times de software: sem montar nada, sem prompt, já trabalham por você.

• Primeira revisão de todo PR, com comentários na linha e etiqueta de risco
• Triagem de bugs do suporte direto para o backlog, com passos para reproduzir
• Regras de segurança e de LGPD já configuradas, sem permissão de aprovar ou fazer merge

Quero os agentes prontos