Utilidades IACómo depurar código con la ayuda de un asistente de IA
| Para quién | Para quien se ha topado con un error que no entiende o un comportamiento inesperado y quiere un método ordenado para encontrar la causa en lugar de probar cambios al azar. |
|---|---|
| Tiempo estimado | 10 a 90 minutos según la dificultad del fallo y lo fácil que sea reproducirlo |
| Categoría | Programación y datos |
Paso a paso
- Reproduce el fallo de forma fiable
Antes de pedir ayuda, consigue que el error ocurra siempre del mismo modo. Anota los pasos exactos, la entrada que lo provoca, el entorno (sistema operativo, versión del lenguaje, versiones de librerías) y qué esperabas que pasara en lugar de lo que pasó. Si el fallo es intermitente, apunta con qué frecuencia ocurre y qué cambia entre ejecuciones. Un fallo reproducible es la mitad del trabajo resuelto, con o sin ayuda de una IA. - Reduce el problema al mínimo
Elimina todo lo que no sea necesario para que el fallo aparezca hasta obtener un ejemplo mínimo: unas pocas líneas que lo reproduzcan por sí solas. Este proceso suele revelar la causa por sí mismo, y si no, te permite compartir un fragmento corto en lugar de cientos de líneas. Sustituye datos reales por valores inventados con la misma forma. Un ejemplo pequeño también reduce el riesgo de exponer información confidencial. - Reúne el mensaje de error completo
Copia el error íntegro, incluida la traza de llamadas con números de línea, no un resumen. Añade el fragmento de código alrededor de las líneas señaladas y cualquier registro relevante. Revisa antes de pegar que no contiene rutas internas sensibles, claves, tokens o datos personales, y sustitúyelos por marcadores. La traza completa permite al asistente distinguir entre un fallo propio del código y uno causado por una librería o la configuración. - Pide hipótesis ordenadas, no solo un arreglo
En lugar de pedir directamente la corrección, solicita una lista de posibles causas ordenadas por probabilidad, con una forma concreta de comprobar cada una (imprimir un valor, añadir un registro, ejecutar con un depurador). Así aprendes dónde mirar y evitas aplicar un parche que oculta el síntoma. Si el asistente propone un cambio, pídele que explique por qué esa causa produciría exactamente el error observado. - Aplica un cambio cada vez
Prueba las hipótesis de una en una y vuelve a ejecutar tras cada cambio. Si modificas varias cosas a la vez, no sabrás cuál arregló el problema ni cuál introdujo uno nuevo. Trabaja en una rama o con una copia, para poder volver atrás. Cuando una propuesta no funcione, devuelve al asistente el resultado nuevo, el error actual y lo que ya has descartado, para que no repita la misma idea. - Confirma la causa y añade una prueba
Cuando el error desaparezca, asegúrate de entender por qué. Si no puedes explicar la causa con tus palabras, es posible que hayas tapado el síntoma. Escribe una prueba automática que fallaba antes del cambio y ahora pasa, para evitar regresiones. Ejecuta el resto de pruebas y revisa que la corrección no altera otros comportamientos. Anota en el commit el motivo del fallo y la solución adoptada.
Prompt de ejemplo
Cambia lo que está entre corchetes por tu situación:
Quiero depurar un error en [LENGUAJE Y VERSIÓN] con [FRAMEWORK O LIBRERÍAS Y VERSIONES]. Comportamiento esperado: [QUÉ DEBERÍA PASAR] Comportamiento real: [QUÉ PASA EN SU LUGAR] Pasos para reproducirlo: [PASOS NUMERADOS] Mensaje de error completo: [PEGA AQUÍ LA TRAZA COMPLETA, SIN SECRETOS] Fragmento de código relacionado: [PEGA AQUÍ EL EJEMPLO MÍNIMO] Lo que ya he probado: [INTENTOS DESCARTADOS] No me des directamente un parche. Primero enumera las tres causas más probables ordenadas por probabilidad y, para cada una, indica cómo comprobarla con una prueba concreta. Después propón la corrección para la causa más probable, explica por qué produce este error y sugiere una prueba automática que lo detecte en el futuro. Si te falta información, dime qué necesitas.
Qué esperar
Con un error bien descrito, es frecuente que el asistente identifique pistas útiles o una causa probable, sobre todo en fallos comunes. En errores que dependen de tu entorno, de datos reales o de condiciones de carrera, puede equivocarse y tendrás que aportar más información y comprobar cada hipótesis.
Cómo verificar el resultado
- Volver a ejecutar los pasos de reproducción y confirmar que el error ya no aparece.
- Escribir una prueba que falle con el código antiguo y pase con el nuevo.
- Ejecutar toda la batería de pruebas existente para detectar efectos secundarios de la corrección.
- Probar en un entorno aislado con datos de ejemplo parecidos a los reales antes de desplegar nada.
Errores comunes
- Pegar solo la última línea del error y no la traza completa ni el código asociado.
- Aplicar varios cambios a la vez sin saber cuál resolvió el problema.
- Aceptar un parche que silencia la excepción en lugar de corregir la causa.
- Compartir en el mensaje claves, tokens o datos de clientes que aparecían en los registros.
Riesgos y límites
El asistente puede proponer una causa plausible pero equivocada, o inventar funciones y opciones de configuración que no existen en tu versión. Sin ver tu entorno real, trabaja con la información que le das. Los registros y las trazas suelen contener datos sensibles como rutas, direcciones, identificadores, tokens o contraseñas: revísalos y anonimízalos antes de pegarlos, y respeta la política de tu organización sobre qué código puede compartirse. Un arreglo que parece funcionar puede ocultar una vulnerabilidad o un fallo más profundo, así que valida siempre con pruebas.
Preguntas frecuentes
¿Qué hago si la solución propuesta no funciona?
Vuelve a la conversación con el nuevo resultado: el error actual, qué cambiaste y qué observaste. Pide otra hipótesis distinta, no la misma reformulada. Si tras dos o tres intentos no avanzas, reduce aún más el ejemplo o usa un depurador para obtener datos propios.
¿Puedo pegar mi código completo para que lo revise?
Conviene evitarlo. Comparte el fragmento mínimo necesario y elimina secretos, datos personales y detalles internos. Además de ser más seguro, un ejemplo reducido suele dar respuestas más precisas porque el asistente se centra en lo relevante.
¿Sustituye a un depurador o a las pruebas?
No. El asistente ayuda a interpretar y a plantear hipótesis, pero el depurador, los registros y las pruebas son lo que te da evidencia real de lo que ocurre en tu programa. Úsalos como complemento, no como alternativa.