English

Deja de ser tú el ciclo de verificación

Pregunta qué verifica la salida de tu agente y la respuesta honesta suele ser: tú, leyéndola. Ese arreglo escala mal. Cada error se queda ahí, sin costo de producción, esperando que un humano lo note, y el humano nota cada vez menos mientras más avanza la sesión.

El cuello de botella no es el prompt

Cuando la calidad decepciona, el reflejo es mejorar el prompt. A veces ayuda. Pero hay una diferencia estructural entre un agente que produce y uno que produce y revisa, y ninguna cantidad de refinamiento del prompt la cruza.

Un agente capaz de verificar su propio trabajo atrapa problemas antes de que tengas que pedir arreglos. El ciclo se cierra sin ti adentro. Un agente sin prueba produce salida confiada a velocidad de máquina, y la capacidad de revisión es una persona cansada leyendo diffs. Agregar un objetivo de verificación cambia lo que el agente puede hacer; reformular la petición solo cambia lo que intenta.

La prueba práctica: ¿podría el agente saber, por su cuenta, si tuvo éxito? Si no, la capa de verificación eres tú, sin importar qué tan bien redactaste la petición.

Cuatro capas, de la más barata a la más fuerte

Escalan en costo y en fuerza. La mayoría del trabajo necesita la primera; algo del trabajo justifica la cuarta.

1. Pide la revisión en el mismo prompt. Incluye el paso de verificación en la petición misma: corre las pruebas, compara la salida con este ejemplo, confirma que el endpoint devuelve 200. Prácticamente gratis, y cubre bastante. Dar objetivos de verificación es lo que permite que el agente atrape sus propios errores antes de entregar.

2. Fija una meta. Una meta se reevalúa a lo largo de los turnos: el agente sigue trabajando hasta que la condición se cumple o la meta se libera por otra razón. La diferencia con una instrucción en el prompt es la persistencia: un prompt lo revisa una vez quien se acuerde, una meta es una condición a la que la sesión vuelve.

3. Un hook que bloquea. Un hook de Stop que sale con código 2 impide que el agente se detenga y continúa la conversación. Esta es la primera capa que no es un consejo: es imposición, corre como comando de shell en un evento fijo del ciclo de vida, y aplica sin importar lo que el agente decida. Si tu linter debe pasar antes de que termine un turno, este es el mecanismo, porque las instrucciones en un archivo de reglas son contexto y se pueden pasar por alto, y un hook no.

4. Un revisor adversarial. Un agente aparte cuyo trabajo es atacar el resultado. La opción más fuerte y más cara, y la que trae una falla que conviene entender antes de usarla.

Cómo acotar al revisor para que no fabrique hallazgos

Un agente al que le pides encontrar problemas va a encontrar problemas. Si el trabajo está limpio, va a ir bajando su vara hasta que algo califique, porque le diste un objetivo que solo se satisface con resultados. Terminas con una lista de preferencias de estilo e hipótesis presentadas con la misma confianza que defectos reales, y la señal se ahoga.

El arreglo es definir qué cuenta antes de que empiece. Acota al revisor a marcar solo lo que rompe la correctitud o tu requisito declarado, y trata todo lo demás como explícitamente opcional. Dale permiso de no devolver nada.

Débil:
  "Revisa esto y encuentra cualquier problema."

Fuerte:
  "Revisa esto contra el requisito: <requisito>.
   Marca solo defectos que rompan la correctitud o ese requisito.
   Todo lo demás es opcional: lístalo aparte u omítelo.
   No encontrar hallazgos es un resultado aceptable."

La misma disciplina aplica a paneles de revisión. Darle a varios revisores lentes distintos, como correctitud, seguridad y si de verdad se reproduce, supera a varios revisores idénticos, porque la diversidad atrapa fallas que la redundancia no.

Construye el ciclo contra el que el agente pueda correr

Debajo de las cuatro capas está el mismo requisito: algo que el agente pueda ejecutar y que le diga si tuvo éxito. Mientras más fuerte sea esa señal, menos importa todo lo demás.

• Una suite de pruebas que pueda correr, con fallas que pueda leer
• Una compilación o verificación de tipos que exponga errores de forma mecánica
• Una forma de manejar el artefacto real: pegarle al endpoint, abrir la página, leer el log
• Salida esperada concreta pegada en el prompt

Aquí también es donde la verificación deja de ser costo y se vuelve ahorro. Un error que atrapa una prueba que el agente corrió solo cuesta un turno extra. Un error que atrapas tú cuesta un cambio de contexto, una explicación y una nueva corrida, asumiendo que lo atrapes, que es justo el supuesto sobre el que descansa todo el arreglo.

Un hábito relacionado que vale adoptar: pon los pasos de verificación en la lista de tareas como elementos propios. "Correr las pruebas" como tarea aparte se hace. "Correr las pruebas" agregado al final de una frase sobre implementar una función, con frecuencia no.

Para llevar

Si no hay prueba, la prueba eres tú, y eres la parte más lenta, más cara y menos confiable de ese ciclo. Empieza por la capa más barata: enuncia la verificación en el mismo prompt. Escala a una meta cuando deba persistir, a un hook que bloquea cuando deba imponerse, y a un revisor cuando el trabajo justifique un adversario. Después acota al revisor a la correctitud y a tu requisito declarado, o inventará hallazgos para cumplir la instrucción que le diste.