Flujo agentic supervisado. Cómo usamos agentes de IA

Un agente de IA puede leer un repositorio, proponer un plan, modificar código y ejecutar pruebas. Eso todavía no constituye un proceso de desarrollo fiable. Un equipo de producción necesita saber quién aprobó el objetivo, qué permisos recibió el agente, qué verificó y quién aceptó el cambio.

En Rise usamos un modelo Shadow con revisión. El agente prepara el cambio en un worktree aislado, pero V1 se inicia de forma manual. Las personas aprueban el plan, las excepciones, el merge y el despliegue. El sistema automatiza el trabajo repetible y conserva las pruebas.

Recomendamos este modelo a equipos que quieren acelerar la implementación sin perder el control del alcance, la seguridad y la publicación. No es la vía más rápida para cualquier experimento. Una petición ad hoc puede costar menos cuando la tarea es pequeña y reversible.

1. Prompts ad hoc

   Es rápido para una tarea pequeña y reversible. El contexto, los permisos y las pruebas dependen del operador en cada encargo.

2. Shadow con revisión

   Encaja en equipos de producción que necesitan controles medibles, correcciones limitadas y merge bajo control humano.

3. Fábrica autónoma

   Exige aislamiento fuerte, observabilidad, parada de emergencia y confianza en cambios automáticos de mayor alcance.

Qué significa Shadow con revisión

Shadow no significa que el agente se limite a observar a una persona. Trabaja dentro de un flujo de desarrollo real, pero no recibe permiso para modificar la base compartida ni la producción.

El trabajo empieza con un WorkOrder. Este documento fija el objetivo, los archivos permitidos, el riesgo, los controles exigidos y las acciones prohibidas. El agente prepara un plan a partir de ese contrato. La implementación solo comienza después de la aprobación humana.

Un solo writer recibe entonces su propio worktree. El aislamiento reduce el riesgo de que dos sesiones sobrescriban los mismos archivos o invaliden las pruebas de la otra. Las guías de Codex y Claude Code worktrees siguen el mismo principio operativo.

1. WorkOrder aprobado

   El alcance, el riesgo, los permisos y las pruebas exigidas se conocen antes de empezar.

2. Plan y aprobación humana

   El agente explica primero el enfoque, los límites afectados y la verificación.

3. Implementación aislada

   Un solo writer trabaja en un worktree aislado con un número limitado de correcciones.

4. Controles exactos

   Los comandos deterministas verifican el alcance acordado y generan resultados repetibles.

5. Revisión independiente y entrega

   Un contexto nuevo revisa el cambio. El evidence manifest llega a quien decide el merge y el despliegue.

Los controles fallidos devuelven el cambio a la implementación. Los hallazgos de la revisión lo devuelven a la planificación.

Los controles son comandos exactos del proyecto, no una petición genérica para probar el cambio. Si un control falla, el writer dispone de un número definido de correcciones. Después, el flujo se detiene y espera una nueva decisión.

Un reviewer con contexto nuevo lee el cambio terminado. No corrige en silencio el trabajo del writer. Devuelve los hallazgos a la planificación o emite una decisión razonada. El evidence manifest registra el alcance, los comandos, los resultados, los riesgos conocidos y las preguntas abiertas.

La última aprobación corresponde a una persona. El agente no hace merge ni despliega. Los rulesets de GitHub pueden exigir pull request, revisión y status checks correctos. El equipo sigue siendo responsable de aceptar el riesgo.

Qué automatizamos y qué deciden las personas

La automatización funciona cuando la misma entrada debe producir una decisión controlable y repetible. La aprobación humana pertenece a los puntos que exigen contexto empresarial, una excepción o la valoración del impacto operativo.

1. Pasos automatizados

   Validación del contrato, dry-run, reglas de estado, hooks, controles de CI y recopilación de pruebas.

2. Decisiones humanas

   Aprobación del plan, excepciones de alcance, aceptación del riesgo, merge, release y despliegue.

Nuestro modelo automatiza estas partes.

• La validación del contrato comprueba los campos obligatorios y los comandos permitidos del WorkOrder y el workflow.
• La inicialización dry-run muestra los archivos y cambios previstos sin escribir en el proyecto de destino.
• Las reglas de estado y permisos de YouTrack protegen las transiciones y los roles. YouTrack workflows está pensado para este tipo de reglas. YouTrack MCP ofrece herramientas gobernadas a los agentes.
• Los hooks bloquean un comando prohibido o inician un control en el momento definido. Claude Code hooks es un ejemplo de capa determinista alrededor del modelo.
• CI repite controles fiables en un entorno limpio.
• El evidence manifest reúne entradas, resultados y revisión en una sola entrega.

Las personas siguen aprobando el objetivo, los cambios de alcance, las excepciones de seguridad, la aceptación del riesgo, el merge, el release y el despliegue. Esta frontera también coincide con las recomendaciones de OWASP. Incluyen privilegio mínimo, aprobación humana para acciones sensibles, validación, rastro de auditoría y límites de recursos.

Siete workflows necesitan reglas distintas

Una plantilla universal resulta tentadora, pero un hotfix tiene otro propósito que un spike de investigación. A 24 de julio de 2026 tenemos siete tipos de workflow validados en el nivel de contrato. Las integraciones reales y los permisos se comprueban por separado en cada proyecto.

El límite no restringe cuántas veces puede pensar un desarrollador. Evita que el agente repita la misma estrategia sin una nueva decisión.

Por qué no bastan los prompts o CI

Los prompts ad hoc sirven para una tarea pequeña y fácil de revertir. Su debilidad está en la memoria del proceso. El operador reconstruye el alcance, los permisos y la verificación en cada sesión.

CI resuelve otra capa. Puede rechazar un cambio que no supera una prueba, pero normalmente no sabe si el agente podía modificar ese módulo, si el propietario aprobó el plan o si otro intento todavía tiene sentido económico.

Shadow con revisión añade un contrato antes de implementar y pruebas después. Es mejor para un equipo de producción que deberá explicar la decisión más adelante. A cambio, exige preparar el WorkOrder y dedicar tiempo a las aprobaciones humanas.

Una fábrica autónoma puede procesar más tareas independientes sin esperar. También necesita más aislamiento, observabilidad, parada de emergencia, gestión de identidad y confianza en el merge o el despliegue automáticos. Para un equipo pequeño es un sistema propio, no un ajuste del prompt.

Medir el valor sin porcentajes promocionales

No publicamos un porcentaje universal de ahorro. El resultado depende de la calidad del repositorio, las pruebas, la definición de la tarea y la experiencia del reviewer. Conviene comparar cambios aceptados antes y después de introducir el flujo.

Mida el tiempo desde la tarea aprobada hasta el cambio aceptado, el tiempo neto de revisión, el número de correcciones, las regresiones después del release, las acciones no autorizadas bloqueadas y el coste por cambio aceptado. El gasto de las propuestas rechazadas o inútiles también forma parte del resultado.

Las primeras semanas deben establecer una referencia. Solo entonces conviene cambiar límites, añadir otro workflow o automatizar una aprobación adicional.

Por dónde empezar

Empiece con un tipo de cambio recurrente, un repositorio y un inicio manual. Defina el WorkOrder, los comandos permitidos, la persona responsable de aprobar y las pruebas exigidas en la entrega. Ejecute primero un dry-run.

Nuestro artículo anterior sobre la persona dentro del ciclo de desarrollo con IA explica por qué el criterio experto sigue siendo necesario. La lista de gobierno para agentes de IA amplía el tema con datos, herramientas y parada de emergencia.

Si todavía está eligiendo el proceso adecuado, consulte nuestro servicio de automatización con IA. Un flujo agentic supervisado solo tiene sentido cuando el equipo puede identificar al responsable, las acciones prohibidas y el camino para aceptar un cambio terminado.