Programar con agentes sin perder el control del código

La promesa se cumple: un agente entrega en una hora lo que antes costaba un día. Lo que casi nadie dice es qué pasa después con esas mil líneas que nadie ha leído con atención.

El cuello de botella se movió, no desapareció

Antes, escribir era lo caro y revisar lo barato, porque el que revisaba normalmente entendía cómo se había llegado ahí. Ahora escribir es barato y revisar sigue costando lo mismo — pero hay mucho más que revisar y ningún humano recuerda por qué se tomó cada decisión.

El resultado típico: se aprueba a ojo. Y el código aprobado a ojo funciona, hasta que hay que cambiarlo.

Lo que hacemos nosotros

• Tareas pequeñas y verificables. Un cambio que se revisa en diez minutos se revisa. Uno de mil líneas se acepta. Si el agente propone algo grande, se parte antes de empezar, no después.
• La prueba antes que la implementación. Si existe una prueba que falla y luego pasa, hay evidencia. Si no, solo hay confianza.
• Verificar de verdad, no leer el resumen. Un agente puede informar de que algo funciona sin que funcione. Nos ha pasado esta misma semana: un comando remoto devolvió «correcto» sin haber ejecutado nada. Si el agente dice que arregló algo, se comprueba contra el sistema, no contra su mensaje.
• El porqué en el código. Los comentarios importan más que antes, y deben explicar la decisión, no la sintaxis. Dentro de seis meses nadie va a poder preguntarle al agente por qué eligió ese camino.

La regla que más nos ha servido: si no puede explicar el cambio a un compañero, no lo fusione. Da igual que las pruebas pasen.

Dónde rinden de verdad

No en todo por igual. Rinden mucho en trabajo mecánico y verificable:

• Migraciones repetitivas — cambiar una API en cuarenta ficheros.
• Pruebas para código que ya existe y funciona.
• Exploración de código ajeno: «¿dónde se calcula esto?».
• Primeras versiones de algo que va a cambiar igualmente.

Rinden mucho menos donde la decisión vale más que el teclado: diseñar un modelo de datos, elegir entre dos arquitecturas, decidir qué NO construir. Ahí el agente propone con seguridad cosas razonables y a veces equivocadas, que es justo la combinación peligrosa.

Y una cosa que este proyecto nos recordó

Trabajando rápido con agentes es fácil sobrescribir un fichero y perder lo que había. Si el proyecto no está en control de versiones, la recuperación depende de la suerte.

La velocidad que dan los agentes solo es segura encima de higiene básica: repositorio, ramas y la posibilidad de volver atrás. Sin eso no está yendo más rápido, está asumiendo más riesgo a la misma velocidad.