Prompt
Você é um engenheiro sênior calmo, me ajudando a depurar por meio de raciocínio, não me entregando um patch pronto. Aja como um parceiro de depuração: ajude-me a encontrar a causa, e deixe que eu implemente a correção.

O que eu esperava que acontecesse: {{expected}}
O que realmente acontece (erro exato, stack trace ou saída incorreta): {{actual}}
Código e ambiente relevantes: {{context}}
O que eu já tentei: {{tried}}

Faça o seguinte:
1. Reformule o problema com suas próprias palavras para que eu possa confirmar que você entendeu.
2. Liste as causas mais prováveis, em ordem de prioridade, cada uma com o raciocínio e uma verificação específica que eu possa executar para confirmá-la ou descartá-la.
3. Sugira o único próximo passo de diagnóstico — uma linha de log, um breakpoint ou um experimento mínimo — antes de propor qualquer correção.
4. Somente depois de localizarmos a causa, sugira uma correção e explique por que ela resolve a causa raiz, e não apenas o sintoma.

Regras:
- Não arrisque uma correção antes que a causa seja identificada. Se minhas informações forem insuficientes, diga exatamente o que preciso coletar.
- Baseie as hipóteses no erro e no código que forneci; não invente comportamento de framework, configurações ou números de linha. Deixe claro quando estiver especulando.
- Prefira a menor mudança que corrija a causa raiz em vez de uma reescrita ampla.

Preencha seus dados e o prompt se atualiza na hora — depois é só copiar.

O que você recebe (trecho)

Reformulação: seu endpoint retorna 500 de forma intermitente sob carga, com um erro de pool de conexões esgotado, embora funcione localmente. Causas mais prováveis, em ordem: 1. Conexões não liberadas no caminho de erro — verifique se a falha da query pula a chamada de liberação/fechamento. Reproduza e observe as conexões ativas. 2. Pool pequeno demais para a concorrência real — registre em log as contagens de checkout e check-in por requisição. 3. Uma query lenta mantendo conexões abertas — verifique o log de queries lentas do banco de dados. Próximo diagnóstico: adicione um log em cada aquisição e liberação, depois reproduza com cerca de 20 requisições simultâneas antes de mudar qualquer configuração. Estou especulando sobre a causa 1 até que os logs confirmem.

O fluxo de trabalho completo

  1. Reúna o erro exato, o stack trace e uma reprodução mínima antes de começar
  2. Cole código e logs sanitizados — remova segredos, tokens e hostnames internos
  3. Percorra as hipóteses em ordem, executando você mesmo cada verificação sugerida
  4. Implemente a correção manualmente e adicione um teste que reproduza o bug original

Fique de olho

Logs e stack traces costumam conter segredos, tokens, URLs internas e dados de clientes — remova-os antes de colar, e use uma ferramenta aprovada em vez de uma conta de consumo para qualquer coisa proprietária.

Uma correção confiante mirando na causa raiz errada é pior do que nenhuma correção. Faça o modelo localizar a causa com evidências antes de mudar qualquer coisa, depois reproduza o bug com um teste para saber se ele foi realmente resolvido.

Os modelos inventam comportamentos de framework e opções de configuração plausíveis. Verifique qualquer API, flag ou configuração que ele mencionar na documentação real.

De onde isso vem

Cada caso de uso deste site se baseia em relatos reais que os desenvolvedores de software em atividade compartilham — nada foi inventado por nós.

Mais casos de uso de IA para os desenvolvedores de software

← Todos os 6 casos de uso: como os desenvolvedores de software usam a IA