Pedir código para IA é fácil. O difícil é receber código que você consegue conferir. Cem linhas que rodam e que você não entende são um problema que vai aparecer daqui a três semanas, quando quebrar.
O que faz diferença no prompt é dizer onde esse código vai morar e o que ele precisa aguentar.
O contexto que falta em quase todo pedido
Stack: {{linguagem e versão}}, {{framework e versão}}
Onde vai morar: {{arquivo ou camada, e o que já existe perto}}
Padrão do projeto: {{ex: sem classe, função pura, erro por exceção}}
Entrada: {{formato exato, com um exemplo real}}
Saída: {{formato exato, com um exemplo real}}
O que já tentei: {{o que não funcionou e o erro que deu}}O campo de entrada e saída com exemplo real vale mais que qualquer descrição. Ele elimina a rodada em que você descobre que a função devolve um formato que não serve.
Peça o contrato antes do código
Em qualquer coisa que passe de vinte linhas, duas rodadas ganham de uma.
Antes de escrever código: descreva a assinatura da função, o que entra, o que sai, e os casos de borda que ela precisa tratar. Liste as decisões que você teria que tomar e onde tem mais de um caminho possível.
Não escreva a implementação ainda.Você lê dez linhas, corrige o que estiver errado e só então pede o código. Corrigir o contrato custa uma frase, corrigir a implementação custa a implementação inteira.
Casos de borda, escritos por você
A IA cobre os casos de borda que costumam aparecer. Ela não cobre os do seu domínio, porque não os conhece.
Trate estes casos:
- lista vazia
- valor nulo em {{campo}}
- data no futuro
- duas linhas com o mesmo {{identificador}}
- número negativo em {{campo}}
Para cada um, diga o que a função faz: retorna vazio, lança erro ou ignora a linha.Escolher entre retornar vazio e lançar erro é decisão de projeto, não de quem escreve a função. Se você não decidir, a IA decide por você.
Peça o teste junto, e leia o teste primeiro
Escreva a função e os testes.
Os testes devem cobrir: o caminho feliz, cada caso de borda listado acima e um caso que deve falhar.
Nomeie cada teste com a frase do que ele garante.Ler o teste antes do código é o atalho: se o nome do teste descreve o comportamento que você quer, o código provavelmente está certo. Se o teste testa o que o código faz, e não o que deveria fazer, você acabou de encontrar o problema.
Revisão de código que você não escreveu
Revise o código abaixo. Responda em três blocos:
1. O que ele faz, em 3 linhas, sem repetir o código.
2. Onde ele quebra: entrada que causa erro, condição não tratada, suposição escondida.
3. O que eu preciso saber antes de colocar isso em produção.
Não reescreva o código. Não sugira melhoria de estilo.
---
{{codigo}}O bloco 1 é o mais importante e o que ninguém pede. Se a explicação do que o código faz não bater com o que você queria, o resto não interessa.
Depurar
Erro: {{mensagem completa, com a pilha}}
O que eu esperava: {{comportamento}}
O que aconteceu: {{comportamento}}
O que muda entre funcionar e não funcionar: {{entrada, ambiente, versão}}
Liste 3 causas possíveis, da mais provável para a menos, e diga como eu testo cada uma em menos de um minuto.
Não me dê o código corrigido ainda.Pedir hipóteses testáveis em vez de correção direta evita o ciclo em que você aplica um conserto, o erro muda de lugar e você perde a linha do que estava investigando.
A regra que vale para tudo
Não aceite código que você não conseguiria explicar para outra pessoa. Se não conseguir, peça assim:
Explique a linha {{n}}. Por que ela precisa existir e o que quebra se eu tirar.
