# Estándar de Validación > Cuando una misma pasada escribe el código y las pruebas, una especificación mal leída produce un build equivocado que sus propias pruebas confirman. Este es el mecanismo que lo detecta. Fuente: https://www.koombea.com/es/ai-pods/standards/validation/ --- ## La falla, dicha sin rodeos En desarrollo tradicional, un desarrollador que entendió mal un requerimiento suele darse cuenta. Una conversación, la revisión de código o QA sacan la brecha a la luz. Con un agente la falla se ve distinta. Un desarrollador pide una implementación. El agente genera el código y las pruebas desde la misma lectura de la especificación. El desarrollador lo entrega. La implementación está mal, las pruebas pasan, y la mala lectura nunca aparece. Esto no es un defecto del modelo. Es una propiedad estructural de cualquier sistema que genera el artefacto y su verificación en la misma pasada. Es exactamente lo que este estándar existe para evitar: **código que pasa sus propias pruebas porque el mismo malentendido generó las dos cosas.** La responsabilidad no se mueve. El agente es la herramienta, no quien entrega. Quien aprobó responde por lo que salió. ## Dos tipos de validación **La validación de producto** demuestra que el build coincide con la especificación. **La validación de sistema** demuestra que el agente se comportó bien, que interpretó la especificación como se pretendía, que no se desvió, y que produjo comportamiento auditable. Un proyecto necesita las dos. La validación no es una red de seguridad para errores de IA. Es el mecanismo que hace auditable la entrega AI-First. Hay un arco más largo aquí. A medida que esta forma de trabajar madura, el trabajo pasa de escribir código, a revisar código generado, a diseñar los sistemas donde los agentes escriben y revisan código. En cada paso la persona se aleja más del artefacto y detecta menos por intuición. El sistema de validación tiene que cubrir esa distancia creciente. ## El contrato de comportamiento Calidad diseña qué hay que demostrar. Ingeniería decide dónde vive físicamente cada escenario. Esa división es deliberada, y es lo contrario del cuello de botella tradicional. Generar una prueba en cualquier capa ahora es barato. La vieja restricción, que nunca había tiempo para automatizar, se cayó. Lo que queda, y no se automatiza, es decidir qué demostrar y dónde es probable que un agente se desvíe de la especificación. Cada escenario del plan lleva cuatro etiquetas. | Etiqueta | Valores | Qué responde | | --- | --- | --- | | Sección | Camino feliz, reglas de validación, casos borde, accesibilidad | Qué tipo de comportamiento cubre | | Propósito de corrida | Smoke, funcional, regresión, usabilidad | Cuándo corre, y en qué pipeline | | Severidad | Crítica, alta, media, baja | Qué arreglar primero cuando falla | | Riesgo de cumplimiento | Una nota opcional por escenario | Dónde podría desviarse un agente de la especificación | El propósito de corrida describe cuándo corre un escenario, no cómo está construido. Un escenario puede llevar más de uno. El punto es habilitar corridas por subconjunto. La severidad es independiente de las otras dos. Un escenario de camino feliz puede ser crítico si es el flujo de compra, o medio si dibuja un avatar. Un caso borde puede ser alto si pierde datos en silencio, o bajo si es cosmético. ### La nota de riesgo de cumplimiento es la parte filosa Es obligatoria donde sea plausible que un agente entregue algo que pasa el escenario literal y viola la intención de la especificación. Nombra la implementación equivocada específica que el agente podría elegir. Una real: si la especificación dice que el endpoint devuelve los ítems ya ordenados por el backend, un agente puede ordenar la respuesta correctamente y aun así dibujarla en orden de inserción. Entonces el escenario verifica el orden visible, no la forma de los datos. ## Pruebas de cumplimiento de especificación Las pruebas estándar verifican que el código hace lo que hace el código. Las pruebas de cumplimiento verifican que el código hace lo que dijo la especificación. La regla: por cada funcionalidad entregada con un build guiado por agente, al menos una prueba verifica un requerimiento de la especificación que las pruebas generadas en el build no cubrieron. Otro autor, con otro propósito. Dónde valen más: | Escenario | Qué probar | | --- | --- | | Alcance de datos | Una consulta devuelve solo los registros del usuario autenticado, no todos | | Autorización | Una acción bloqueada en la interfaz también está bloqueada en la API y en la capa de datos | | Estado por defecto | Una funcionalidad inicia en el valor especificado, no en la primera opción ni en un default del código | | Persistencia de estado | Una selección sobrevive la navegación | | Camino negativo | Una entrada inválida se rechaza, no se acepta en silencio, ni se reemplaza por un default, ni truena | | Contrato | Nombres de campo, tipos, orden y forma coinciden con el contrato documentado, no solo un código de éxito | ## Quién es dueño de qué, y cuándo Cada artefacto tiene un dueño y un momento. | Artefacto | Cuándo | Dueño | | --- | --- | --- | | La especificación | Antes del build | Producto | | El plan de validación: escenarios por criterio, etiquetas, casos borde, trazabilidad | Antes del build | Calidad | | La mezcla de capas: qué escenarios corren como unitario, componente, integración, punta a punta o visual | En el plan | Ingeniería | | El código de las pruebas | Durante el build | Ingeniería, generado bajo supervisión | | La revisión de si la suite cubre la especificación | Después del build | Ingeniería | | Las pruebas de cumplimiento implementadas | Después del build | Calidad, apuntando a las brechas que predijeron las notas de riesgo | | Pruebas manuales | Después del build | Calidad, como herramienta de calibración y no como cobertura principal | El límite que importa: las pruebas del agente del build verifican que la implementación es consistente consigo misma. Las pruebas de calidad verifican que coincide con la especificación. Las dos son automatizadas. Autores distintos, propósito distinto. Todos en este flujo trabajan con un agente. Producto con un agente de especificación, calidad con un agente de planeación, ingeniería con un agente de build. Cuando esto dice "las pruebas del agente del build", se refiere al que manejó el desarrollador durante el build. ## La cobertura sube, nunca baja La cobertura debe corresponder a la complejidad y criticidad del trabajo. Un cambio de texto y un flujo nuevo de autenticación no necesitan la misma suite, pero los dos necesitan una. Cuando dudes de si un comportamiento necesita prueba, escríbela. Generar la prueba ahora es barato. Que se te pase el comportamiento no lo es. ## Las compuertas que pasa cada cambio Las compuertas son el piso, no la cobertura. Las pruebas de funcionalidad demuestran corrección. Las compuertas imponen el mínimo. | Compuerta | Qué impone | | --- | --- | | Lint | Cero errores, no cero advertencias | | Chequeo de tipos | Sin errores de tipo y sin supresiones | | Suite unitaria | Todo pasa | | Umbral de cobertura | Un mínimo a nivel de proyecto, más alto en rutas críticas de seguridad | | Escaneo estático de seguridad | Cero advertencias | | Escaneo de dependencias | Sin vulnerabilidades de severidad alta en dependencias de producción | Un umbral de cobertura a nivel de proyecto es un indicador rezagado. Autenticación, middleware de autorización, procesamiento de pagos y control de llaves necesitan cobertura casi completa sin importar el promedio del proyecto. **Las compuertas tienen que hacer fallar el build.** Una compuerta instalada y no aplicada es decoración. Si se desactiva una, la razón queda documentada y la fecha en que vuelve queda registrada. Auditamos un proyecto cuyo pipeline invocaba un comando de pruebas de un framework que el equipo no usaba: no encontró nada, no corrió nada, y reportó verde en cada merge mientras 93 archivos de prueba quedaban invisibles. Así se ve una compuerta sin aplicar desde afuera. ## Trazabilidad Cada criterio se mapea a una prueba que lo demuestra. El trabajo de la especificación es asegurar que el criterio exista antes del build. El trabajo del plan es mapearlo. Un criterio sin prueba no está terminado, y una prueba sin criterio no es evidencia. El [estándar de especificación](https://www.koombea.com/es/ai-pods/standards/specification/) cubre la otra mitad de esto, y la [auditoría de preparación](https://www.koombea.com/es/ai-pods/ai-readiness-audit/) es cómo averiguamos dónde está realmente un proyecto frente a los dos.