Cómo hacer que Claude Code arregle sus propios errores

Le pides un cambio, lo hace, recargas la página y en vez de tu web hay un texto rojo lleno de líneas raras.

Ahí es donde mucha gente cierra el portátil y decide que esto de programar con IA no era para tanto.

Y lo curioso es que ese momento es el mejor de todos. Ese texto rojo que da tanta impresión es información pura: dice qué ha fallado, dónde y por qué. Es el mejor material que le vas a dar a la IA en toda la tarde. Solo hay que saber cómo dárselo.

¿Qué hago cuando la IA rompe algo y no sé arreglarlo?

Copiarlo todo y pegárselo. Todo, no un trozo.

Ese es el noventa por ciento de la solución y es donde falla casi todo el mundo, porque el instinto es escribir "me da un error, arréglalo". Y con eso el modelo no tiene nada. Se pone a adivinar, cambia cosas al azar, y de ahí sale la sensación de que empeora todo lo que toca.

El error tiene información concreta: un mensaje, el nombre del archivo, el número de línea y a veces una lista de por dónde ha pasado el programa antes de romperse. Cada una de esas cosas reduce el espacio de búsqueda. Si le quitas todo eso y le dejas "no funciona", le has quitado el mapa.

Así que copia. Desde la primera línea del error hasta la última, aunque sean cuarenta líneas y aunque no entiendas ninguna. Tú no tienes que entenderlo. Solo pegarlo.

Y si aún no has usado nunca Claude Code, esto tiene más sentido después de leer la guía para no programadores.

Paso 1: saber dónde está el error

Los errores no salen todos en el mismo sitio, y esto se aprende una vez y ya no se olvida.

En la terminal, donde tienes el proyecto arrancado. Si la web ni siquiera carga, mira ahí. Suele ser el error más útil de todos porque viene entero.

En la consola del navegador. Si la página carga pero algo no funciona (un botón que no hace nada, una lista que no aparece), el error está ahí. Se abre pulsando la tecla F12 o con clic derecho e "Inspeccionar", y luego a la pestaña "Consola". Las líneas rojas son las tuyas.

En la pantalla directamente. Algunos proyectos te enseñan el error encima de la página, con el archivo y la línea. Ese es el más cómodo.

Aprender estos tres sitios te ahorra la frustración de decir "no funciona" sin poder decir nada más.

Paso 2: la instrucción que sí funciona

No basta con pegar el error a secas. Lo que a mí me da mejores resultados es esto:

"Me sale este error después del último cambio. Aquí lo tienes entero:

(pegas todo)

Antes de tocar nada, dime qué crees que lo ha causado y qué archivos vas a mirar. No cambies nada todavía."

Ese "no cambies nada todavía" es lo importante y es contraintuitivo. Lo que consigues es que primero diagnostique y luego actúe, en vez de ponerse a parchear a lo bruto.

Además, cuando te explica qué cree que ha pasado, tú puedes darte cuenta de que va por mal camino antes de que toque quince archivos. Muchas veces le digo "no, eso ya funcionaba antes, mira mejor lo que cambiaste hace dos mensajes". Y acierta a la primera.

Paso 3: cuando arregla una cosa y rompe otra

Este es el bucle de la desesperación y hay que saber cortarlo.

Arregla el error uno. Aparece el error dos. Arregla el dos y vuelve el uno. Tres vueltas así y el proyecto está peor que al principio.

Cuando pasa esto, para. Y cambia de estrategia:

"Llevamos tres intentos y cada arreglo rompe otra cosa. Vamos a parar. Explícame cómo funciona esta parte del proyecto, qué depende de qué, y por qué estos dos errores están relacionados. No propongas ninguna solución todavía."

Lo que hace ese cambio es sacarlo del modo parche. Casi siempre resulta que el problema real es otro, más de fondo, y que los dos errores eran síntomas.

Y si aun así no sale: deshaz. Vuelve al último punto donde funcionaba y empieza el cambio de otra manera. Eso no es rendirse, es lo que hace cualquiera que lleve tiempo en esto. Lo explico en los puntos de guardado y la marcha atrás, que es lo que convierte cualquier destrozo en un contratiempo de dos minutos.

Paso 4: los errores que no dan error

Los peores no son los rojos. Son los silenciosos.

La página carga, todo parece bien, y resulta que el formulario no está guardando nada. O que el precio se calcula mal. No hay texto rojo en ninguna parte porque, técnicamente, nada ha fallado. Simplemente hace algo distinto de lo que querías.

Para esos, la instrucción es otra:

"Cuando relleno el formulario y le doy a enviar, no aparece nada en la base de datos y tampoco sale ningún error. Repasa el camino completo que sigue el dato desde que se escribe hasta que se guarda y dime en qué punto se está perdiendo."

La palabra clave es "el camino completo". Sin eso mira solo el botón, que es lo último que has tocado, y el problema suele estar tres pasos más atrás.

Estos errores son también el motivo por el que merece la pena tener comprobaciones automáticas aunque no seas programador. Lo cuento en cómo poner tests sin saber testear: son pequeños programas que revisan solos que lo importante sigue funcionando, y te avisan cuando algo se rompe por dentro.

Paso 5: que aprenda de los errores repetidos

Si un tipo de error te sale tres veces, no lo arregles una cuarta. Documéntalo.

En el archivo de instrucciones del proyecto, ese que Claude Code lee cada vez que abres la carpeta, añade una línea:

"En este proyecto, las fechas se guardan siempre en este formato. No uses otro."

"Antes de dar por terminado cualquier cambio en el formulario, comprueba que sigue guardando."

Cada línea de esas es un error que no vuelve a pasar. Yo tengo proyectos donde ese archivo tiene veinte líneas de estas, y cada una nació de una tarde perdida.

Lo que se te va a atascar

Pegar solo la primera línea del error. La causa real casi siempre está más abajo, en la parte que parece ruido. Copia todo.

Recortar los nombres de archivo. Vienen unas rutas largas y feas y da la sensación de que sobran. No sobran. Son las que le dicen dónde mirar.

Arreglar sin entender. Cuando lo arregle, pídele que te explique en una frase qué pasaba. Cuesta diez segundos y a la tercera vez ya reconoces el patrón tú solo.

El error que en realidad no es tuyo. A veces el fallo viene de una pieza externa desactualizada o de un servicio que está caído. Si el error menciona algo que tú no has escrito nunca, dilo: "esto viene de una librería, ¿es un problema de versión?".

Aceptar que reescriba medio proyecto. Si para arreglar un botón te propone tocar doce archivos, párale. Pregunta por qué. Un error pequeño se arregla con un cambio pequeño, y si no es así es que el diagnóstico está mal.

Y ahora qué

El cambio de mentalidad que a mí me hizo dejar de sufrir con esto: los errores no son una señal de que lo estás haciendo mal. Son parte del trabajo, también para quien lleva veinte años programando. La diferencia es que ellos ya no se asustan.

Y ahora, además, tienes al lado algo que se lee el error y te dice qué pasa. Con eso, el error rojo pasa de ser un muro a ser el paso siguiente.

La única condición innegociable: tener marcha atrás siempre. Con eso, lo peor que puede pasar es que pierdas media hora. Sin eso, lo peor que puede pasar es que pierdas el proyecto.

Si quieres el recorrido completo, desde la carpeta vacía hasta tu web publicada y tú resolviendo los problemas que salgan por el camino, lo tengo montado paso a paso.

Ver el curso de crear tu web con Claude Code