SENAR introduce puertas de calidad para el desarrollo con IA: cómo las especificaciones y las métricas reducen los errores

Habr ha publicado el cuarto artículo de la serie sobre SENAR, una metodología abierta para el desarrollo con agentes de IA. Andrei Yumashev describe cómo unas «puertas» formales de entrada y salida deben sustituir la disciplina personal de quien plantea la tarea y reducir el número de errores que aparecen después de cerrarla.

Cómo funciona SENAR

El autor define SENAR como una metodología de ingeniería para trabajar con agentes de IA en el desarrollo. No nació de la teoría, sino de la práctica: según Yumashev, en año y medio más de treinta proyectos han pasado por este esquema. En ellos, el código lo escribía cada vez más el agente, mientras que la persona se encargaba de plantear las tareas, validarlas y analizar los fallos.

La idea central del artículo es sencilla: el agente no conserva el contexto entre ejecuciones, sigue la formulación al pie de la letra y tiende a optimizar localmente si la tarea está descrita de forma descuidada. En el ciclo de una tarea, SENAR se apoya en varios elementos obligatorios:

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

El autor subraya que no se trata de sustituir los tests, los linters ni la revisión de código. La lógica es otra: las comprobaciones habituales examinan el código, mientras que las puertas examinan la propia tarea antes de empezar y la calidad de su validación una vez terminada.

En TAUSIK, la implementación práctica, estos pasos están integrados directamente en la herramienta, de modo que no se pueden saltar sin eludir el propio sistema. Según el autor, esto es precisamente lo que protege al equipo del cansancio de los viernes, cuando las tareas más pequeñas son las que con más frecuencia llegan a producción con defectos.

Qué comprueban las puertas

A la entrada, SENAR utiliza la puerta QG-0. Esta no deja que una tarea pase a ejecución mientras no tenga una especificación mínima: objetivo, criterios de aceptación, escenarios negativos, límites de los cambios y una referencia al contexto arquitectónico.

Yumashev cuestiona expresamente la idea extendida de que las tareas pequeñas pueden darse al agente «en una línea». Según su experiencia, son precisamente esas tareas las que más fallan en producción, porque quien las plantea tiene los detalles importantes en la cabeza, pero no los deja anotados en la ficha.

«El paso no se lo saltó el agente, me lo salté yo».

A la salida funciona QG-2, una puerta que bloquea el cierre de la tarea hasta que el resultado se contrasta con lo prometido a la entrada. El autor destaca tres comprobaciones obligatorias: confirmar cada criterio de aceptación mediante un test, una verificación manual o un artefacto; registrar todas las correcciones manuales posteriores al trabajo del agente; y actualizar la memoria del proyecto si la tarea ha revelado un nuevo caso límite o una particularidad de la infraestructura.

Este régimen no existe por burocracia, sino para que el agente no repita los mismos errores en la siguiente tarea por culpa de correcciones que una persona introdujo sin dejar constancia.

Métricas y límites

Una parte específica del artículo se dedica a las métricas que SENAR utiliza como señales del estado del proceso. FPSR indica la proporción de tareas resueltas al primer intento; MIR, con qué frecuencia hizo falta una corrección manual después del agente; DER mide las vías muertas y el tiempo perdido; y ERR refleja las tareas que hubo que arreglar después de cerrarlas.

Según el registro de trabajo del autor, en tareas de servidor dentro de un dominio conocido, el FPSR subió aproximadamente del 40% al 75–80%; el MIR del proyecto Sortule bajó del 20% al 5–7%, y el ERR descendió aproximadamente del 15% al 6%.

Al mismo tiempo, Yumashev describe con honestidad los límites de la metodología. Las puertas ayudan poco cuando el resultado es difícil de formalizar: en tareas que dependen de la «sensación» de una interfaz, del tono de un texto o de la intuición de producto. Tampoco sirven cuando se trabaja con servicios externos cuya documentación contradice el comportamiento real de la API.

En esos casos, el proceso formal puede mantener la estructura de la tarea, pero no sustituye el conocimiento del dominio, la verificación manual de hipótesis ni la investigación previa de la integración.

Qué significa esto

SENAR no se plantea como un conjunto de consejos, sino como un circuito operativo estricto para el desarrollo con IA: sin una especificación adecuada, el agente no arranca; sin una validación confirmada, la tarea no se cierra.

Para los equipos que ya delegan parte del código en agentes, es una señal clara: el principal riesgo ya no está solo en el modelo, sino también en la calidad del planteamiento de las tareas, la memoria del proyecto y la disciplina del proceso.