Prompt Engineering para Devs: como escrever

Anatomia de um bom prompt para código

Um bom prompt de código tem quatro partes bem definidas: contexto, tarefa, restrições e exemplo. Não precisa ser longo — precisa ser preciso e completo. Cada parte tem uma função específica e omitir qualquer uma delas aumenta as chances de um output que você vai precisar retrabalhar.

Contexto, restrições e exemplos

Contexto: quem você é, qual o stack exato do projeto, qual o objetivo geral. Tarefa: o que você quer que seja feito, descrito em linguagem específica e sem ambiguidade. Restrições: o que NÃO pode acontecer, qual padrão seguir obrigatoriamente, qual framework usar, o que evitar. Exemplo: se tiver um padrão existente no projeto que deve ser seguido, mostra o código. Esse quarto elemento é o mais subestimado de todos — um exemplo de código existente do seu projeto vale mais que três parágrafos de descrição em palavras. Mostra, não descreve.

Prompts de sistema vs prompts de tarefa

No Cursor, você tem dois lugares para colocar instruções. O .cursorrules é o equivalente ao system prompt — onde você coloca as regras permanentes e o contexto fixo do projeto: stack, convenções, o que evitar sempre, padrões de nomenclatura, qual biblioteca de testes usar. O chat de cada sessão é onde você coloca a tarefa específica que quer realizar agora. Não repita no chat o que está no .cursorrules — é redundância que confunde. Foque em descrever a tarefa de hoje com precisão e deixa as regras permanentes fazer o trabalho delas.

10 templates de prompt que funcionam

Esses são os templates que uso toda semana em projetos reais. Copie, adapte para o seu contexto, linguagem e framework. Os brackets indicam onde você substitui pelo seu caso específico.

Prompt para gerar API REST

O template para endpoints: 'Cria um endpoint [METHOD] [ROTA] que [DESCRIÇÃO CLARA DO QUE FAZ]. Parâmetros de entrada: [lista com tipos]. Resposta de sucesso com status [CODE]: [formato JSON esperado]. Erros possíveis e seus status codes: [lista]. Use [framework específico] com validação Zod. Sem any no TypeScript. Adiciona tipagem completa e tratamento de erro com try/catch.' Simples assim. Específico o suficiente pra o código sair funcionando de primeira na maioria dos casos.

Prompt para refactoring

Para refactoring, o prompt precisa deixar explícito o que muda e o que absolutamente não muda: 'Refatora a função abaixo para [objetivo — ex: usar async/await no lugar de callbacks, separar em funções menores de responsabilidade única, reduzir complexidade ciclomática abaixo de 5]. Mantém exatamente o mesmo comportamento externo para todos os inputs válidos e inválidos. Não muda os parâmetros de entrada nem o tipo do retorno. Adiciona comentários onde a lógica não é imediatamente óbvia pra um dev sênior.'

Prompt para testes unitários

Testes têm um template específico que extrai muito mais cobertura real: 'Escreve testes unitários com [Jest/Vitest] para a função abaixo. Cobre obrigatoriamente: o happy path com inputs válidos, ao menos 3 edge cases relevantes ao domínio, os casos de erro esperados (inputs inválidos, falhas de dependências). Use describe e it com nomes descritivos em português que leiam como frases. Mocka [lista das dependências externas com o caminho do import]. Usa matchers específicos e corretos — não usa only toBeTruthy para verificar valores.'

Prompt para code review

Code review por IA fica muito melhor quando você define o papel e o foco: 'Revisa o código abaixo como um dev sênior com 10 anos de experiência, com foco especial em [área: segurança de inputs / performance em escala / legibilidade para manutenção / boas práticas de TypeScript]. Para cada problema encontrado: descreve o problema com clareza, explica por que é problemático no contexto de produção, e sugere a correção com código de exemplo. Classifica cada ponto como crítico (bloqueia PR), importante (precisa de ticket) ou sugestão (melhoria futura). Se não encontrar problemas sérios, diz isso explicitamente.'

Erros que todo dev comete ao promptar IA

Depois de usar IA intensivamente por mais de um ano e de observar outros devs usando, os mesmos erros aparecem repetidamente. Aqui estão os que mais prejudicam a qualidade do output.

Prompt engineering avançado: chain-of-thought e few-shot

Para problemas mais complexos — algoritmos não-triviais, arquitetura de módulos, lógica de negócio com muitas regras — duas técnicas avançadas fazem muita diferença. Não são complicadas de usar, mas a maioria dos devs não conhece.

Chain-of-thought: você pede pra IA pensar em voz alta antes de gerar o código. Adiciona ao final do prompt: 'Antes de escrever o código, explica em um parágrafo sua abordagem e por que você escolheu ela em vez de alternativas.' O resultado costuma ser código mais bem pensado e mais explícito nas decisões tomadas — especialmente útil para algoritmos e lógica complexa onde a abordagem errada pode custar caro depois.

Few-shot: você dá ao modelo dois ou três exemplos do tipo de saída que quer antes de pedir o código. 'Aqui estão dois exemplos de como eu quero que os endpoints sejam escritos neste projeto: [exemplo 1] [exemplo 2]. Agora cria um endpoint para [nova funcionalidade] seguindo exatamente o mesmo padrão de estrutura, nomenclatura e tratamento de erro.' O few-shot é o que muda completamente o jogo quando você quer que a IA respeite um padrão muito específico que é difícil de descrever apenas em palavras. Se você quiser saber qual ferramenta responde melhor a prompts estruturados, tem um <a href='/github-copilot-vs-cursor-vs-windsurf-melhor-ai-coding'>comparativo de qual ferramenta responde melhor a prompts estruturados</a> com resultados práticos de testes reais.

Para aproveitar essas técnicas ao máximo no dia a dia, a combinação com o Cursor IDE é a mais poderosa. Tem um guia específico de como <a href='/cursor-ide-como-codar-10x-mais-rapido'>aplicar prompts no Cursor IDE</a> que mostra o workflow completo — do .cursorrules que seta o contexto permanente até os prompts de sessão para tarefas específicas.