Muchas personas usan Claude Code para programar, en realidad todavía se quedan en "donde está roto, lo reparo allí".

Esta también es una de las formas más fáciles de arruinar un proyecto, yo también en estos días he estado siguiendo las ideas de los expertos y modificando y perfeccionando el proyecto continuamente.
Porque los bugs en proyectos reales, generalmente no son un pequeño agujero aislado.
Cuando ves errores, anomalías en la página, o que un botón deja de funcionar, en la mayoría de los casos solo son un pico que surge de un problema del sistema.
Si simplemente le entregas ese pico a la IA y dices "ayúdame a arreglarlo", probablemente solo te ayude a limar ese pico.
A simple vista parece estar arreglado, pero la lógica subyacente no ha sido modificada.
La próxima vez, en un escenario diferente, el mismo problema vuelve a explotar.
Y en la siguiente, sigues añadiendo correcciones, en realidad todos son errores de lógica iguales.
Al final, el código está lleno de parches, el proyecto puede correr cada vez más, pero también cada vez da menos confianza para modificarlo.
Por eso ahora, cuando uso Claude Code, tengo un hábito muy importante:
No le pido que cambie el código de inmediato, primero le hago que analice por qué ocurre el problema.
Yo prefiero preguntar así:
Primero, no lo arregles.
Ayúdame a analizar la causa raíz de este problema.
¿Podría ser un problema en alguna capa de diseño, flujo de estado, estructura de datos o condiciones límite?
En ese momento, el rol de la IA cambia.
No es un "subcontratista para arreglar bugs", sino un "ayudante para investigar el sistema".
Esa diferencia es muy grande.
Lo que le das tampoco debe ser solo un mensaje de error, sino que debe incluir el contexto completo: archivos relacionados, cadena de llamadas, ruta de operaciones del usuario, resultado esperado, resultado real, qué cambios se han hecho antes.
Cuanto más completo sea el contexto, más probable será que te ayude a ver el problema real, en lugar de solo poner parches en la superficie.