GPTPrompts.AIPrompts para
Prompts para
código.
40 prompts testados para desenvolvimento. Revisão, debug, refatoração, documentação e SQL em português brasileiro.
Funciona em ChatGPT, Claude, Cursor, Windsurf e GitHub Copilot Chat.
Como usar
Três ajustes antes de colar.
- 1. Especifique a linguagem e versão. 'Python 3.11', 'Go 1.22', 'TypeScript 5.3'. IA costuma default para versões antigas e gera código depreciado.
- 2. Diga o que já tentou. Em prompts de debug, 'já verifiquei X e Y' evita que o modelo sugira o óbvio e acelera o diagnóstico real.
- 3. Revise antes de usar. Esses prompts reduzem o tempo de rascunho, não o tempo de review. Código gerado por IA sem revisão humana é dívida técnica em produção.
Categoria
Revisão de código
Revisar função com critérios claros
Aja como tech lead revisando código em [LINGUAGEM]. Revise a função abaixo por estes critérios: 1. Correção: a função faz o que o nome promete? 2. Edge cases: lista até 5 casos de input que podem quebrar 3. Legibilidade: nomes, complexidade ciclomática, aninhamento excessivo 4. Performance: algo obviamente ruim (N+1, complexidade desnecessária) 5. Segurança: se lida com input externo, vulnerabilidades comuns Formato do output: - Severidade (crítico / médio / baixo) + descrição em 1 linha - Sugestão de fix em código quando aplicável Não refatore tudo. Foque em issues reais. CÓDIGO: ``` [cole aqui] ```
Revisar pull request inteiro
Aja como revisor sênior. Analise o diff abaixo e entregue: 1. Sumário de 3 linhas: o que este PR faz em alto nível 2. Bloqueadores: issues que impedem merge (bugs, regressões, tests quebrados, segurança). Cite arquivo:linha 3. Sugestões não bloqueadoras: até 5 melhorias para discutir 4. O que foi bem feito: 2 ou 3 pontos específicos, não genéricos 5. Veredito: aprovar / aprovar com ajustes / rejeitar Português brasileiro técnico. Sem sycophancy. DIFF: ``` [cole o diff aqui] ```
Avaliar estrutura de projeto
Aja como arquiteto avaliando estrutura de projeto em [STACK]. Abaixo está a árvore de diretórios e o que cada pasta contém. 1. Três problemas estruturais (acoplamento, nomes inconsistentes, pastas que viraram lixeira) 2. Duas recomendações concretas de reorganização, com justificativa 3. O que NÃO mexer (coisas que parecem estranhas mas existem por motivo) 4. Nota: essa estrutura se mantém saudável em escala de 10 devs e 100k linhas? ESTRUTURA: ``` [cole a árvore com comentário do que tem em cada pasta] ```
Checar cobertura de testes
Aja como engenheiro de QA. Abaixo está a função X e seus testes. Avalie: 1. Caminhos cobertos (liste cada) 2. Caminhos não cobertos (liste com criticidade) 3. Testes redundantes que podem ser removidos 4. Cenários importantes que nenhum teste cobre (empty, nulo, limite, concorrência) 5. Sugira 3 testes novos em código pronto para colar FUNÇÃO: ``` [cole aqui] ``` TESTES: ``` [cole aqui] ```
Review de segurança focado
Aja como engenheiro de segurança aplicativa. Revise o código abaixo contra a OWASP Top 10 e identifique: 1. Injeções possíveis (SQL, command, HTML) 2. Controle de autorização (checagens faltando, bypass possível) 3. Exposição de dados sensíveis (logs, respostas, mensagens de erro) 4. Validação de input fraca 5. Dependências ou APIs que podem estar desatualizadas Para cada issue: severidade (crítico/alto/médio/baixo), linha, explicação, fix em código. Não faça audit geral. Só segurança. CÓDIGO: ``` [cole aqui] ```
Categoria
Debug e investigação
Debug com raciocínio estruturado
Aja como engenheiro sênior investigando bug. Antes de propor fix, pense: 1. Hipóteses iniciais: 3 causas possíveis ranqueadas por probabilidade 2. Evidência: para cada hipótese, qual log ou comportamento confirma ou descarta 3. Diagnóstico: a causa mais provável e o raciocínio 4. Fix: código que resolve (com comentário do que está sendo mudado) 5. Prevenção: teste, alerta ou guard rail para não voltar a acontecer Sintoma: [descreva: o que deveria acontecer, o que aconteceu, quando começou] Logs relevantes: ``` [cole aqui] ``` Código relacionado: ``` [cole o trecho] ```
Bug que só acontece em produção
Aja como engenheiro de sistemas distribuídos. O bug abaixo reproduz em prod mas não em local nem staging. Analise possíveis causas por categoria: 1. Ambiente: variáveis, versões de lib, configs que diferem 2. Carga: concorrência, race condition, timeouts que só aparecem em throughput alto 3. Dados: estado que só existe em prod, edge cases de dados reais 4. Rede: latência, DNS, firewalls 5. Timing: cron jobs, caches, expirações Para cada categoria: hipótese específica + como validar em 5 minutos sem mexer em prod. Sintoma: [descreva] O que já foi tentado: [liste]
Explicar mensagem de erro obscura
Aja como engenheiro que já viu de tudo. A mensagem de erro abaixo é obscura. Explique: 1. O que a mensagem literalmente significa (não o jargão) 2. Três causas mais comuns (com 1 linha de verificação cada) 3. Causas raras mas possíveis (se houver) 4. Comando ou código para diagnosticar qual delas MENSAGEM: ``` [cole stack trace ou mensagem completa] ``` CONTEXTO: Linguagem/stack: [Python 3.11 com FastAPI, por exemplo] Quando acontece: [em prod sob carga, no deploy, etc]
Performance: função lenta
Aja como engenheiro de performance. A função abaixo está lenta. Analise por categoria: 1. Complexidade algorítmica: big O atual, se há versão melhor 2. I/O: chamadas de rede, queries, leitura de disco desnecessárias 3. Memória: alocações evitáveis, garbage pressure 4. Paralelismo: trabalho serial que poderia ser paralelo 5. Cache: dados recalculados que poderiam ser cached Para cada categoria: diagnóstico + fix em código. Priorize ganhos reais. Micro-optimizations só se o profiling justificar. FUNÇÃO: ``` [cole aqui] ``` CONTEXTO: [volume de dados típico, hot path ou não, etc]
Reproducir bug em teste unitário
Aja como engenheiro de QA. Quero capturar o bug descrito abaixo em um teste que falha antes do fix e passa depois. Escreva: 1. Teste unitário mínimo que expõe o bug (em [framework: pytest / Jest / JUnit]) 2. Fixtures necessárias 3. Assertion explícita sobre o comportamento errado vs esperado 4. Comentário no teste explicando o bug, para quando alguém ler daqui a 6 meses BUG: [descreva: input, output errado, output esperado] CÓDIGO AFETADO: ``` [cole função] ```
Categoria
Refatoração
Refatorar para legibilidade
Aja como engenheiro que prioriza legibilidade. Refatore o código abaixo mantendo: - Mesmos inputs e outputs - Mesma assinatura pública (para não quebrar callers) - Tests existentes passando Foco: 1. Nomes de variáveis e funções explicativos 2. Funções pequenas (até 20 linhas quando possível) 3. Reduzir aninhamento (early returns) 4. Comentários só onde o código não consegue falar sozinho Entregue antes/depois lado a lado com 1 linha de justificativa por mudança. CÓDIGO: ``` [cole aqui] ```
Extrair função pura
Aja como engenheiro sênior. No código abaixo, há lógica que deveria ser função pura testável. Identifique e extraia: 1. Aponte quais blocos são lógica pura misturada com I/O 2. Extraia em função separada com nome descritivo 3. Atualize o caller 4. Escreva 3 testes unitários da nova função pura Linguagem: [LINGUAGEM] CÓDIGO: ``` [cole aqui] ```
Remover código morto
Aja como engenheiro limpando tech debt. Analise o código abaixo e identifique: 1. Funções ou variáveis não usadas 2. Branches inalcançáveis 3. Comentários obsoletos que contradizem o código 4. Imports não usados 5. Código comentado que deveria ser deletado Entregue versão limpa + lista do que foi removido com justificativa de 1 linha. Se algum item é ambíguo (pode estar sendo usado por reflexão ou via string), sinalize como 'manter com comentário'. CÓDIGO: ``` [cole aqui] ```
Migrar de padrão antigo para novo
Aja como engenheiro liderando migração. Migre o código abaixo de [PADRÃO ANTIGO: callbacks / class components / jQuery / etc] para [PADRÃO NOVO: async-await / hooks / fetch API]. Regras: 1. Mesmo comportamento observável 2. Testes existentes continuam passando 3. Preserve comentários que explicam decisões não triviais 4. Se algo não tem equivalente direto, explique trade-off e escolha Entregue o código migrado + lista das 3 mudanças conceituais mais importantes para o leitor humano aprender. CÓDIGO: ``` [cole aqui] ```
Aplicar princípio SOLID específico
Aja como arquiteto explicando refatoração. A classe abaixo viola o princípio [S / O / L / I / D]. Entregue: 1. Onde exatamente viola (linha específica, não abstração) 2. Por que isso cria problema concreto em manutenção 3. Refatoração respeitando o princípio 4. Código antes/depois 5. Quando NÃO aplicar esse princípio (over-engineering também é problema) CÓDIGO: ``` [cole aqui] ```
Categoria
Documentação e commits
Docstring em padrão profissional
Aja como technical writer para código. Adicione docstring à função abaixo no padrão [Google / JSDoc / reStructuredText / conforme a linguagem]. Inclua: 1. Uma frase de sumário (o que a função faz, não como) 2. Parágrafo com contexto: quando usar, quando não usar 3. Args com tipo e explicação 4. Return com tipo e significado 5. Raises / erros possíveis 6. Exemplo de uso em 3 a 5 linhas Não mude a implementação. Só docstring. FUNÇÃO: ``` [cole aqui] ```
README de projeto open source
Aja como maintainer de projeto open source brasileiro. Escreva README em markdown para o projeto abaixo. Estrutura: 1. Nome + badge de status / licença 2. Descrição em 2 linhas (o que é, para quem) 3. Por que existe (problema que resolve) 4. Instalação em 3 linhas de código 5. Uso mínimo (snippet de 5 linhas) 6. Uso avançado (link para docs se houver) 7. Como contribuir 8. Licença Tom: direto, sem marketing. Português brasileiro técnico. CONTEXTO DO PROJETO: [descreva: nome, stack, funcionalidade principal]
ADR para decisão arquitetural
Aja como arquiteto registrando decisão. Escreva ADR (Architecture Decision Record) em markdown: - Título: [DECISÃO] - Status: proposto - Contexto: 4 a 6 frases (problema, forças em jogo, restrições) - Decisão: 1 a 2 frases em voz ativa - Alternativas consideradas: mínimo 2, com 1 parágrafo cada do porquê descartadas - Consequências: positivas (3) e negativas (2), honestas Português técnico brasileiro. Não invente restrições não mencionadas. DECISÃO EM QUESTÃO: [descreva o que está sendo decidido] CONTEXTO: [cole contexto relevante]
Runbook de operação
Aja como SRE escrevendo runbook para on-call. O cenário: [DESCREVA: serviço X começou a dar 500, fila Y subiu, etc]. Estrutura do runbook em markdown: 1. Sintoma: como o oncall identifica que este é o caso 2. Diagnóstico rápido: 3 comandos ou dashboards para confirmar (com copy-paste pronto) 3. Mitigação imediata: o que fazer em 5 minutos para estancar 4. Fix definitivo: investigação mais longa 5. Comunicação: quem avisar, template de mensagem 6. Escalação: quando e para quem escalar Português direto. Não escreva parágrafos longos, runbook é para quem está sob pressão.
Comentário de commit útil
Aja como tech lead ensinando bom commit message. Abaixo o diff de uma mudança. Escreva commit message no padrão Conventional Commits:
1. Header: type(scope): subject (máximo 72 caracteres)
2. Body: 2 a 4 parágrafos explicando (a) o quê mudou, (b) por quê, (c) risco
3. Footer: breaking changes, refs de issue (se aplicável)
Português brasileiro. Voz imperativa ('adiciona X', não 'adicionado X').
DIFF:
```
[cole aqui]
```
MOTIVO DA MUDANÇA:
[1 ou 2 frases]Categoria
Dados e SQL
Query SQL com CTEs e comentário
Aja como engenheiro de dados sênior em [PostgreSQL / BigQuery / Snowflake / ClickHouse]. Escreva query que [OBJETIVO]. O schema: ```sql [cole DDL ou descrição das tabelas relevantes] ``` Regras: 1. Use CTEs para cada passo lógico (com comentário de 1 linha cada) 2. Otimize para leitura, não para performance extrema 3. No final, explique trade-offs (sampled vs exato, aproximações, etc) 4. Se houver indicação de índice recomendado, sinalize Questão específica: [O QUE VOCÊ QUER RESPONDER]
Otimizar query lenta
Aja como DBA com foco em performance. A query abaixo está lenta. Analise: 1. Problemas prováveis (seq scan em tabela grande, join sem índice, função em WHERE, etc) 2. Reescrita otimizada 3. Índices sugeridos (com CREATE INDEX pronto) 4. Se houver trade-off (índice pesa em write), explique 5. Comando de EXPLAIN ANALYZE para validar ganho Dialeto: [PostgreSQL / MySQL / etc] QUERY: ```sql [cole aqui] ``` CONTEXTO: [volume de dados, frequência de execução, se é OLTP ou OLAP]
Modelar schema de banco
Aja como arquiteto de dados. Preciso modelar banco relacional para [DOMÍNIO]. Entregue: 1. Diagrama ER descrito em texto (tabelas, colunas principais, relacionamentos) 2. DDL em [PostgreSQL / MySQL] com tipos apropriados, PKs, FKs, índices óbvios 3. Três decisões de design controversas (com trade-offs) 4. Dados que você NÃO colocou no banco (e onde deveriam ir) Não normalize demais nem de menos. Decisão deve ser justificada. REQUISITOS FUNCIONAIS: [liste casos de uso principais] VOLUMETRIA ESPERADA: [escala em 1 ano e em 5]
Explicar plano de execução
Aja como DBA explicando para dev intermediário. Abaixo está o EXPLAIN ANALYZE de uma query. Explique: 1. Por onde o banco começa (driver table) 2. Quais operações custaram mais (com custo absoluto) 3. Onde há oportunidade de melhoria 4. Uma reescrita ou índice que reduziria o custo, com expectativa de ganho 5. O que NÃO mexer (operações já otimizadas) Português técnico brasileiro. EXPLAIN ANALYZE: ``` [cole aqui] ```
Validar dados com checks
Aja como engenheiro de qualidade de dados. Dado o schema da tabela [NOME], escreva 10 checks de qualidade em SQL: 1. Cardinalidade esperada (contagem em ranges sensatos) 2. Unicidade em colunas que devem ser únicas 3. Referential integrity (FKs que podem estar órfãs) 4. Range de valores (ex: ano entre 2000 e 2030) 5. Formato (ex: CPF tem 11 dígitos) 6. Nulls onde não deveria haver 7. Duplicatas lógicas 8. Distribuição (ex: nenhum valor representa mais de 95%) 9. Consistência temporal (created_at < updated_at) 10. Completude cruzada (ex: se tem customer_id deve ter customer_name) Para cada check: query SQL + threshold + o que fazer quando falha. SCHEMA: ``` [cole DDL ou descrição] ```
Continue
Próximos passos.
FAQ
Perguntas sobre prompts para código.
Estes prompts funcionam no Cursor e GitHub Copilot Chat?+
Sim. Os prompts são agnósticos de IDE. No Cursor, cole como instrução de chat. No GitHub Copilot Chat no VSCode, use /explain ou /fix antes e cole a instrução. Na maioria dos casos, adicionar '@file' ou '@workspace' no Cursor dá contexto automático e o prompt fica ainda melhor.
Por que os prompts pedem raciocínio passo a passo em vez de só o código?+
Modelos de IA entregam código melhor quando forçados a pensar antes. Pedir 'pense na abordagem, liste opções, escolha uma com justificativa e então escreva' reduz bugs de lógica e escolhas ruins de design. Para tarefas simples (ajustar sintaxe), raciocínio é desnecessário e atrapalha.
Devo copiar o código inteiro ou só o trecho relevante?+
Para prompts de debug, revisão e refatoração, cole só o trecho relevante e mencione o que você cortou. Janela de contexto é limitada. Para tarefas arquiteturais (onde a IA precisa entender todo o sistema), use ferramentas como Cursor que indexam o projeto inteiro.
Os prompts assumem qual linguagem?+
São agnósticos. Troque [LINGUAGEM] pelo que está usando (Python, TypeScript, Go, Java, Rust). Alguns prompts têm variações específicas (SQL tem dialetos diferentes). Para linguagens menos comuns (Elixir, Clojure, Zig), peça explicitamente 'idiomatic em [LINGUAGEM]'.
Posso confiar no código gerado?+
Você precisa revisar. Em 2026, IA gera código correto em 70 a 90% dos casos para tarefas padrão, mas falha em casos edge, em código que interage com estado compartilhado e quando a lógica de negócio é complexa. Trate o output como rascunho de um junior talentoso: útil, mas precisa review.
Qual modelo é melhor para código em 2026?+
Para raciocínio profundo sobre arquitetura e debug difícil: Claude 4 Opus e GPT-5 empatam. Para completion rápido no editor: Cursor com Claude 4 Sonnet ou GPT-5 mini. Para revisão de PR longo: Claude (contexto maior). Para SQL e one-liners: GPT-5 mini é rápido e suficiente. Faça teste com seu caso real antes de escolher.