Sin verificación no hay autonomía

Cada mes que pasa, los agentes aguantan sesiones más largas sin ayuda: una hora de trabajo continuo sobre decenas de archivos ya no sorprende a nadie. Y cada mes queda más claro que esa autonomía vale exactamente lo que vale la verificación que la acompaña.

De la sobreconfianza de los modelos escribimos en noviembre: afirman que todo está resuelto con la misma seguridad cuando lo está y cuando no. Medio año después el problema no se corrigió; escaló junto con la autonomía. Un agente que trabaja una hora solo y sin verificador no es más productivo que antes. Es más peligroso, porque entrega errores más grandes con la misma cara de éxito.

«Que funcione» no es un criterio

La pieza que ordena todo es anterior al agente: el criterio de éxito verificable. Un criterio verificable es algo que pasa o falla sin opinión de por medio:

# criterios verificables
las pruebas de auth.spec pasan completas
GET /api/salud responde 200 con {"estado":"ok"}
la página /tablero carga sin errores de consola
el build de producción termina sin advertencias nuevas

# no son criterios
"que funcione"
"que quede bien"
"mejorar el rendimiento"

La regla que adoptamos suena estricta y nos ahorró más tiempo que ninguna otra este año: si no podemos escribir el criterio antes de empezar, la tarea no está lista para delegarse a un agente. La dificultad para escribirlo casi siempre revela que el pedido está mal definido, y un agente trabajando horas sobre un pedido mal definido produce exactamente eso: horas de trabajo sobre otra cosa.

Verificar barato, verificar siempre

Con el criterio escrito, la verificación se vuelve maquinaria: pruebas automatizadas, verificación de tipos, análisis estático. Lectores que no se cansan y corren en cada vuelta. El agente los ejecuta, ve el resultado y corrige antes de que una persona mire nada.

Para lo que no es binario (la calidad de un texto, la claridad de una interfaz) usamos evaluaciones con rúbrica: imperfectas, pero bastante mejores que el ojo cansado de un viernes. La clave en ambos casos es la misma: el costo de verificar tiene que ser mucho menor que el costo de producir, porque se verifica muchas más veces de las que se produce.

El orden de los factores

Hay una inversión de orden que describe bien esta etapa. Antes el flujo era escribir, y después ver cómo probar lo escrito. Ahora conviene el inverso: escribir primero la prueba de que la tarea quedó bien, y recién entonces soltarle la tarea al agente.

No es una idea nueva; el desarrollo guiado por pruebas la propone hace veinticinco años. Lo nuevo es que dejó de ser una disciplina opcional para equipos virtuosos. Con agentes autónomos en el medio, es la diferencia entre delegar y desear.