Cómo usar Claude para depurar errores complejos en JavaScript
Deja de pelearte con console.log y los foros. Aprende a usar Claude para depurar errores complejos en JavaScript con prompts prácticos que funcionan.
Cómo usar Claude para depurar errores complejos en JavaScript
Mira, colega. Todos hemos pasado por eso: llevas horas con un error en JavaScript que no tiene ni puta lógica, el stack trace no te dice nada útil, y ya has rebuscado en Stack Overflow hasta el punto de que te sabes las respuestas de memoria. Pues deja de perder el tiempo.
Claude es una bestia para depurar, pero solo si sabes cómo pedírselo. No es magia: es saber estructurar el prompt. Aquí van mis trucos de batalla.
El error sin contexto no sirve para nada
Lo primero: no le pegues a Claude un muro de código y le digas "arregla esto". Eso no funciona ni con Claude ni con nadie. Tienes que darle contexto, el error exacto y qué esperas que pase.
Prompt que funciona:
Estoy depurando un error en una app React con TypeScript.
Contexto: es un formulario con validación en tiempo real.
El error: "TypeError: Cannot read properties of undefined (reading 'map')"
Ocurre solo cuando el usuario selecciona una opción del dropdown y luego borra el campo.
Aquí está el código del componente:
[PEGA TU CÓDIGO]
¿Cuál es la causa raíz y cómo lo arreglo sin romper la validación?
¿Ves la diferencia? Le das contexto, el momento exacto en que ocurre, y el comportamiento esperado. Con eso, Claude no adivina: deduce.
Pídele que te explique, no que te lo dé todo hecho
Otro fallo común: querer la solución al primer intento. Claude no es un oráculo, es un colega muy listo. Pídele que razone en voz alta y que te explique el flujo.
Prompt que funciona:
Mira, tengo este array de objetos y un filter que no filtra nada.
El código es este:
const data = [{id: 1, active: false}, {id: 2, active: true}]
const filtered = data.filter(item => item.active = true)
El resultado es que me devuelve todos los objetos, no solo los activos.
¿Qué está pasando aquí? Explícame el problema y luego propón la solución.
Quiero que razones paso a paso antes de darme el código.
Con esto, Claude te explica el clásico error de = vs ===, y además te lo razona. No te da solo el pez, te enseña a pescar.
Depuración por fases: divide y vencerás
Cuando el error es gordo, no intentes resolverlo todo en un prompt. Ve por fases. Primero, que identifique el problema. Luego, que proponga soluciones. Al final, que te dé el código completo.
Prompt que funciona:
Necesito depurar este bug en Node.js. Es un endpoint que a veces devuelve 500 y a veces funciona.
Primera fase: solo quiero que identifiques las posibles causas del error basándote en este código y en el stack trace que te pego. No me des soluciones todavía, solo un análisis de las causas.
[PEGA CÓDIGO + STACK TRACE]
Una vez que tengas las causas, propón la más probable y dime qué pruebas harías para confirmarla.
Así conviertes a Claude en tu compañero de pair-programming, no en un generador de código aleatorio.
El truco definitivo: dale el error y pídele tests
Esto es oro puro. Cuando Claude te proponga una solución, pídele que escriba tests que verifiquen que el bug no vuelve a pasar. Eso te ahorra dolores de cabeza futuros.
Prompt que funciona:
Vale, la solución que me has dado tiene sentido. Ahora escríbeme tests unitarios con Jest que cubran:
1. El caso normal
2. El caso límite que causaba el error
3. Un caso borde que no hemos probado
Quiero tests que fallarían con el código original y que pasen con la solución.
Con esto, no solo arreglas el bug, blindas tu código. Y encima aprendes.
No le tengas miedo a pegar el stack trace completo
Un error común: limpias el stack trace "para que sea más legible". No. Pega el stack trace entero, con todas las líneas. Claude es capaz de seguir la cadena de llamadas y detectar dónde se rompe la cosa.
Prompt que funciona:
Tengo este stack trace de un error en producción:
[PEGA EL STACK TRACE COMPLETO]
El servicio corre en AWS Lambda con Node 18.
No puedo reproducir el error localmente.
¿Qué está fallando? ¿Es un problema de memoria, de timing, o de algo en las dependencias?
¿Qué logs añadirías para diagnosticarlo mejor?
Claude te puede encontrar patrones en stack traces que tú no ves porque llevas horas mirando la misma pantalla.
En resumen
Claude no va a sustituir tu cerebro, pero sí te quita el 80% del trabajo sucio. Dales contexto, pídele razonamiento, ve por fases, y que te escriba tests. Ah, y no seas vago: pega el código completo, no un resumen. La información que le des marca la diferencia entre una respuesta genérica y la solución exacta a tu problema.
Y tú, ¿qué haces cuando un bug te come la cabeza? ¿Sigues buscando en foros o ya le has pillado el truco a Claude? Cuéntame en los comentarios.


