Given/When/Then y EARS: el idioma común de humanos y agentes de IA
Tiempo de lectura: 7 minutos
Pídele a una IA que implemente "un login seguro" y obtendrás algo. Pídele que implemente "dado un usuario con cinco intentos fallidos, cuando introduce una contraseña incorrecta, entonces la cuenta se bloquea quince minutos" y obtendrás eso. La diferencia no es la potencia del modelo: es la precisión del criterio. Y resulta que los formatos que llevan años ayudando a los equipos a escribir buenos criterios —Given/When/Then y EARS— son justo los que mejor entienden los agentes de IA.
No es casualidad. Ambos formatos eliminan la ambigüedad, y la ambigüedad es exactamente lo que hace que un agente rellene huecos a su manera. Este artículo te enseña a usarlos como idioma común entre tu equipo y la IA.
01 · El problema: "correcto" no significa lo mismo para todos
Un criterio como "el sistema debe ser rápido" es inútil para verificar nada: ¿rápido para quién, en qué condición, comparado con qué? Un humano lo interpreta con su contexto; un agente lo interpreta con el suyo —y rara vez coinciden. El resultado es retrabajo, ese sobrecoste que analizamos en Specs que la IA convierte en código sin retrabajo.
La solución no es escribir más, sino escribir verificable: criterios que cualquiera —persona o máquina— pueda comprobar como verdadero o falso.
02 · La anatomía de un buen criterio
Hay dos notaciones que llevan la ambigüedad a casi cero. Given/When/Then describe comportamiento por escenarios; EARS estructura requisitos en una frase. Así se ven anotadas:
Lo potente es que ambos formatos son legibles para una persona y ejecutables para un agente: de un Given/When/Then sale casi directamente un test automatizado.
03 · Cuándo usar cada uno
No compiten; se complementan. Una regla simple:
- Given/When/Then para comportamiento observable por el usuario: flujos, pantallas, casos de uso. Encaja de maravilla con las historias de usuario —de hecho, son su criterio de aceptación natural, como vemos en La guía definitiva para escribir buenas historias de usuario.
- EARS para requisitos de sistema, reglas de negocio y restricciones: rendimiento, seguridad, límites. Una frase, sin ambigüedad.
Muchas specs usan ambos: GWT para describir el escenario, EARS para fijar las reglas que ese escenario debe respetar.
04 · Los errores que reintroducen ambigüedad
Incluso con la notación correcta, es fácil colar imprecisión:
- Condiciones implícitas: olvidar el "Given" y asumir el estado inicial.
- Resultados vagos: "entonces funciona bien" en lugar de un resultado observable.
- Varios comportamientos en un criterio: si hay dos "Then", probablemente son dos criterios.
- Vocabulario inconsistente: llamar "cuenta", "perfil" y "usuario" a lo mismo confunde a humanos y agentes por igual.
Escribir buenos criterios es la misma disciplina que descomponer bien el trabajo. Si te cuesta, quizá la historia es demasiado grande: revisa Cómo descomponer bien las épicas en historias de usuario.
Lleva esto a tu próxima spec
Hemos incluido plantillas de criterios en Given/When/Then y EARS, con ejemplos y un glosario, en los recursos de Spec-Driven Development. Cópialos y adáptalos a tu próxima historia.
Y si quieres practicarlo con feedback —escribiendo criterios que un pipeline de IA convierte en tests reales— ese es uno de los núcleos del curso Specification-Driven Development.
Cada jueves enviamos un caso práctico sobre cómo trabajar con IA con precisión en la newsletter de ITNOVE: suscríbete gratis en itnove.com/newsletter.
La IA no necesita que le hables con código. Necesita que le hables sin ambigüedad. Given/When/Then y EARS son ese idioma.