Evidence-Gated Agentic Development: dentro del bucle EG
Un pipeline en rojo es costoso de una manera que no tiene nada que ver con el cómputo. Un cambio generado por un agente falla en CI a las 6 de la tarde, y ahora tú eres el motor de diagnóstico: revisando logs de jobs, decidiendo si el fallo es el código, la prueba, el escáner o el entorno, y luego decidiendo quién tiene permiso para arreglarlo. Cuando la IA escribe código más rápido de lo que puedes revisarlo, cada fallo se convierte en una investigación manual, y cada reparación manual es una oportunidad para algo peor: un arreglo que pone el pipeline en verde bajando el estándar en silencio. Que los pipelines fallidos requieran demasiado diagnóstico y reparación manual no es una molestia a la velocidad de la IA — es el cuello de botella que decide si el desarrollo agéntico es una ventaja o un pasivo.
La respuesta del libro blanco de Koinessa a esto no es un mejor chatbot. Es un modelo de entrega — Evidence-Gated Agentic Development (EGAD) — con un bucle de operación específico, un vocabulario de resultados específico, y una regla estricta sobre quién nunca puede tocar la definición de éxito. Este artículo forma parte de una serie sobre la brecha de verificación en el desarrollo agéntico; aquí abrimos la sección 4 del libro blanco, el propio bucle EG.
Qué es realmente el bucle EG
El libro blanco define EGAD como un modelo de entrega de software en el que los agentes de IA producen e integran cambios pequeños en la rama principal, mientras que la autoridad de commit, push, promoción y release permanece limitada por verificación determinista, evidencia firmada, gates de política y excepciones controladas por humanos. Los agentes hacen la producción. Todo lo que acerca el código a producción pasa por la puerta de la prueba.
El bucle tiene diez etapas, y el libro blanco es explícito en que cada una existe para eliminar un modo de fallo específico: observar el estado actual; recordar decisiones, arreglos y fallos previos desde la memoria compartida persistente; planificar trabajo acotado con requisitos de verificación declarados; reclamar la propiedad mediante arriendos y reclamos de archivo; compilar un paquete de contexto acotado a partir del estado canónico; ejecutar dentro del límite reclamado; verificar con herramientas deterministas que emiten estados de resultado canónicos; aprobar las transiciones con consecuencias según la política, dejando las excepciones en manos humanas; enviar a producción y observar el resultado desplegado, no solo el merge; y aprender — escribir el resultado verificado de vuelta en la memoria, donde lo encontrará el recall de la siguiente sesión.
Tres propiedades separan esto de la «programación autónoma», y cada una se corresponde directamente con el dolor de diagnóstico y reparación descrito arriba.
La evidencia es la moneda de aceptación
Primero: la autoridad se deriva del estado, no de la confianza. Que un agente reporte que el trabajo está completo no cambia nada. El paquete de evidencia adjunto al commit actual es lo que cambia el estado. Esta es la única decisión de diseño que elimina la mayor parte de la adjudicación manual — nunca tienes que decidir si crees un resumen, porque los resúmenes no son el mecanismo.
Segundo: las capacidades son peldaños, no un interruptor. Generate, stage, commit, push, merge, promote y deploy son capacidades delegables separadas, que se amplían por clase de tarea a partir del historial verificado. El libro blanco señala que los lotes pequeños basados en la rama principal hacen que cada peldaño sea barato de comprobar, citando la guía de capacidades de DORA sobre el desarrollo basado en la rama principal. DORA — el programa DevOps Research and Assessment — describe la práctica como desarrolladores que dividen el trabajo en lotes pequeños y hacen merge a la rama principal al menos una vez al día, con ramas que duran horas en lugar de semanas; su análisis de los datos de investigación de 2016 y 2017 encontró un mayor desempeño de entrega de software y operativo en equipos con tres o menos ramas activas, merges diarios, y sin code freezes ni fases de integración. Los lotes pequeños no son una preferencia estética — son lo que hace viable la verificación por cambio, y por eso los peldaños del bucle EG funcionan al ritmo de los agentes.
Tercero: la verificación es independiente de la generación. Herramientas deterministas, modelos separados o humanos evalúan; el generador nunca califica su propio trabajo. La política — codificada como reglas versionadas y comprobables en lugar de texto de prompt — decide si la evidencia satisface el perfil. El libro blanco señala a Open Policy Agent como una fuente del patrón general de política como código, cuidando de aclarar que Koinessa no afirma incorporar a OPA.
Seis formas en que puede terminar una comprobación — y por qué eso arregla el diagnóstico
Esta es la parte del modelo que ataca más directamente el triage manual. Un pipeline que solo conoce verde y rojo clasificará mal un escáner ausente como un escaneo limpio. El modelo de verificación de Koinessa distingue seis estados de resultado canónicos — PASS, FAIL, SKIPPED-NOT-APPLICABLE, INFRASTRUCTURE ERROR, TOOL MISSING y EVIDENCE INVALID — y este modelo está en vivo.
El valor diagnóstico es inmediato. FAIL significa que el código no alcanzó el estándar; INFRASTRUCTURE ERROR significa que lo que está roto es el runner, no el cambio; TOOL MISSING significa que una comprobación nunca corrió y por lo tanto no se verificó nada; EVIDENCE INVALID significa que un comprobante no sobrevivió al escrutinio. Esto es verificación fail-closed en la práctica: un éxito no verificado nunca es un pass, y la ausencia de evidencia se enruta a su propio estado en lugar de subir en silencio a verde. Cuando el pipeline está en rojo, la primera pregunta — «¿es esto el código, el entorno o la evidencia?» — ya está respondida por la etiqueta de estado. El diagnóstico empieza en la segunda pregunta.
Un séptimo estado se lanzó con EGD-002 (en vivo, 12/12 historias cerradas el 2026-08-15): ABSTAIN-SPEC-CONFLICT, una ruta premiada y de primera clase para que un agente declare que el trabajo no se puede completar legítimamente bajo su especificación actual. El razonamiento es directo: la alternativa medida a una salida legítima es hacer trampa, y una ruta explícita de inviabilidad produjo un resultado de 54 a 9 en un experimento separado citado del trabajo de ImpossibleBench sobre LLM que explotan casos de prueba. Dale al agente una manera honesta de decir «esta especificación es contradictoria», y tendrá menos motivos para fingir un pass.
La ley de Goodhart es la razón por la que el bucle de reparación no puede tocar las pruebas
Esta es la regla que sostiene todo el diseño, y responde al temor que la mayoría de los fundadores técnicos nombran primero sobre el CI autorreparable: ¿qué impide que el agente reparador debilite una prueba para forzar un resultado en verde?
Los sistemas que optimizan aprenden a satisfacer la medición en lugar del objetivo — la ley de Goodhart. El libro blanco cita el artículo de 1997 de Marilyn Strathern en European Review, "'Improving ratings': audit in the British University system", un estudio antropológico de la «explosión de auditoría» en la educación superior británica cuya observación más citada es que la auditoría hace más que monitorear — tiene vida propia y esa vida pone en riesgo aquello que audita. Su formulación de la idea — cuando una medida se convierte en un objetivo, deja de ser una buena medida — tiene treinta años y describe exactamente lo que un agente reparador sin restricciones le hace a una suite de pruebas.
Así que el bucle de reparación local de Koinessa (Ralph, en vivo) está acotado por construcción. Puede arreglar código, configuración, enrutamiento o infraestructura. No puede bajar umbrales, eliminar pruebas significativas, deshabilitar escáneres, ni convertir comprobaciones obligatorias en opcionales. La regla se generaliza más allá de las reparaciones: el optimizador no debe controlar la definición de éxito. La misma lógica gobierna la mejora de modelos — un arreglo de campeón-retador juzga las alternativas con criterios independientes como la tasa de éxito verificado, los ciclos de reparación y la tasa de regresión después del despliegue, y un humano promueve una afirmación solo después de revisar evidencia medida. El comportamiento de alto impacto gana autoridad primero mediante simulación: un agente reparador parchea un espacio de trabajo aislado y pasa la verificación antes de que cambie cualquier estado compartido.
Para el fundador, el resultado de negocio es que la reparación del pipeline se puede delegar sin delegar el estándar. El bucle de reparación es automatización con puerta humana en el sentido preciso del término: opera de forma autónoma dentro de un límite que no puede redibujar.
Qué piden realmente los organismos de normalización
¿Es esta una arquitectura idiosincrática, o una implementación de expectativas reconocidas? El libro blanco la ancla a dos publicaciones del NIST.
El NIST AI Risk Management Framework — AI RMF 1.0 (NIST AI 100-1) y su Generative AI Profile (AI 600-1) — es un marco voluntario para gestionar el riesgo de IA organizado en torno a las funciones de gobernar, mapear, medir y gestionar, con el perfil de IA generativa enumerando riesgos y acciones sugeridas específicas para sistemas como la programación agéntica. El NIST Secure Software Development Framework, SP 800-218 v1.1, publicado en febrero de 2022, recomienda un conjunto central de prácticas de desarrollo de software seguro para integrar en cualquier SDLC precisamente porque, como el propio documento señala, pocos modelos de SDLC abordan la seguridad del software en detalle; el SP 800-218A, finalizado en 2024, lo extiende con un perfil comunitario de IA generativa.
La postura del libro blanco hacia estos marcos vale la pena repetirla: los marcos son orientación, un control es comportamiento implementado, la evidencia demuestra que el comportamiento ocurrió, y la certificación es una determinación aparte. Los paquetes de evidencia de Koinessa están construidos para corresponderse con las expectativas de garantía de estilo SSDF — cuando un cliente, un inversor o un auditor pregunta por qué se permitió un release, la respuesta es un comprobante, no un relato. No se hace ninguna afirmación de certificación o cumplimiento.
Niveles de riesgo: el mismo bucle, presión distinta
El bucle EG no aplica una sola intensidad de verificación a todo. Como cubre el artículo complementario sobre autonomía por niveles de riesgo, cada elemento de trabajo en Koinessa lleva un nivel de riesgo legible por máquina, de R0 a R3, que deriva de forma determinista su perfil de verificación y su política de aprobación. Este comportamiento adaptativo al riesgo está en vivo de extremo a extremo (AAV-001, implementado el 2026-08-12). El filo cortante: el trabajo R2 y R3 ni siquiera se puede reclamar sin un brief de tarea válido según el esquema — un gate de conversación-a-contrato aplicado dentro del compare-and-set del reclamo — de modo que una conversación exploratoria nunca puede deslizarse hacia una implementación de alto riesgo.
El bucle también se come su propia receta. La deuda de verificación se mide a sí misma: las métricas de fuga de defectos, carga de revisión, retrabajo y lead time caen en el mismo warehouse que cualquier otro comprobante. Y el manifiesto de evidencia acepta evidencia conectable por dominio, con comprobaciones de firmware y hardware como la primera extensión más allá del CI de software, bajo la regla permanente de que compilar no es demostrar. El libro blanco mantiene un matiz: su inventario de repositorio del 2026-08-23 cuenta 1,614 archivos de prueba o especificación indexados en git, y ese inventario no afirma que las suites se hayan vuelto a ejecutar.
Lo esencial
Los pipelines fallidos consumen horas del fundador porque la mayoría de los sistemas de entrega confunden tres preguntas: qué se rompió, qué tiene permiso para arreglarlo, y qué demuestra que el arreglo es real. El bucle EG las separa por construcción — los estados de resultado canónicos responden la primera, la autoridad de reparación acotada la segunda, la evidencia firmada la tercera. Los agentes se mueven rápido dentro de este sistema no porque se confíe en ellos, sino porque los límites son lo bastante explícitos como para que la velocidad sea segura: la evidencia es la moneda de aceptación, la verificación es fail-closed, y el optimizador nunca controla la definición de éxito. El argumento completo está en el libro blanco de Koinessa, sección 4.