Con agentes, lo escaso ya no es el código. Es el criterio

Cada vez tengo más clara una idea: los agentes no han resuelto la parte importante del trabajo de ingeniería.

Han abarrotado la parte abundante.

Hoy generar código es más barato, más rápido y más convincente que hace un año. Y va a seguir siéndolo.

Pero justo por eso se vuelve más evidente qué parte sigue costando de verdad:

entender qué hace realmente un cambio,
anticipar cómo puede romper producción,
acotar su radio de impacto,
y decidir si merece salir o no.

Ese sigue siendo el trabajo caro.

El problema no es que el agente se equivoque

Que un agente cometa errores no debería sorprender a nadie.

El problema serio es otro: que cada vez se equivoca con más elegancia.

Te deja un diff limpio, una descripción razonable, nombres consistentes, tests suficientes para tranquilizar a medio equipo y una sensación incómoda de que “esto tiene pinta de estar bien”.

Y ahí está la trampa.

Antes, mucho código malo olía mal desde lejos.

Ahora no siempre.

Ahora puede parecer sólido, pasar CI y seguir metiendo en producción una suposición peligrosísima sobre carga, concurrencia, costes, latencia, orden de ejecución o comportamiento real del sistema cuando hay tráfico de verdad.

No porque el modelo sea torpe.

Precisamente porque ya es suficientemente bueno como para parecer más fiable de lo que es.

Pasar CI ya no basta ni como señal psicológica

Creo que una parte del sector todavía no ha interiorizado el cambio de marco.

Seguimos usando algunas señales heredadas como si conservaran el mismo significado que antes.

Una de ellas es esta: si pasa CI, transmite tranquilidad.

No digo que CI no sirva.

Claro que sirve.

Lo que digo es que ha dejado de ser una señal emocional suficiente.

En un mundo con agentes, pasar CI muchas veces sólo demuestra que el cambio ha conseguido satisfacer tus checks actuales.

Y eso puede ser compatible con varias cosas malas a la vez:

que el cambio sea demasiado grande para revisarlo con criterio,
que nadie tenga un modelo mental claro de su comportamiento,
que la cobertura valide caminos felices pero no modos reales de fallo,
o que el riesgo importante ni siquiera esté codificado en los tests.

Esto no es un problema de los agentes solamente.

Pero los agentes lo amplifican porque suben muchísimo el volumen de output.

La diferencia clave no es usar IA o no usarla

La diferencia importante no está entre equipos que usan agentes y equipos que no.

Está entre dos formas de usarlos.

1. Confiar en el agente

Aquí el proceso mental suele ser algo así:

lo ha generado el agente,
parece razonable,
pasan los tests,
tiramos.

El resultado típico son PRs que nadie entiende del todo pero que nadie quiere frenar porque “en principio está bien”.

Eso no es apalancarse en IA.

Eso es externalizar criterio demasiado pronto.

2. Apalancarte en el agente

Aquí el agente acelera trabajo, explora opciones, reduce fricción y quizá incluso encuentra cosas útiles que el humano no habría producido tan rápido.

Pero la propiedad del cambio sigue teniendo dueño.

Alguien entiende:

qué hace,
qué asume,
qué podría romper,
cómo se despliega,
y cómo se revierte.

Para mí, esa es la línea seria.

No me preocupa que un agente escriba mucho código.

Me preocupa que el equipo deje de sentir que poner su nombre en una PR significa realmente algo.

El cuello de botella se ha movido

Durante años nos obsesionamos con la velocidad de implementación.

Tenía sentido.

Escribir software costaba tiempo, atención y manos.

Ahora empezamos a entrar en una fase distinta: la implementación se abarata antes que el juicio.

Eso mueve el cuello de botella.

Lo escaso ya no es tanto producir el cambio.

Lo escaso es poder decir con honestidad:

entiendo este cambio,
entiendo su riesgo,
entiendo cómo se comporta cuando sale del entorno ideal,
y acepto responder por él si algo va mal.

Eso no se genera con autocomplete.

Eso sigue siendo criterio operativo.

Si quieres agentes más autónomos, el sistema tiene que volverse más serio

Aquí veo otra confusión bastante habitual.

Mucha gente interpreta que, si los agentes mejoran, cada vez necesitaremos menos proceso, menos infraestructura y menos disciplina.

Yo creo más bien lo contrario.

Si quieres permitir más autonomía, necesitas un entorno mejor diseñado:

despliegues graduales,
rollback automático,
validación continua,
staging que se parezca de verdad a producción,
checks que recojan conocimiento operativo real,
y guardrails ejecutables en vez de documentación decorativa.

No por burocracia.

Justo al revés.

Porque cuando el volumen de cambios sube tanto, no puedes depender sólo de heroicidad humana ni de revisar cada diff como si fuera artesanía.

La salida razonable es hacer que el sistema contenga mejor el daño.

No basta con pedirle a la gente que “sea cuidadosa”.

Hay que construir un entorno donde lo seguro sea lo fácil.

La responsabilidad no desaparece. Se concentra

Otra idea que me parece importante: los agentes no diluyen responsabilidad.

La concentran.

Cuando producir diez cambios cuesta casi lo mismo que producir uno, el valor ya no está en tocar más código.

Está en decidir:

qué cambios merecen existir,
cuáles no deberían salir aún,
cuáles necesitan rollout parcial,
cuáles exigen observabilidad adicional,
y cuáles simplemente no entendemos lo suficiente como para aprobarlos.

Eso es bastante menos glamuroso que hablar de “fully autonomous coding”.

Pero es mucho más cercano al trabajo real.

Mi regla mental

Si yo no me siento cómodo explicando en voz alta cómo puede romperse un cambio en producción, no me da igual que lo haya escrito una persona o un agente.

No está listo.

Y si además necesito releer mi propia PR para entender qué hace, el problema no es de velocidad.

Es de propiedad.

Para mí, la pregunta útil no es “¿el agente lo ha hecho bien?”.

La pregunta útil es esta:

¿estoy dispuesto a que este incidente lleve mi nombre al lado?

Si la respuesta es no, todavía no has terminado.

Idea final

Los agentes van a seguir mejorando.

Generarán más código, más rápido y con mejor apariencia.

Precisamente por eso, el trabajo importante no va a ser escribir más.

Va a ser sostener un criterio más duro sobre lo que aceptas poner en producción.

Porque en esta etapa, la ventaja real ya no está en quién produce más código.

Está en quién conserva mejor el juicio cuando producir código deja de ser lo difícil.