English

Tu agente no puede probar lo que nunca le diste

Tu agente implementa una función, escribe una prueba unitaria, dice que ya está, y nunca abre lo que construyó. Se lee como flojera, o como un modelo al que le da igual. Casi nunca es ninguna de las dos. Verificó la única capa que podía alcanzar, y se detuvo en el borde de lo que le diste.

Alcance, no diligencia

Piensa en lo que exige físicamente una verificación de punta a punta para un cambio típico. Un navegador para recorrer el flujo. Una herramienta de línea de comandos para el servicio involucrado. Una cuenta de prueba con la cual entrar. Credenciales que sea seguro usar. Una forma de leer los logs después.

Ahora pregúntate cuántas de esas tiene tu agente. Para la mayoría de los montajes la respuesta honesta es cero o una. Las pruebas unitarias suelen ser la única verificación a su alcance, así que eso es lo que recibes, no porque las juzgara suficientes, sino porque todo lo demás era un muro.

Esto convierte una queja en una tarea. "Mi agente no prueba bien" es una afirmación sobre tu entorno más seguido que sobre el modelo. Y el entorno se arregla, de forma permanente, en una tarde.

Pregúntale, en vez de adivinar

No tienes que deducir tú la lista de faltantes, y adivinar tiende a producir lo obvio mientras se te escapa lo que realmente lo bloquea. Describe el tipo de cambio que haces más seguido y pregunta directo qué necesitaría para verificarlo de punta a punta, sin ayuda.

"Cuando te pida cambiar el flujo de compra, ¿qué necesitarías
 de mí para verificarlo de punta a punta tú solo, sin que yo revise?
 Lista herramientas, cuentas y credenciales, y di qué desbloquea cada una."

Las respuestas suelen ser concretas y baratas: una CLI que nunca instalaste, una cuenta desechable, una llave con alcance limitado, una forma de llegar a una copia de staging. De vez en cuando sale algo genuinamente incómodo, como una dependencia de hardware o un servicio sin modo de prueba, y saberlo también sirve, porque dejas de esperar verificación ahí y pones una revisión humana a propósito.

Constrúyelo una vez y todo lo hereda

Esta es la parte que hace que valga una tarde. Un entorno de verificación no es trabajo por tarea, es un activo duradero. Instala las herramientas, crea la cuenta desechable, genera las llaves con alcance limitado, y cada corrida futura sobre ese código arranca pudiendo revisarse a sí misma.

Dos cosas que conviene hacer de paso:

• Limita las credenciales al modo menos destructivo que la tarea necesite. Solo lectura donde leer alcance; una copia desechable en vez de algo real. Un agente con entorno de verificación es un agente con más alcance, y el alcance merece permisos más estrechos.
• Anota cómo se usa cada una. Una herramienta que el agente no puede descubrir es una herramienta que no va a usar. Ya sea en un archivo de reglas o en una skill, la invocación tiene que ser encontrable.

Después haz obligatoria la revisión

La capacidad sola no cambia el comportamiento: un agente que puede verificar todavía necesita un motivo. Dar objetivos de verificación es lo que le permite atrapar problemas antes de que tengas que pedir arreglos, así que enuncia la revisión en el mismo prompt, o escala a algo impuesto cuando importe.

El artículo sobre capas de verificación cubre la escalera: la revisión en el prompt, una meta reevaluada cada turno, un hook que bloquea el turno hasta que tu script pase, y un revisor adversarial. Las cuatro suponen que el agente puede ejecutar algo. De ese supuesto trata este artículo.

Para llevar

Tu agente no es mal probador. Es un probador al que dejaste fuera del edificio. Pregúntale qué necesita para verificar tu cambio más común de punta a punta, instala exactamente esa lista una vez, y luego exige la revisión. La queja sobre pruebas superficiales deja de ser sobre el modelo.