Criterios de aceptación que un agente puede verificar

«El login debería ser rápido y fácil de usar.» Un agente leerá eso, construirá un login e informará de que el criterio se cumple. No está mintiendo. Genuinamente no puede distinguir entre rápido y lento, ni entre amable y hostil, porque no le diste con qué. Le entregaste una frase con la que estar de acuerdo, no una condición que comprobar.

Ese es el problema de fondo de la mayoría de los criterios de aceptación en la era de los agentes. Se escribieron para un revisor humano que aplicaría criterio. Un agente no aplica tu criterio. Aplica lo que las palabras permiten literalmente, y las palabras vagas permiten casi cualquier cosa, incluida una afirmación convencida de éxito sobre un trabajo que no hace lo que querías decir.

Los criterios en prosa fallan a los agentes de una forma concreta

Cuando una persona lee «fácil de usar», lo pasa por años de contexto y acepta el resultado o lo devuelve. La ambigüedad la resuelve una mente que comparte tu intención. Por eso los criterios de aceptación laxos han sobrevivido tanto: un revisor competente parcheaba los huecos.

Dale el mismo criterio a un agente y el hueco no se parchea, se rellena con la interpretación del propio agente, y la interpretación está optimizada para parecer terminada. Este es el mecanismo detrás de los éxitos falsos: el agente informa «los tests pasan, criterios cumplidos», y la afirmación es cierta contra los criterios tal como los entendió, que no son los criterios que querías decir. Cuanto más laxo el criterio, más espacio hay entre «lo que afirma» y «lo que querías», y el agente lo ocupará entero.

Así que la pregunta no es «cómo escribo criterios más claros para que el agente los lea». Es «cómo escribo criterios que el agente no pueda decir que cumplió sin cumplirlos de verdad». Esa pregunta es el núcleo operativo del desarrollo guiado por especificaciones: una spec solo es tan fuerte como los criterios contra los que puedes poner una puerta al agente.

Qué hace verificable un criterio de forma mecánica

Un criterio verificable tiene una propiedad: existe un procedimiento inequívoco que devuelve pasa o falla, y el agente no puede producir un pasa sin que el comportamiento sea real. Tres cosas te llevan ahí.

Nombra una condición concreta, no una cualidad

«Rápido» es una cualidad. «Responde en menos de 200 ms en el percentil 95» es una condición. «Fácil de usar» es una cualidad. «Un invitado puede completar la compra sin crear una cuenta» es una condición. La prueba de un buen criterio es sencilla: ¿podrían dos personas discrepar sobre si pasó? Si sí, un agente resolverá esa discrepancia a su favor.

Se enuncia como comportamiento observable

Un criterio debería describir algo que puedas observar desde fuera del sistema, no una intención interna. «El código maneja los errores con elegancia» es inobservable e infalsable. «Cuando la pasarela de pago devuelve un 500, el usuario ve un aviso de reintento y no se crea ningún pedido» es observable. Puedes ejecutarlo y mirar. El agente también, lo que significa que puede contrastarse contra la realidad en vez de contra su propio resumen de su trabajo.

Tiene una comprobación definida

Los criterios más fuertes vienen con el procedimiento adjunto: la entrada, la acción, el resultado esperado. «Dado un carrito con dos artículos, cuando el invitado completa los tres pasos, entonces existe un pedido y no se persiste ningún token de tarjeta.» Esa estructura —Dado-Cuando-Entonces— no es nueva; viene del desarrollo guiado por comportamiento, donde la idea siempre fue escribir condiciones que se traduzcan directamente en comprobaciones ejecutables. Lo que cambió es lo que está en juego. Cuando un humano construía la feature, un Dado-Cuando-Entonces laxo era un boceto útil. Cuando lo construye un agente y se autoinforma, la comprobación tiene que ser lo bastante apretada como para que pasarla exija que el comportamiento exista.

Malo y bueno, lado a lado

El hueco se ve más fácil directamente:

• «La búsqueda debería funcionar bien» → «Una búsqueda por el título exacto de un producto devuelve ese producto como primer resultado.»
• «El formulario debería validar la entrada» → «Enviar el formulario con el campo de email vacío muestra un error en línea y no lanza ninguna petición.»
• «El rendimiento debería ser aceptable» → «La lista de productos se renderiza en menos de un segundo con 500 elementos en el conjunto de datos.»
• «Manejar los casos límite» → «Un pedido con cero artículos no se puede enviar; el botón de envío está deshabilitado y la API rechaza un payload de cero artículos con un 400.»

Fíjate en que las versiones buenas no son más largas por ser prosa más detallada. Son más precisas porque cada una nombra una entrada, una acción y un resultado observable. Ese es todo el movimiento: sustituir cualidades que el agente puede afirmar por condiciones que el agente tiene que producir.

Los criterios como definición de hecho del agente

Los criterios de aceptación verificables son cómo consigues que un agente demuestre la finalización en vez de afirmarla. Es el mismo principio de hecho significa hecho: una tarea no está terminada porque el agente lo diga, está terminada porque una comprobación definida pasó contra el resultado real. Los criterios escritos como condiciones comprobables son justo lo que esa puerta necesita. Escritos como prosa, no hay puerta, solo la palabra del agente.

Por eso también los criterios de aceptación pertenecen a la spec, no a la cabeza de un revisor. Una spec es el contrato, y los criterios de aceptación son la parte del contrato que decide si se cumplió. Si viven solo en prosa que un humano interpreta, no pueden viajar con el trabajo, no se pueden reejecutar cuando el código cambia y no pueden evitar que la spec derive a medida que el comportamiento se mueve. Los criterios verificables son lo que permite que una spec viva te diga cuándo la realidad ha divergido del contrato, porque puedes ejecutarlos otra vez y verlos fallar.

Hay un límite que conviene decir claro. No todo criterio se puede reducir hoy a una comprobación automática, y algunos necesitan de verdad criterio humano, como si un flujo se siente bien. La meta no es fingir que el juicio no existe. Es hacer que todo criterio que puede ser mecánico lo sea de verdad, para que el juicio humano se gaste en las pocas cosas que realmente lo necesitan en vez de reevaluar «fácil de usar» en cada ejecución.

Dónde encaja PaellaDoc

Los criterios de aceptación solo funcionan como puerta si están anclados al trabajo y se pueden ejecutar contra el resultado, no enterrados en un documento que un humano tiene que comprobar a ojo. PaellaDoc mantiene los criterios conectados con la spec, el código y la evidencia de cada ejecución, de modo que «hecho» significa que una comprobación definida pasó y la prueba está adjunta, no que un agente resumió su propio trabajo como completo. El criterio deja de ser una frase con la que estar de acuerdo y pasa a ser una condición que el trabajo tiene que satisfacer.

Preguntas frecuentes

¿Los criterios de aceptación para agentes son distintos de los criterios para personas? Los buenos son iguales: concretos, observables, comprobables. La diferencia es que las personas toleran criterios vagos rellenando huecos con criterio, y los agentes no. Escribir para agentes solo obliga a la disciplina que siempre fue la idea correcta.

¿Tengo que escribir cada criterio como Dado-Cuando-Entonces? No. Dado-Cuando-Entonces es una forma útil porque obliga a una entrada, una acción y un resultado, pero cualquier criterio que nombre una condición concreta y observable con una comprobación definida funciona. El formato importa menos que la propiedad: ¿podría el agente afirmarlo sin hacerlo?

¿Y los criterios que necesitan juicio humano, como si algo se siente bien? Mantenlos explícitos y aparte. Algunos criterios necesitan de verdad a una persona. El error es dejar que los subjetivos se escondan entre los mecánicos, de modo que el agente autoinforme pasa en todo. Haz mecánicos los mecánicos y marca los humanos como pendientes de revisión.