Un agente de código es una herramienta de IA que trabaja dentro de tu proyecto: lee archivos, los edita, ejecuta comandos como los tests y revisa qué pasó. Un chat común te dice qué cambiar; el agente lo cambia. Ejemplos conocidos son Claude Code, Codex y Cursor. Revisar lo que hizo sigue siendo tu trabajo.
✅ Tests en verde
Una pregunta de la app. Elige una respuesta.
Pediste arreglar una errata. El diff también cambia el cálculo de precios. ¿Qué haces?
Quizás, pero nadie lo pidió ni lo revisó. Un cambio en precios merece su propia revisión.
No era parte del pedido. Si cree que hay un error en precios, que lo cuente aparte y lo decides tú.
Los tests prueban lo que prueban. El problema es otro: es un cambio que no pediste en algo delicado.
Le pides arreglar un error en el formulario de registro. Un chat te devuelve un bloque de código para que lo pegues tú. Un agente busca el archivo, lo edita, corre los tests y te cuenta el resultado. Por dentro suele haber un modelo de lenguaje con herramientas: decide cuál usar, mira lo que pasó y sigue. Por eso es un tipo de agente de IA. Para una búsqueda larga puede lanzar un subagente, con su propio contexto.
«Listo, ya funciona» es una afirmación, no una prueba. Lo que la respalda es un resultado: tests corridos y leídos, con los fallos a la vista. Y aun así, los tests que pasan prueban lo que prueban, no toda la app.
Muchas herramientas leen un archivo de instrucciones en el repo, como CLAUDE.md o AGENTS.md; cuál lee cada una depende de la herramienta y su configuración. Ahí va lo que no se deduce del código: «los textos van en español, inglés y portugués», «corre los tests antes de terminar». Ese archivo suele cargarse en cada sesión y ocupa lugar en la ventana de contexto, así que conviene corto.
Las instrucciones guían, no garantizan: el agente puede olvidarlas. Lo que de verdad lo limita son los permisos, qué acciones puede hacer y cuáles te piden aprobación. Para cambiar un texto de la app no necesita acceso a la base de datos de producción.
Para un cambio grande o riesgoso, pídele un plan y revísalo antes de que toque nada. Si el plan entero dice «arreglo lo necesario», pide detalle. Si propone agregar una columna y tu equipo no toca la base de datos, corrígelo ahí. Para una errata, el plan sobra.
Después, el diff muestra lo que cambió de verdad, pedido o no. Ejemplo: pediste cambiar el color de un botón y el diff también toca la validación del login. Eso no era parte del pedido: se saca y, si hace falta, se discute aparte. Ojo con los archivos nuevos, que a veces no aparecen en el diff.
Muchos llaman «vibe coding» a programar pidiéndole todo al agente y aceptando lo que sale sin leerlo. Para un prototipo de una tarde que vas a tirar, puede servir. En un proyecto con usuarios, pagos o datos personales, un cambio que nadie leyó es un riesgo: el modelo puede inventar una función que no existe o «arreglar» algo que no pediste.
Si estás aprendiendo a programar, hay un motivo más: leer el diff es la forma más rápida de entender qué hizo el agente y por qué. Si aceptas sin mirar, el código avanza y tú no.