Pedir código para IA é diferente de pedir texto porque a saída é verificável — e essa verificabilidade deveria estar no prompt. "Entregue código que compila" não é restrição acionável; "entregue o projeto completo com package.json, instruções de rodar em um terminal, e sem TODOs ou placeholders" é.
Aqui estão os padrões que a nossa curadoria exige para prompts de código — os mesmos que separam os 6 prompts da categoria Programação & Web do resto.
1. A restrição anti-alucinação (a mais importante)
O erro número um em geração de código: a IA inventa APIs, pacotes e flags que não existem. O modelo "preenche lacunas" com o padrão estatístico mais provável — e para bibliotecas menos populares, o padrão mais provável é errado.
A correção tem duas partes:
- Trave a versão: "use Fastify 5 (não v4), Prisma 6 e Node 22 LTS". Versão explícita elimina metade das alucinações, porque o modelo para de misturar APIs de gerações diferentes.
- Proíba invenção: "se não tiver certeza de uma API ou flag, deixe um comentário // VERIFICAR em vez de inventar". Essa restrição transforma erro silencioso em sinal visível — e é a diferença entre 10 minutos de debug e 2 horas.
2. Boilerplate: especificação por camadas
O Boilerplate de API REST Fastify + Prisma + TypeScript é o prompt mais copiado da categoria, e a estrutura dele vale como modelo:
- Estrutura do projeto — árvore de pastas explícita (o que vai em
src/routes,src/lib, etc.). Sem isso, cada geração produz uma organização diferente. - Contratos — endpoints com método, path, corpo e resposta. Contratos primeiro, implementação depois: é o mesmo princípio de API-first design.
- Requisitos numerados — cada funcionalidade como item verificável ("1. validação de input com zod em todas as rotas"). Requisito numerado = checklist de aceite que você pode conferir linha a linha.
- Critério de entrega — "npm install && npm run dev sobe a API sem erro; testes de fumaça incluídos". Critério executável é o que torna a saída auditável.
3. Revisão de código: o prompt como auditor
Code review com IA funciona melhor quando você trata o modelo como um revisor sênior específico — não como "verifique meu código". O System Prompt: Code Reviewer Sênior com Foco em Segurança do catálogo é o exemplo completo, mas os elementos essenciais são:
- Papel com especialidade: "revisor sênior focado em segurança web" produz findings diferentes de "revisor genérico". Especialidade concentra a atenção do modelo onde você quer.
- Formato de finding fixo: severidade (crítica/alta/média/baixa), localização (arquivo:linha), descrição, e correção sugerida. Sem formato fixo, o review vira prosa que você precisa reinterpretar.
- Pedido explícito de falsos positivos: "se achar algo que pode ser falso positivo, marque como 'baixa' e explique por quê". Revisores humanos fazem isso; prompts raramente pedem — e é exatamente aí que mora a confiança calibrada.
4. Refatoração: o diff é o produto
Para refatorar código existente, o prompt precisa dizer o que não pode mudar: "mantenha a assinatura pública das funções; não renomeie exports; preserve os testes existentes passando". Sem isso, a IA refatora além do pedido e você passa mais tempo revertendo do que ganhando.
O padrão de saída ideal para refatoração é o diff unificado com explicação por hunk — "para cada bloco alterado, uma linha dizendo por quê". Diferente de boilerplate (onde o produto é o arquivo completo), aqui o produto é a justificativa da mudança.
5. Infra e CI: prompts que economizam horas
Pipeline de CI é onde prompt específico brilha, porque os detalhes que mais doem (cache, multi-stage, matrix) são exatamente os que o modelo sabe — se você pedir. O Pipeline Completo GitHub Actions + Docker Multi-Stage exige explicitamente: cache de dependências por hash do lockfile, build multi-stage com imagem final < 100MB, e fail fast em teste unitário. Cada um desses itens é uma hora economizada por execução.
Para quem trabalha com jogos web, a mesma lógica se aplica: o Plataformer 2D em Phaser 3 especifica física (gravidade, velocidade), assets placeholder e loop de jogo completo — os três pontos onde prompts vagos geram "jogo que não roda".
O checklist da curadoria para código
- Versões das dependências travadas?
- Há restrição anti-invenção de API?
- Requisitos estão numerados e verificáveis?
- O critério de entrega é executável (um comando que prova)?
- Para refatoração: o que não pode mudar está explícito?
Prompts que passam nesses cinco entram no catálogo. Se você está escrevendo um para publicar, comece pelo nosso guia de como avaliar a qualidade de um prompt — o checklist é o mesmo, com os itens específicos desta categoria.
Prompts do catálogo para estudar
- Boilerplate de API REST Fastify + Prisma + TypeScript
- System Prompt: Code Reviewer Sênior com Foco em Segurança
- Pipeline Completo GitHub Actions + Docker Multi-Stage
- Servidor MCP em TypeScript para Ferramentas Customizadas
Perguntas frequentes
Como evitar que a IA invente bibliotecas?
Inclua a restrição anti-alucinação: use apenas a stack listada, não invente métodos ou pacotes, e declare explicitamente o que não sabe em vez de supor.
Como pedir uma revisão de código útil?
Peça um auditor: para cada achado, severidade, arquivo e linha, o risco e a correção sugerida. Sem esse formato, a revisão vira lista de opiniões.
Refatorar código com IA é seguro?
Se a saída for um diff e não o arquivo inteiro. Diff permite revisar exatamente o que mudou; um arquivo reescrito esconde mudanças que você não pediu.