Agentes de código: por qué la disciplina importa más que el prompt
Un agente de código puede escribir miles de líneas en minutos. Eso no cambia lo que un ingeniero senior sigue teniendo que decidir: qué construir, cómo verificarlo, y cuándo detenerse a pensar.
Un agente de código bien dirigido puede portar una integración de pagos completa (firmas de integridad, verificación HMAC de webhooks, links de cobro firmados) en una tarde. Eso es real, lo hice hace poco. Pero la parte interesante no es la velocidad: es que exactamente los mismos criterios que aplico revisando el código de un ingeniero junior aplican, sin excepción, revisando el de un agente. La velocidad cambió. El estándar de aceptación no.
El cambio real no es la velocidad de escritura
Lo que un agente de código elimina es el tiempo de mecanografía: boilerplate, el segundo archivo que replica el patrón del primero, la búsqueda del nombre exacto de una función en una librería que ya usaste antes. Eso es trabajo real, pero nunca fue el trabajo difícil. El trabajo difícil sigue siendo el mismo de siempre: decidir qué construir, qué no construir, y dónde puede fallar silenciosamente un sistema que "funciona" en la demo.
Un agente no tiene contexto de negocio. No sabe que ese endpoint de pagos necesita idempotencia porque la pasarela reintenta, ni que ese campo "opcional" en realidad nunca está vacío en producción. Eso lo sabe el ingeniero, y seguirá siendo así mientras el agente no tenga acceso a la memoria institucional completa de un negocio, que no es poco tiempo.
El error que más rápido acumula deuda
El error más caro que he visto, y que he cometido, no es usar un agente para escribir código. Es dejar que decida arquitectura sin que nadie la revise. Un agente optimiza por completar la tarea que se le dio, no por la salud del sistema a seis meses. Si se le pide "agrega un campo a esta tabla", lo agrega, sin preguntar si ese campo debería vivir en otra tabla, si rompe una invariante que el resto del código asume, o si ya existe un campo equivalente con otro nombre.
Esto se ve exactamente igual que la deuda técnica de siempre: código que funciona, pasa los tests que existen, y se vuelve más caro de cambiar cada vez que alguien más toca esa parte del sistema. Solo que ahora se acumula más rápido, porque el volumen de código producido por sesión es mayor.
La práctica que sí funciona
Lo que funciona en la práctica es tratar al agente como una llamada a un método: input verificable, output verificable, y un humano en el medio que decide antes y confirma después. Antes de que escriba una línea, un plan explícito: qué archivos toca, qué patrón sigue, qué se queda igual. Después de que termina, el mismo review que le haría al PR de cualquier persona del equipo, diff por diff, no un "se ve bien" superficial.
Eso fue literalmente el proceso detrás del rediseño completo de este sitio: paleta de marca, tipografía, sistema de iconos, estructura de navegación. Cada cambio se planeó antes de escribirse, y se verificó después (build, lint, capturas de pantalla reales) antes de darlo por bueno. El agente escribió la mayoría de las líneas. Las decisiones de qué construir y cuándo aceptar el resultado siguieron siendo mías.
La lección
Un agente de código no cambia lo que significa ser un ingeniero senior: seguir siendo responsable de un sistema que no puede fallar, aunque no hayas escrito cada línea a mano. Cambia cuánto código se puede producir por hora de esa responsabilidad. Confundir esas dos cosas, tratar la velocidad como si fuera criterio, es exactamente cómo un equipo termina con un sistema rápido de construir e imposible de mantener.