Plantillas de prompts para depurar problemas de producción

Usa la IA para la depuración de producción como un flujo de trabajo de evidencia a validación: recopila hechos, formula hipótesis, verifícalas, realiza la corrección más pequeña respaldada y valida con seguridad. No pidas a un asistente que parchee un problema activo a partir de un síntoma vago ni apliques el resultado a ciegas.

Las plantillas siguientes mantienen la investigación fundamentada. Elimina secretos, tokens de acceso, datos personales e identificadores de clientes antes de compartir registros o trazas.

La secuencia de depuración en producción

evidencia -> hipótesis -> verificación -> corrección más pequeña -> validación

Cada prompt debe incluir el comportamiento esperado, el comportamiento observado, el entorno, la información de reproducción, los cambios recientes pertinentes y el límite seguro del trabajo solicitado.

Plantilla: triaje inicial de un incidente

Necesitamos investigar un problema de producción. Todavía no propongas un cambio
de código.

Síntomas: [Lo que muestran las personas usuarias o la monitorización.]
Comportamiento esperado: [Lo que debería ocurrir.]
Comportamiento observado: [Lo que ocurre realmente.]
Impacto: [A quién afecta, frecuencia, gravedad y alternativa segura si se conoce.]
Entorno: [Versión, despliegue, navegador/OS, región, feature flags o detalles de
ejecución.]
Cambios recientes: [Despliegues, migraciones, configuración o dependencias pertinentes.]
Evidencia: [Registros depurados, errores, métricas, IDs de traza, capturas de pantalla, comandos.]
Reproducción: [Pasos fiables o indica que es intermitente.]

Devuelve:
1. una cronología concisa de los hechos confirmados;
2. las hipótesis principales ordenadas por probabilidad e impacto;
3. la siguiente observación o paso de reproducción seguro para cada hipótesis;
4. cualquier información faltante que bloquee materialmente el diagnóstico.

Esto proporciona a un asistente material suficiente para razonar sin fingir que tiene acceso a tus sistemas de producción.

Plantilla: reproducir antes de corregir

Intenta reproducir este problema localmente o en el entorno no productivo aprobado.

Esperado: [Resultado esperado.]
Observado: [Resultado real.]
Configuración: [Fixture, estado de cuenta, comando, configuración o datos de prueba.]
Cambio reciente que investigar: [Commit, versión o cambio de comportamiento.]

No edites código de producción hasta que se reproduzca el fallo o tengamos una
explicación basada en evidencia de por qué la reproducción no es posible. Captura
la prueba que falla, la secuencia de registros o la salida de comando más pequeña
que distinga las hipótesis principales.

Si la reproducción es imposible, indica la incertidumbre y recomienda instrumentación segura o una decisión de reversión, no un parche de código especulativo.

Plantilla: analizar registros depurados

Analiza estos registros depurados para detectar un fallo de producción.

Contexto: [Servicio/funcionalidad y flujo de solicitudes esperado.]
Ventana temporal: [Inicio/fin y zona horaria.]
Comportamiento esperado: [Ruta de éxito esperada.]
Comportamiento observado: [Error o comportamiento degradado.]
Cambios recientes: [Cambios de despliegue/configuración/dependencias.]
Registros: [Entradas depuradas en orden cronológico.]

Separa los hechos de las inferencias. Correlaciona eventos solo cuando los IDs,
las marcas de tiempo o la evidencia causal lo respalden. Enumera hipótesis
plausibles, el registro o la métrica que confirmaría cada una y la siguiente
observación de menor riesgo.

No dejes que un asistente trate marcas de tiempo contiguas como prueba de causalidad.

Plantilla: investigar el fallo de un comando o script

Investiga por qué falló este comando de mantenimiento de producción.

Comando: [Comando exacto sin secretos.]
Salida esperada: [Señal de éxito esperada.]
Salida observada: [stderr/stdout depurados exactos y código de salida.]
Entorno: [Shell, directorio de trabajo, versión de OS/ejecución, archivos pertinentes.]
Cambios recientes: [Cambios de script o despliegue.]

Primero explica qué hace realmente el comando e identifica el primer paso que
falla. Propón comandos de diagnóstico seguros que no modifiquen datos. Solo
después de entender el fallo, propone la corrección más pequeña y cómo validarla
en un entorno no productivo.

Para los fallos de terminal, la entrada y salida exactas suelen ser más valiosas que un resumen en prosa.

Plantilla: investigar una regresión de despliegue

Evalúa si esta regresión está relacionada con el despliegue gradual reciente.

Línea base: [Comportamiento/versión anterior al despliegue.]
Cambio: [Versión, flag, migración o diferencia de configuración.]
Regresión observada: [A quién afecta y cómo.]
Evidencia: [Métricas, registros, trazas, capturas de pantalla o una reproducción.]
Restricciones: No cambies el despliegue gradual ni migres datos hasta que la
evidencia respalde una decisión. Conserva la ruta de reversión.

Compara las rutas de la línea base y la modificada. Identifica el experimento,
la comprobación de feature flag o la prueba no productiva más pequeños que puedan
confirmar la causalidad. Recomienda reversión, mitigación o investigación de código
con el grado de confianza y las contrapartidas de cada opción.

La respuesta correcta puede ser una reversión o un ajuste de feature flag, no un cambio de código.

Plantilla: solicitar una corrección segura

Úsala solo después de que la evidencia respalde una causa:

Causa confirmada: [Causa raíz respaldada por evidencia.]
Alcance: [Archivos, módulo o configuración que se deben cambiar.]
Comportamiento que se debe conservar: [Ruta de éxito existente, contrato público,
permisos, datos, configuración regional, rendimiento o comportamiento de reversión.]

Propón la corrección más pequeña. Incluye:
- por qué aborda la causa confirmada;
- la prueba de regresión o comprobación reproducible;
- la validación en un entorno no productivo aprobado;
- consideraciones de despliegue, monitorización y reversión;
- el comportamiento que sigue siendo incierto.

No incluyas refactorización no relacionada en este cambio.

El prompt evita que un incidente real se convierta en una oportunidad para una reescritura imposible de revisar.

Plantilla: validar después de la corrección

Valida la corrección frente al incidente original.

Comprueba:
1. la reproducción original o la prueba que fallaba ahora pasa;
2. la ruta de éxito normal permanece sin cambios;
3. las rutas de error y casos límite pertinentes siguen comportándose con seguridad;
4. las señales de despliegue o monitorización muestran la recuperación esperada;
5. la condición de reversión sigue disponible.

Informa de la evidencia para cada comprobación y nombra explícitamente cualquier
elemento que no se haya verificado.

La validación debe responder la pregunta original del incidente, no limitarse a confirmar que se ejecutó una nueva ruta de código.

Usa la IA como investigadora disciplinada

La IA puede ayudar a organizar evidencia, generar hipótesis, explicar código desconocido y sugerir pruebas. No puede sustituir el control de acceso, la propiedad de incidentes, las salvaguardas de producción ni la revisión humana.

Empieza con cómo escribir mejores prompts para IA para la estructura general. Usa errores de los asistentes de programación con IA y cómo evitarlos para reconocer atajos inseguros, y usa plantillas de prompts para refactorizar código solo después de entender el incidente.

Si la evidencia incluye comandos de shell, reproduce el flujo de trabajo con seguridad antes de cambiarlo. Practica escenarios de línea de comandos en el navegador para crear el hábito de comprobar las señales de entrada, salida y fallo.