Cómo deshacer lo que la IA ha roto en tu proyecto sin sufrir por ello

Hay un momento en la vida de todo el que usa IA para construir cosas. Le pides un cambio pequeño, le das a enter, te vas a por agua, vuelves y el proyecto no arranca.

Y entonces empieza lo peor: intentar arreglarlo pidiéndole a la misma IA que lo arregle. Que es como pedirle al que te ha pintado la pared que la despinte. A veces sale. A veces acabas con dos capas de pintura y la pared peor.

La solución no es que la IA se equivoque menos. Es tener una forma de volver al minuto anterior. Y eso se monta en cinco minutos el primer día.

¿Cómo vuelvo atrás si la IA me destroza el proyecto?

Con tres redes de seguridad a distintas alturas, y usando la más barata primero.

La primera es el rewind de la propia herramienta, que deshace lo que acaba de hacer. La segunda son los puntos de guardado del proyecto, que te devuelven a un estado que tú marcaste como bueno. La tercera es la copia en la nube, que te salva incluso si borras la carpeta entera.

Casi todo el mundo tiene cero de las tres el día del primer susto. Vamos a que tengas las tres antes de que llegue.

Red 1: el rewind de Claude Code

Claude Code

Cuando algo se ha ido de madre, no le pidas que lo arregle. Rebobina. Pulsando la tecla de escape dos veces seguidas te aparece la lista de puntos anteriores de la conversación y puedes volver a uno.

Lo que tienes que entender de esto, y es lo que confunde a todo el mundo: rebobinar puede devolverte el chat, los archivos o las dos cosas. No es lo mismo. Si vuelves solo el chat, los archivos siguen rotos. Si vuelves las dos cosas, es como si esos últimos minutos no hubieran existido.

Mi regla: en cuanto veo que va por mal camino, corto y rebobino. No espero a que termine "por si acaba bien". Nunca acaba bien.

Red 2: los puntos de guardado del proyecto

El rewind es de la sesión. Si cierras y vuelves mañana, esa red ya no está.

Para eso está la segunda: guardar el estado del proyecto cuando funciona. En el mundo del desarrollo esto se llama hacer un commit, y suena mucho más complicado de lo que es.

La versión sin jerga: le dices a Claude "guarda el estado actual del proyecto con el mensaje 'funciona el formulario de contacto'" y él lo hace. No tienes que aprenderte comandos ni entender qué pasa por debajo. Solo tienes que coger la costumbre de decirlo.

¿Cuándo? Cada vez que algo funcione. Literalmente. Acabas de conseguir que se vea bien la página de inicio, guardas. Consigues que se envíe el formulario, guardas. Tardas diez segundos y te compras la posibilidad de volver a ese punto exacto dentro de tres semanas.

Y cuando la has liado, la frase es igual de tonta: "vuelve al último punto guardado". Ya está. Todo el proceso de gestionar versiones sin saber nada de esto lo desmenuzo en Claude Code y GitHub sin saber Git.

Red 3: la copia que vive fuera de tu ordenador

Las dos anteriores viven en tu máquina. Si se te muere el disco, se te va todo igual.

Subir el proyecto a un repositorio remoto es la tercera red. Y es la que además te da el historial completo: puedes ver qué cambió cada día, y volver a cualquier punto de hace meses.

Se monta una vez y luego es una frase más: "sube los cambios". Con eso el proyecto está en dos sitios.

La costumbre que lo cambia todo: guardar antes, no después

Aquí va lo que de verdad marca la diferencia y no tiene nada que ver con herramientas.

Antes de pedirle a la IA algo gordo (rehacer el diseño, cambiar cómo funciona una parte entera, tocar varios archivos a la vez), guardas. Antes. No después.

Porque el problema de guardar después es que solo te acuerdas de guardar cuando algo ha ido bien. Y cuando va mal, que es cuando lo necesitas, tu último punto de guardado es de hace dos horas y has perdido dos horas de trabajo bueno junto con los cinco minutos de trabajo malo.

Yo lo tengo automatizado en la cabeza: cambio grande igual a guardar. Es el equivalente a mirar antes de cruzar. No lo piensas, lo haces.

Cuándo conviene abrir una rama aparte

Hay un caso donde ni el rewind ni volver al último punto guardado son la respuesta: cuando quieres probar algo gordo sin comprometer lo que ya funciona.

Rehacer el diseño entero, cambiar cómo está montada una parte importante, probar una idea que no sabes si va a salir. Para eso está la rama: una copia paralela del proyecto donde experimentas a gusto.

Si sale bien, la juntas con la principal. Si sale mal, la borras y no ha pasado nada. Tu proyecto bueno ni se ha enterado.

Y también se pide hablando: "crea una rama para probar el rediseño de la portada". No necesitas saber nada más para usar esto, aunque sea la herramienta más potente de las tres.

Lo que se te va a atascar

Rebobinas y los archivos siguen rotos. Has vuelto solo la conversación. Vuelve a hacerlo eligiendo restaurar también los archivos.

No sabes en qué punto estaba bien. Es lo que pasa cuando los mensajes de guardado son "cambios" y "más cambios". Escribe qué funcionaba: "página de contacto enviando correos". Tu yo de dentro de un mes te lo agradece.

Guardaste con el proyecto ya roto. Pasa. No es grave: los puntos anteriores siguen ahí. Vuelve a uno de antes, no al último.

Le pides que arregle en vez de volver atrás. Es el error más caro de todos. Cada intento de arreglo añade cambios encima del desastre y hace que volver sea más difícil. Si dos intentos no lo arreglan, rebobina y replantea la petición desde el estado bueno. Sobre cuándo dejarle arreglar y cuándo no, escribí aparte en dejar que Claude Code arregle sus propios errores.

Archivos que no están guardados. Las claves, las contraseñas y los archivos de configuración local muchas veces se quedan fuera a propósito. Eso significa que volver atrás no te los devuelve. Ten una copia de esos aparte, en tu gestor de contraseñas.

Y ahora qué

Ahora mismo, sin esperar al primer susto: abre tu proyecto y dile que lo guarde con un mensaje claro. Si nunca lo has subido a ningún sitio, dile que lo suba.

Cinco minutos. Y a partir de mañana, la costumbre: antes de cada cambio grande, guardas.

La diferencia entre la gente que abandona esto a las dos semanas y la que sigue un año después casi nunca es el talento. Es que unos perdieron un proyecto entero y otros pudieron volver atrás y seguir. Si estás empezando desde cero con esto, la guía de Claude Code para no programadores te ordena todo lo demás.

Todo esto y bastante más lo enseño paso a paso, con proyectos reales, en el curso de crear tu web con Claude Code.

Ese cambio de mentalidad, además, se nota en cómo le pides las cosas. Cuando sabes que puedes volver atrás en diez segundos, te atreves a pedirle cambios grandes. Cuando no lo sabes, vas con miedo y le pides cosas pequeñitas que no llevan a ningún sitio. La red de seguridad no es solo para cuando algo sale mal: es lo que te deja trabajar rápido el resto del tiempo.

Ver el curso