Stack trace a diagnóstico: ChatGPT, Claude y Gemini | OpenWebinars

Cómo investigar un error con ChatGPT, Claude o Gemini

Con el stack trace y el contexto inicial delante, ya podemos utilizar la IA como apoyo al diagnóstico. El objetivo no es conseguir una respuesta definitiva en el primer prompt, sino reducir progresivamente el espacio de hipótesis y convertir cada explicación en algo que pueda comprobarse.

El método funciona con ChatGPT, Claude o Gemini. Lo importante es aportar contexto suficiente, exigir que distingan hechos de suposiciones y contrastar después sus propuestas con el sistema real.

Prepara la traza y el contexto mínimo necesario

Empieza por compartir la traza completa relevante, no solo la última línea de la excepción. Añade también el fragmento de código directamente implicado y la información mínima necesaria para entender qué debería estar ocurriendo.

Para nuestro ejemplo ficticio, partimos de este stack trace:

Traceback (most recent call last):
  File "orders.py", line 84, in process_order
    customer = get_customer(order["customer_id"])
  File "customers.py", line 41, in get_customer
    return customers[customer_id]
KeyError: 'C-1842'

En Python, un KeyError indica que la clave solicitada no se encuentra entre las existentes en el mapping consultado. Eso explica qué ocurre en esa operación, pero todavía no por qué C-1842 no está disponible en customers.

Podemos añadir el fragmento de código directamente relacionado:

def process_order(order):
    customer = get_customer(order["customer_id"])
    return create_invoice(order, customer)

def get_customer(customer_id):
    return customers[customer_id]

Y dos datos de contexto: el pedido llega desde una API y customers se carga previamente desde una fuente de datos interna.

No necesitas pegar el repositorio completo. Si trabajas con código corporativo, logs o configuraciones, revisa además qué puedes compartir y elimina secretos, credenciales o datos innecesarios antes de introducir información sensible en un prompt.

Pide hipótesis y comprobaciones, no una solución directa

Un prompt como “soluciona este error” empuja al modelo hacia una respuesta prematura. Es más útil pedirle que organice la investigación y haga explícito qué parte de su razonamiento procede de la evidencia disponible.

El objetivo es que cada explicación venga acompañada de una comprobación concreta. Si el modelo propone que customers está incompleto, debería indicar qué dato permitiría reforzar esa hipótesis y cuál serviría para debilitarla o descartarla.

Prompt para separar hechos e hipótesis

Puedes utilizar una instrucción como esta:

Instrucción para la IA: Analiza este stack trace y el contexto proporcionado. Separa claramente: 1) hechos que pueden afirmarse directamente a partir de la información disponible, 2) inferencias o causas posibles, y 3) datos que faltan para distinguir entre esas hipótesis. No propongas todavía una corrección. Para cada causa posible, indica qué comprobación permitiría reforzarla o descartarla.

Al revisar la respuesta, comprueba que el modelo no haya añadido componentes inexistentes ni presente como hecho algo que solo está suponiendo.

Organiza las causas posibles en una matriz de investigación

Convierte las hipótesis en una tabla que relacione cada explicación con evidencias y pruebas concretas.

Hipótesis	Indicio inicial	Qué comprobar	Qué la descartaría	Estado
El pedido contiene un customer_id incorrecto	La búsqueda de C-1842 falla en la colección customers	Comparar el identificador recibido con el cliente esperado y la fuente principal	El identificador recibido corresponde al cliente esperado en la fuente principal	Pendiente
El cliente existe pero no fue cargado en customers	La búsqueda falla en la colección en memoria	Comparar la fuente principal con el contenido cargado	El identificador tampoco existe en la fuente principal	Pendiente
Dos sistemas utilizan identificadores distintos	El pedido llega desde una API externa	Comparar el identificador recibido con el mapeo interno	Ambos sistemas utilizan exactamente el mismo identificador	Pendiente
Existe un problema de orden de ejecución	El procesamiento depende de que customers se haya cargado previamente	Revisar logs y secuencia de inicialización	La colección está completamente cargada antes de ejecutar process_order	Pendiente

La columna Estado no debería pasar directamente de Pendiente a Confirmada. Resultan más útiles estados como Compatible con la evidencia, Debilitada, Descartada o Mejor respaldada.

Contrasta cada hipótesis con código, logs y comportamiento real

Supongamos que revisamos el payload y encontramos customer_id: "C-1842". Después consultamos la fuente principal y comprobamos que ese cliente sí existe, pero no aparece en la colección customers cargada por la aplicación.

Con esa nueva evidencia:

• La hipótesis de identificador incorrecto pierde fuerza.
• Que el cliente no se haya cargado pasa a estar mejor respaldado.
• La hipótesis de identificadores incompatibles sigue abierta hasta revisar cómo se construye la colección.
• El posible problema de orden de ejecución tampoco puede descartarse sin comprobar los logs de inicialización.

Cuando trabajas con sistemas que no conoces bien, antes de modificar una línea conviene entender el comportamiento real del código y contrastarlo con configuración, dependencias, tests y datos de ejecución.

Prompt para actualizar el diagnóstico

Cuando obtengas nueva evidencia, puedes pedir al modelo que revise la investigación:

Instrucción para la IA: Actualiza las hipótesis utilizando esta nueva evidencia. Indica cuáles se fortalecen, cuáles se debilitan y cuáles pueden descartarse. Explica qué dato concreto produce cada cambio y qué comprobación sigue siendo necesaria. No propongas todavía una corrección si varias causas siguen siendo compatibles con la evidencia.

Así obligamos al modelo a revisar el diagnóstico en lugar de mantener automáticamente su primera explicación.

Utiliza un segundo modelo para cuestionar la hipótesis dominante

Que ChatGPT, Claude y Gemini lleguen a explicaciones similares no confirma una causa: pueden estar razonando sobre la misma evidencia incompleta. Un segundo modelo aporta más valor si le pedimos que intente debilitar la hipótesis dominante.

Instrucción para la IA: La hipótesis actualmente mejor respaldada es que el cliente existe en la fuente principal pero no se carga correctamente en la colección utilizada por la aplicación. Busca explicaciones alternativas compatibles con las mismas evidencias. Indica qué dato podría demostrar que esta hipótesis dominante es incorrecta y qué comprobación realizarías antes de modificar el código.

Si descubre una explicación compatible que no habías considerado, ganas una nueva vía de investigación. Si no lo hace, la hipótesis puede seguir siendo la mejor respaldada, pero la coincidencia entre modelos no sustituye a la evidencia del sistema.

Cómo saber si tienes un diagnóstico suficientemente respaldado

Después de varias comprobaciones es fácil sentir que una hipótesis “encaja” y dar por terminada la investigación. Pero una causa probable todavía puede competir con otras explicaciones capaces de producir el mismo síntoma.

No necesitas eliminar toda incertidumbre antes de actuar, pero sí reunir suficiente evidencia para justificar por qué una causa explica mejor el fallo que sus alternativas.

Qué evidencia aumenta la confianza en una causa

Una hipótesis gana fuerza cuando distintas evidencias apuntan en la misma dirección. En el ejemplo anterior, descubrir que C-1842 existe en la fuente principal pero falta en customers es más informativo que limitarse a observar el KeyError.

Antes de considerar una causa bien respaldada, busca señales como estas:

• La hipótesis explica el stack trace completo, no solo la última excepción.
• El código y los datos reales muestran la condición que produciría el fallo.
• Los logs o la reproducción del problema son compatibles con esa explicación.
• Otras hipótesis razonables han perdido fuerza o pueden descartarse con evidencia.
• La causa permite anticipar qué debería cambiar si se elimina la condición que origina el error.

Una hipótesis sólida debería permitir hacer alguna predicción comprobable sobre el comportamiento del sistema.

Cuándo todavía faltan datos para cerrar el diagnóstico

Hay momentos en los que lo más correcto es mantener varias hipótesis abiertas. Que una explicación sea la mejor disponible no significa que tengamos evidencia suficiente para modificar el código.

Por ejemplo, si sabemos que el cliente falta en customers, pero desconocemos por qué no se cargó, corregir get_customer para ignorar la ausencia podría ocultar el síntoma sin resolver el origen del problema.

Conviene seguir investigando cuando:

• Varias causas siguen siendo compatibles con las mismas evidencias.
• La explicación depende de supuestos sobre datos, configuración o ejecución que todavía no has comprobado.
• No puedes reproducir el comportamiento ni identificar las condiciones en las que aparece.
• La solución propuesta corrige la excepción, pero no explica por qué el sistema llegó a ese estado.

En estos casos, la IA puede ayudarte a decidir qué información buscar después, pero la evidencia todavía no permite cerrar el diagnóstico.

Qué comprobar antes de modificar el código

Antes de aplicar una corrección, relaciona el cambio propuesto con la causa que intentas resolver.

Si nuestra investigación demuestra que customers se construye antes de que termine la carga de datos, la corrección debería actuar sobre esa secuencia o sobre la condición que la provoca. Añadir simplemente un try/except alrededor del acceso podría evitar el KeyError, pero no corregir necesariamente el fallo original.

Antes de tocar el código, comprueba al menos que:

• Puedes explicar qué condición provoca el error y dónde se origina.
• El cambio propuesto actúa sobre esa condición y no únicamente sobre su síntoma.
• Sabes qué comportamiento esperas observar después de la corrección.
• Existe alguna forma de verificar el resultado, mediante una reproducción controlada, un test o evidencia equivalente.
• Has considerado si el cambio puede introducir efectos secundarios en otros recorridos del sistema.

La IA puede ayudarte a estructurar la investigación, pero la decisión de modificar el código debe apoyarse en la evidencia obtenida del sistema real.

Conclusiones

Un stack trace puede acotar mucho una investigación, pero rara vez demuestra por sí solo la causa de un fallo. ChatGPT, Claude o Gemini resultan más útiles cuando ayudan a formular y ordenar hipótesis que cuando intentan saltar directamente a una corrección.

El diagnóstico gana solidez al incorporar nuevas evidencias: código, logs, configuración, datos de entrada, tests y comportamiento reproducible. Cada comprobación debería servir para fortalecer, debilitar o descartar una explicación hasta que una causa quede mejor respaldada que sus alternativas.

La IA puede acelerar ese proceso, señalar contexto que falta o cuestionar una hipótesis dominante. Pero el punto de cierre sigue estando fuera del modelo: antes de modificar el código, necesitas poder explicar qué condición provoca el error, qué evidencia la sostiene y cómo comprobarás que el cambio realmente la corrige.