para escrever instruções que funcionam bem no dia a dia
Engenharia de Prompt para Programadores
Eu trato prompt como especificação: um texto curto, verificável e focado em reduzir ambiguidade.
Abaixo está um método prático para transformar intenção em saída útil — especialmente quando você precisa
de código, testes e documentação consistentes.
1) Comece pelo objetivo: transforme “quero um resultado” em critérios de aceitação
Antes de escrever qualquer instrução, eu descrevo o quê deve ser entregue e
como eu vou validar. Isso evita que a conversa “gire” em detalhes irrelevantes.
Objetivo
O que exatamente precisa ser produzido: função, endpoint, script, README, teste, migração.
Critérios de aceitação
Regras objetivas: entradas/saídas esperadas, limites, exemplos, invariantes.
Condições de contorno
O que considerar: performance, compatibilidade, edge cases, erros e mensagens.
Definição de pronto
Como sei que terminou: cobertura de testes, lint passando, formato do output.
Regra de ouro: se o objetivo não tem um jeito claro de verificar, ele ainda não está especificado.
2) Estruture o prompt como um “contrato” (Contexto → Tarefas → Restrições → Formato)
Eu escrevo prompt com uma ordem que “encaixa” no cérebro: primeiro o contexto necessário,
depois as tarefas, depois as restrições, e por fim o formato do resultado.
Essa sequência reduz retrabalho e melhora a consistência.
Contexto
Linguagem, stack, versão, padrões do projeto, estrutura de pastas e dependências relevantes.
Tarefas
Itens numerados do que precisa acontecer: implementar, refatorar, criar testes, escrever documentação.
Restrições
O que NÃO fazer e limites: sem libs externas, O(n log n), sem breaking changes, manter API.
Formato de saída
Como você quer receber: blocos de código, arquivos separados, comandos a executar, seções no README.
Para projetos reais, eu também adiciono prioridades. Ex.: “primeiro corretude,
depois legibilidade, depois performance”. Assim, caso existam trade-offs, a saída tende a respeitar seu critério.
3) Faça perguntas que eliminam ambiguidade (e só então peça a implementação)
Em vez de pedir “faça do jeito certo”, eu descrevo o que já sei e sinalizo as
lacunas. Quando uma decisão muda o comportamento (ex.: política de cache, estratégia de erro,
modelo de dados), eu marco isso como pergunta.
Decisões de negócio
Regras de domínio: como validar, o que acontece em falha, quais status codes/erros usar.
Semântica de API
Contratos: nomes, formatos, paginação, idempotência, formatos de data, encoding.
Estratégias técnicas
Persistência, caches, retries, timeouts, controle de concorrência e transações.
Testabilidade
Quais partes devem ser mockadas, o que deve ter asserts diretos, exemplos e edge cases.
Dica prática: inclua no prompt uma lista do tipo “Se faltar X, assuma Y” ou “Pergunte antes”.
Isso define o comportamento quando informações não estiverem completas.
4) Planeje checagens: saída “boa” é a que passa por critérios de qualidade
Eu não considero o trabalho concluído só porque “parece certo”. Então, eu descrevo
como avaliar a solução: testes, casos extremos, aderência ao estilo e operação em ambiente semelhante.
Testes com cobertura real
Especificar cenários: sucesso, erro esperado, entradas inválidas e limites (strings vazias, números negativos, etc.).
Performance e complexidade
Onde isso importa: loops aninhados, consultas ao banco, ordenações e uso de memória.
Tratamento de erros
Padronizar mensagens, códigos/status e classes de erro. Definir consistência de retorno.
Estilo e manutenção
Regras: nomes, organização em funções menores, comentários úteis, tipagem quando aplicável.
Se você quer que a saída seja útil, peça explicitamente que inclua: comandos para rodar,
estrutura de arquivos e observações sobre trade-offs.
Modelo de prompt que eu uso (exemplo prático)
Abaixo vai um template enxuto. Eu adapto para cada tarefa, mantendo a mesma lógica: objetivo,
critérios, restrições e formato.
Você vai ajudar a implementar um recurso em um projeto Node.js/TypeScript.
OBJETIVO
- Implementar um endpoint POST /v1/schedules que cria um agendamento.
CRITÉRIOS DE ACEITAÇÃO
- Recebe JSON: { "userId": string, "start": ISO8601, "durationMinutes": number }
- Retorna 201 com: { "id": string, "userId": string, "start": string, "end": string }
- end = start + durationMinutes (considerar timezone do ISO enviado)
- Erros:
- userId vazio -> 400 com mensagem padronizada
- start inválido -> 400
- durationMinutes <= 0 -> 422
- conflito de horário para o mesmo userId -> 409
RESTRIÇÕES
- Não adicionar libs externas.
- Usar o estilo e camadas já existentes (controller/service/repository).
- Persistir via repository já existente (use os métodos atuais).
- Incluir validação e tratamento de erros seguindo o padrão do projeto.
TAREFAS
1) Descrever rapidamente o fluxo (validação → serviço → repositório → resposta).
2) Fornecer o código completo dos arquivos impactados:
- src/controllers/scheduleController.ts (ou equivalente)
- src/services/scheduleService.ts
- src/repositories/scheduleRepository.ts (se necessário)
- src/routes/schedules.ts (se necessário)
3) Criar testes:
- 5 testes de API (happy path + 4 cenários de erro)
- pelo menos 3 testes unitários do service/repository
4) Escrever comandos para rodar: build, test e lint.
FORMATO DE SAÍDA
- Responder com seções:
- “Fluxo”
- “Código” (com blocos por arquivo)
- “Testes” (com blocos por arquivo)
- “Comandos para executar”
- Não omitir arquivos ou trechos que conectam as camadas.
PERGUNTAS (se faltar informação)
- Se o projeto já define um helper de validação, use-o; senão, proponha um mínimo e coerente.
- Confirmar como o repositório representa conflitos (consulta existente? regra no serviço?).Quer deixar seu fluxo de trabalho ainda mais redondo?
Leia os próximos posts do yurideveloper.com para consolidar boas práticas de engenharia de código:
arquitetura, testes, padrões de desenvolvimento e qualidade.
Sou Apaixonado pela programação e estou trilhando o caminho de ter cada diz mais conhecimento e trazer toda minha experiência vinda do Design para a programação resultando em layouts incríveis e idéias inovadoras! Conecte-se Comigo!