Depura con hipótesis comprobables

Describe el fallo antes de proponer una corrección

Una petición útil de depuración indica el comportamiento esperado, el observado y el alcance afectado. Incluye la versión, la entrada pertinente y el error. Elimina las credenciales y los registros privados de los logs antes de proporcionarlos a una herramienta de IA.

«La exportación no funciona» orienta poco. Una descripción mejor es: «La exportación funciona en local. En staging, la misma solicitud de un responsable devuelve 403 desde el último despliegue. Las demás rutas siguen funcionando».

Esta descripción no establece la causa. Identifica diferencias que pueden orientar la investigación.

Mantén abiertas varias explicaciones

Pide al agente un conjunto pequeño de causas plausibles y las pruebas que respaldan cada una. No le pidas que se comprometa con la primera explicación convincente.

En el fallo ficticio de exportación, las causas posibles incluyen un permiso ausente en la identidad de servicio, un cambio en la asignación de roles o una solicitud enviada al entorno equivocado. Cada explicación predice pruebas distintas.

La tabla es un punto de partida. Una respuesta 403 puede proceder de distintas capas. Identifica qué componente la produjo antes de suponer que falló la autorización de la aplicación.

Elige una observación segura

Empieza por una observación que permita distinguir explicaciones con poco coste. Compara la versión desplegada y la configuración que no contiene secretos. Inspecciona el error pertinente y el identificador de solicitud. Cuando sea posible, reproduce el problema en un entorno de pruebas autorizado.

No concedas permisos amplios solo para ver si desaparece el error. Esa acción cambia el límite de seguridad y puede ocultar el permiso que realmente falta. No pegues un log completo de producción en el modelo cuando basten un error sin datos sensibles y la ruta de solicitud.

Indica qué debilitaría cada hipótesis. Esto ayuda al agente a revisar su explicación en lugar de defender su primera respuesta.

Cambia una causa cada vez

Cuando las pruebas identifiquen una causa probable, aplica una corrección concreta. Evita combinar un cambio de permisos, una actualización de biblioteca y una reescritura del manejador. Si el síntoma desapareciera, no sabrías qué cambio fue relevante.

Verifica la condición original del fallo. Comprueba también el límite cercano. Si corriges el acceso de un responsable, confirma que un usuario no autorizado siga recibiendo una denegación.

Para un defecto recurrente, añade una comprobación de regresión en la capa que pueda detectarlo. Una prueba unitaria no detecta todos los errores de configuración de despliegue. Algunos fallos necesitan una comprobación de integración o una verificación controlada después del despliegue.

Detén los intentos repetidos sin pruebas nuevas

Un agente puede generar muchas variantes de una corrección. Más intentos no mejoran necesariamente el diagnóstico. Si se repite el mismo fallo, pregunta qué observación nueva aportará el siguiente intento.

Fija un límite de tiempo o de intentos para una investigación incierta. Al alcanzarlo, informa de las pruebas actuales, las hipótesis descartadas y la pregunta sin resolver. Este registro permite que otra persona continúe sin repetir los mismos experimentos.

Después de la recuperación, registra la causa y la condición que permitió que llegara al entorno afectado. Una corrección elimina el defecto inmediato. Un seguimiento útil reduce la probabilidad de que vuelva el mismo fallo.