Prompt
Eres un ingeniero senior tranquilo que me ayuda a depurar razonando, no entregándome un parche. Actúa como compañero de depuración: ayúdame a encontrar la causa, y deja que yo implemente la corrección.

Qué esperaba que pasara: {{expected}}
Qué pasa en realidad (error exacto, stack trace o salida incorrecta): {{actual}}
Código y entorno relevantes: {{context}}
Qué ya he intentado: {{tried}}

Haz esto:
1. Reformula el problema con tus propias palabras para que pueda confirmar que lo entiendes.
2. Enumera las causas más probables, en orden, cada una con el razonamiento y una comprobación concreta que pueda ejecutar para confirmarla o descartarla.
3. Sugiere el siguiente paso de diagnóstico único: una línea de log, un breakpoint o un experimento mínimo, antes de proponer cualquier corrección.
4. Solo después de haber localizado la causa, sugiere una corrección y explica por qué aborda la causa raíz y no el síntoma.

Reglas:
- No adivines una corrección antes de identificar la causa. Si mi información es insuficiente, dime exactamente qué reunir.
- Basa las hipótesis en el error y el código que proporcioné; no inventes comportamiento del framework, configuración ni números de línea. Indica con claridad cuándo estás especulando.
- Prefiere el cambio más pequeño que corrija la causa raíz frente a una reescritura amplia.

Rellena tus datos y el prompt se actualiza al instante — luego cópialo.

Lo que obtienes (extracto)

Reformulado: tu endpoint devuelve 500 de forma intermitente bajo carga con un error de pool de conexiones agotado, aunque funciona en local. Causas más probables, en orden: 1. Las conexiones no se liberan en la ruta de error: comprueba si el fallo de la consulta se salta la llamada de liberación/cierre. Reproduce y observa las conexiones activas. 2. Pool demasiado pequeño para la concurrencia real: registra los conteos de checkout y check-in por solicitud. 3. Una consulta lenta que mantiene conexiones abiertas: revisa el log de consultas lentas de la base de datos. Siguiente diagnóstico: agrega un log en cada adquisición y liberación, luego reproduce con unas 20 solicitudes concurrentes antes de cambiar cualquier configuración. Estoy especulando sobre la causa 1 hasta que los logs la confirmen.

El flujo de trabajo completo

  1. Reúne el error exacto, el stack trace y una reproducción mínima antes de empezar
  2. Pega código y logs saneados; elimina secretos, tokens y nombres de host internos
  3. Recorre las hipótesis ordenadas, ejecutando tú mismo cada comprobación sugerida
  4. Implementa la corrección a mano y agrega una prueba que reproduzca el error original

Cuidado con

Los logs y stack traces suelen contener secretos, tokens, URLs internas y datos de clientes; sanéalos antes de pegarlos, y usa una herramienta aprobada en lugar de una cuenta de consumo para cualquier cosa propietaria.

Una corrección segura dirigida a la causa raíz equivocada es peor que ninguna corrección. Haz que el modelo localice la causa con evidencia antes de cambiar nada, y luego reproduce el error con una prueba para saber que realmente está resuelto.

Los modelos inventan comportamiento de framework y opciones de configuración plausibles. Verifica cualquier API, flag o ajuste que mencione contra la documentación real.

De dónde sale esto

Cada caso de uso de este sitio se basa en relatos reales de los desarrolladores de software en activo — no lo inventamos nosotros.

Más casos de uso de IA para los desarrolladores de software

← Los 6 casos de uso: cómo los desarrolladores de software usan la IA