Un agente puede cambiar diez ficheros en un minuto. Para usarlo con tranquilidad: commit y rama antes, encargo con límites, revisión del diff y cómo deshacer lo que no quieres.
Antes de pedirle nada a un agente, deja el proyecto en un commit limpio y crea una rama solo para ese encargo.
Un buen encargo es pequeño y tiene límites: qué ficheros puede tocar, qué no debe hacer y cuándo está terminado.
Revisa siempre el diff: primero qué ficheros cambiaron (git diff --stat) y después las líneas, fichero a fichero.
Puedes quedarte con una parte y descartar otra (git restore), o tirar la rama entera.
Un chat te devuelve texto; un agente edita tus ficheros.
Con un chat tú decides qué copias. Con un agente (el modo agente de Copilot, Claude Code, Codex, Cursor…) el encargo se ejecuta directamente en tu proyecto: lee ficheros, los edita, crea otros nuevos y puede lanzar comandos en la terminal.
Ahorra mucho trabajo, pero también puede dejarte un proyecto que ya no entiendes. Para evitarlo, trabaja de forma que cada cambio se pueda ver y deshacer. Para eso está Git.
Dos comandos para poder deshacer lo que haga el agente.
Comprueba que no tienes cambios a medias con git status. Si los hay, haz commit (o guárdalos con git stash). Así sabrás que todo lo que cambie a partir de ahora lo ha hecho el agente.
Después crea una rama para el encargo: git switch -c ia/menu-movil. Si el resultado no te convence, borras la rama y main sigue intacta. El prefijo ia/ te recuerda después qué ramas salieron de un agente.
Cuanto más concreto sea, menos sorpresas habrá en el diff.
El diff muestra exactamente qué ha cambiado.
Empieza por git diff --stat: te dice qué ficheros cambiaron y cuántas líneas. Si aparece uno que no estaba en el encargo (un package.json, el HTML que dijiste que no tocara), ya sabes dónde mirar primero.
Después revisa fichero a fichero con git diff ruta/al/fichero, o en VS Code en el panel Control de código fuente, que muestra el antes y el después lado a lado. Las líneas con + son nuevas; las de -, eliminadas.
Busca especialmente: ficheros que no pediste, bloques grandes borrados, dependencias nuevas, claves o URLs que no reconoces y código que repite algo que ya existía. Y aplica lo de la lección de PRIMM: si no puedes explicar una línea, esa línea no entra.
Puedes quedarte con lo que sirve y descartar el resto.
No apruebes comandos que no entiendes.
Los agentes suelen pedir permiso antes de ejecutar comandos. Esa pausa es tu control: lee el comando antes de aceptar. Instalar un paquete que no pediste, borrar con rm -rf, hacer git push --force o tocar ficheros fuera de la carpeta del proyecto son motivos para decir que no y preguntar por qué.
Evita los modos que aprueban todo automáticamente hasta que domines el flujo, y nunca le des al agente claves de producción: si las necesita, es que la tarea no es para él.
Un agente puede cambiar diez ficheros en un minuto. Para usarlo con tranquilidad: commit y rama antes, encargo con límites, revisión del diff y cómo deshacer lo que no quieres.
Código del tema: git switch -c · git diff · git restore
Un chat te devuelve texto; un agente edita tus ficheros.
Con un chat tú decides qué copias. Con un agente (el modo agente de Copilot, Claude Code, Codex, Cursor…) el encargo se ejecuta directamente en tu proyecto: lee ficheros, los edita, crea otros nuevos y puede lanzar comandos en la terminal.
Ahorra mucho trabajo, pero también puede dejarte un proyecto que ya no entiendes. Para evitarlo, trabaja de forma que cada cambio se pueda ver y deshacer. Para eso está Git.
Dos comandos para poder deshacer lo que haga el agente.
Comprueba que no tienes cambios a medias con git status. Si los hay, haz commit (o guárdalos con git stash). Así sabrás que todo lo que cambie a partir de ahora lo ha hecho el agente.
Después crea una rama para el encargo: git switch -c ia/menu-movil. Si el resultado no te convence, borras la rama y main sigue intacta. El prefijo ia/ te recuerda después qué ramas salieron de un agente.
Cuanto más concreto sea, menos sorpresas habrá en el diff.
Una sola cosa, descrita como resultado: «El botón ☰ abre y cierra el menú en móvil y actualiza aria-expanded».
Los ficheros concretos: «Solo js/menu.js y css/menu.css».
«No cambies el HTML, no instales dependencias, no borres ficheros, no hagas commit ni push».
Una comprobación observable: «Funciona con teclado (Tab + Intro) y la consola no muestra errores».
El diff muestra exactamente qué ha cambiado.
Empieza por git diff --stat: te dice qué ficheros cambiaron y cuántas líneas. Si aparece uno que no estaba en el encargo (un package.json, el HTML que dijiste que no tocara), ya sabes dónde mirar primero.
Después revisa fichero a fichero con git diff ruta/al/fichero, o en VS Code en el panel Control de código fuente, que muestra el antes y el después lado a lado. Las líneas con + son nuevas; las de -, eliminadas.
Busca especialmente: ficheros que no pediste, bloques grandes borrados, dependencias nuevas, claves o URLs que no reconoces y código que repite algo que ya existía. Y aplica lo de la lección de PRIMM: si no puedes explicar una línea, esa línea no entra.
Puedes quedarte con lo que sirve y descartar el resto.
git restore package.json.git restore ..git switch main y git branch -D ia/menu-movil.git revert <commit>.feat: menú móvil accesible (con agente, revisado)), y fusiona la rama.No apruebes comandos que no entiendes.
Los agentes suelen pedir permiso antes de ejecutar comandos. Esa pausa es tu control: lee el comando antes de aceptar. Instalar un paquete que no pediste, borrar con rm -rf, hacer git push --force o tocar ficheros fuera de la carpeta del proyecto son motivos para decir que no y preguntar por qué.
Evita los modos que aprueban todo automáticamente hasta que domines el flujo, y nunca le des al agente claves de producción: si las necesita, es que la tarea no es para él.