SENAR introduce compuertas de calidad para desarrollo de IA: cómo las especificaciones y métricas reducen errores

Un cuarto artículo de la serie SENAR fue publicado en Habr — una metodología abierta para el desarrollo con agentes de IA. Andrey Yumashev describe cómo las "compuertas" formales de entrada y salida deben reemplazar la disciplina personal de quienes especifican las tareas y reducir el número de errores que emergen solo después de que se cierra una tarea.

Cómo Funciona SENAR

SENAR es lo que el autor llama una metodología de ingeniería para trabajar con agentes de IA en el desarrollo. Surgió no de la teoría, sino de la práctica: según Yumashev, durante algo más de un año y medio, más de treinta proyectos han pasado por tal régimen, donde el código era cada vez más escrito por un agente, mientras que los humanos se ocupaban de la especificación, aceptación y análisis de fallos. La idea principal del artículo es simple: un agente no mantiene contexto entre ejecuciones, literalmente sigue la formulación y optimiza fácilmente de forma local si una tarea se describe de manera negligente.

Dentro de una única tarea, SENAR se basa en varios elementos obligatorios:

• objetivo formal de la tarea en lógica de producto
• criterios de aceptación verificables
• un bloque separado de escenarios negativos
• límites de cambios y contexto arquitectónico
• métricas de señal para la calidad del proceso

El autor enfatiza que esto no es un intento de reemplazar pruebas, linters o revisión de código. La lógica es diferente: las verificaciones normales examinan el código, mientras que las compuertas examinan la tarea en sí antes del inicio y la calidad de su aceptación después de la finalización. En la implementación práctica de TAUSIK, estos pasos se incorporan directamente en la herramienta, por lo que no pueden omitirse sin eludir el propio sistema. Esto, según el pensamiento del autor, protege al equipo del cansancio de "viernes", cuando las tareas más pequeñas con mayor frecuencia se filtran en producción con defectos.

Qué Verifican las Compuertas

En la entrada, SENAR utiliza la compuerta QG-0. No permite que una tarea comience el trabajo hasta que tenga una especificación mínima: un objetivo, criterios de aceptación, escenarios negativos, límites de cambios y un enlace al contexto arquitectónico. Yumashev discute por separado la suposición popular de que las tareas pequeñas se pueden entregar a un agente "en una sola línea." Precisamente estas tareas, según su observación, son las que más frecuentemente se rompen en producción, porque quien especifica la tarea mantiene detalles importantes en su cabeza pero no los fija en la tarjeta.

"El paso fue omitido no por el agente, sino por mí."

En la salida, funciona QG-2 — una compuerta que bloquea el cierre de la tarea hasta que el resultado se verifique contra las promesas hechas en la entrada. En el artículo, el autor destaca tres verificaciones obligatorias: confirmación de cada criterio de aceptación mediante prueba, verificación manual o artefacto; fijación de todas las correcciones manuales después del trabajo del agente; actualización de la memoria del proyecto si la tarea descubrió un nuevo caso límite o particularidad de infraestructura. Tal modo es necesario no por el bien de la burocracia, sino para que el agente en la siguiente tarea no repita los mismos errores debido a correcciones silenciosas hechas por un humano.

Métricas y Límites

Una sección separada del artículo se dedica a las métricas que SENAR utiliza como señales del estado del proceso. FPSR muestra la proporción de tareas resueltas en el primer intento; MIR — con qué frecuencia fue necesaria la corrección manual después del agente; DER mide ramas sin salida y pérdidas de tiempo; ERR refleja tareas que tuvieron que ser corregidas solo después del cierre.

Según el registro de trabajo del autor, en tareas de servidor en un dominio familiar, FPSR creció aproximadamente del 40% al 75–80%; MIR en el proyecto Sortule disminuyó del 20% al 5–7%, y ERR bajó a aproximadamente el 6% desde el 15%. Al mismo tiempo, Yumashev describe honestamente los límites de la metodología. Las compuertas ayudan poco donde el resultado es difícil de formalizar: en tareas sobre la "sensación" de interfaz, tono de texto o intuición de producto.

Tampoco ayudan al trabajar con servicios externos, si la documentación de terceros contradice el comportamiento real de la API. En tales casos, el proceso formal puede mantener la estructura de la tarea, pero no reemplaza el conocimiento del dominio, las pruebas manuales de hipótesis y la investigación preliminar de integración.

Qué Significa Esto

SENAR se formaliza no como un conjunto de recomendaciones, sino como un bucle operacional rígido para el desarrollo de IA: sin una especificación adecuada, el agente no inicia; sin aceptación confirmada, la tarea no se cierra. Para los equipos que ya están entregando código a los agentes, esta es una señal fuerte: el riesgo principal ahora no solo está en el modelo, sino en la calidad de la especificación de tareas, la memoria del proyecto y la disciplina del proceso.