De revisar código a convertir el criterio: apuntes sobre el trabajo diario con agentes

¿Qué cambia de verdad en la cadena de producción cuando los agentes de programación pasan a formar parte del trabajo diario? Pues puede que la habilidad más útil acabe siendo una para la que nadie se ha formado.

Una escena pequeña, pero real, del trabajo con agentes de programación. Le encargas una tarea a uno, te devuelve una pull request (PR) y, enterrada en su propia revisión del trabajo, aparece una nota como esta: «El segundo SELECT de este procedimiento no está protegido respecto al primero: ¿y si alguien borra la tabla entre medias?». La ventana en cuestión dura menos de un milisegundo. Nadie va a borrar esa tabla. Y, aun así, el agente lo señala con la misma gravedad que le daría a un fallo real de pérdida de datos. Multiplica eso por una PR grande y tendrás la experiencia que muchos ya reconocemos: diffs que se desparraman, revisiones que se ponen a hurgar en código que ya existía y por el que nadie ha preguntado, y la sensación sorda de que tu propio código se te está yendo de las manos.

La explicación más extendida es que nuestro trabajo se está convirtiendo en un trabajo de gestión: ahora eres el gestor de varios agentes, quizá incluso de un agente que gestiona a otros agentes. Nos parece un planteamiento seductor y, en buena parte, equivocado. Gestionar a personas funciona porque estas son lo bastante lentas como para que tu ritmo y el suyo vayan más o menos a la par, y porque comparten tu intención. Los agentes van más rápido de lo que puedes supervisar y no comparten tu intención: tienen una reconstrucción verosímil de ella. El «gestor de agentes» acaba reducido a «revisor de un aluvión», y ahí es justo donde más duele la sobreingeniería.

El problema de fondo es que esa sobreingeniería no es un fallo que se arregle con un prompt. Es estructural. Un ingeniero humano que ya ha llevado código a producción carga con un presupuesto de riesgo implícito: una reserva finita de atención, de capacidad de revisión y de tolerancia a las regresiones que gasta de forma deliberada. Por esta ruta pasa todo, así que recibe el trato más cuidadoso; este script se ejecuta una vez por trimestre, así que basta con que cumpla. Un agente no tiene ese presupuesto. Cualquier mejora posible le parece gratis, así que las propone todas. La nota sobre el borrado de la tabla no es más que un agente que tira de un presupuesto que no sabe que existe.

Mira, no te voy a engañar: hay tardes en que apruebo la versión inflada sin más, porque discutir con el cacharro me costaría más energía de la que me queda. No me enorgullece. Pero cualquier ingeniero que diga que nunca lo ha hecho miente.

Así que el instinto es acertado: el agente necesita una noción del coste del esfuerzo. Pero enseñarle ese coste directamente suele fracasar, porque el coste no es un dato del código. Es un dato de tu situación esta semana: cuánta capacidad de revisión tienes, lo cerca que estás del lanzamiento, cuánto te fías de ese rincón del sistema. Codifícalo y quedará obsoleto en cuanto cambie la situación. Los límites estructurales rígidos —un tope de tamaño para el diff, por ejemplo— fallan de otra manera: penalizan al agente por la refactorización ocasional que de verdad mejora las cosas y que, casualmente, es grande. Ninguno de los dos extremos se sostiene.

Lo que funciona mejor está a medio camino, y sale más barato de lo que parece: deja que el agente plantee el coste como una elección, por adelantado, en el plan y no en el código. Pídele, antes de que escriba nada, que exponga tres planes —una intervención mínima, una razonable y una reescritura completa de toda la cadena— y elige tú. Tres planes salen baratos; tres implementaciones, no. Gastas tu criterio en el único momento en que ejercerlo cuesta poco —antes del trabajo— en lugar de volver a gastarlo línea a línea en la revisión posterior. Es muy parecido a lo que recomiendan las propias pautas de Anthropic para Claude Code con el modo de planificación: explorar y acordar el alcance antes de tocar ningún archivo, y dejar que la verificación ejecutable haga de última línea de defensa.

Pero el replanteamiento más certero que hemos encontrado va más allá, y es el que vale la pena interiorizar. Si la revisión parece una batalla perdida es porque pagas el mismo coste de criterio en cada PR y nada se acumula: es trabajo puro y duro, nada genera intereses. La alternativa es una disciplina que un modelo reciente de ingeniería agéntica llama conversión en gobernanza: tomar una decisión que, de otro modo, volverías a tomar a mano cada vez y congelarla en una estructura duradera —una regla de lint, una cláusula de la especificación, un alcance por defecto, un invariante de test— para que, a partir de ese momento, el sistema decida solo. Pagas el criterio una sola vez y lo tienes ahorrado para siempre.

Hay un giro que lo vuelve casi atractivo. La velocidad del agente, justo lo que te desborda, también es un sensor. Como genera tanto código tan deprisa, saca a la luz las mismas clases de fallos una y otra vez, mucho más rápido de lo que lo haría un equipo humano. Las PR desparramadas y las notas sobre el borrado de la tabla no son solo ruido: son señal, y te muestran con mucha frecuencia exactamente qué decisiones tienes que tomar una y otra vez. Cada una de las que se repiten es candidata a la conversión. La pregunta deja de ser «¿cómo reviso más rápido?» y pasa a ser «¿cuáles de las decisiones que he tomado esta semana no debería tener que volver a tomar nunca un humano?». Esa estructura acumulada es capital de ingeniería: la construyes una vez y sigue rindiendo. La pega, para qué engañarnos, es que las especificaciones y los controles pueden desviarse del código a medida que este evoluciona, así que ese capital necesita mantenimiento; pero es un problema mucho preferible al aluvión del principio.