Flujo Devian
Del ticket al pull request, con una persona en el medio
Devian convierte una especificación o un ticket de Jira en commits atómicos: planifica sobre el repositorio real, los audita con gates multi-agente y valida cada cambio con el compilador, el linter y los tests antes de dejar el diff en tu puerta.
Tres pilares
Un flujo que frena la generación ciega de código
01
Contexto acotado
Cada agente recibe solo los archivos indispensables de su subtarea. Al planificar, el scout lee el repositorio real para no inventar rutas ni stack.
02
Human-in-the-loop
El plan, cada diff y el pull request pasan por una puerta explícita. Los agentes proponen y corrigen, pero nunca aplican un cambio sin que una persona lo revise.
03
Validación por máquina
El compilador, el linter y los tests son el oráculo de verdad. Sus comandos salen del propio repositorio y el error textual vuelve al agente para corregirse.
Cómo funciona
Un bucle determinista con dos gates
01
Planificar
El arquitecto desglosa la especificación en un DAG de subtareas atómicas. Cada una lista los archivos que su objetivo necesita, guiado por el perfil detectado del repositorio.
02
Gate de plan
Cuatro lentes (cobertura, atomicidad, riesgo y verificabilidad) auditan el plan antes de generar código. Si alguna bloquea, el gate escala en lugar de aprobarlo.
03
Ejecutar y verificar
Por subtarea: el scout acota el contexto, el coder genera el parche y la verificación corre typecheck, lint y tests, con reintentos sobre el stdout crudo.
04
Revisar y abrir el PR
Seis lentes revisan el diff, un escéptico adversarial intenta refutar cada hallazgo y, sin bloqueos, un agente de release abre el pull request.
Módulos base
Seis módulos, cada uno con una responsabilidad
Sobre ellos se montan los gates: cuatro lentes auditan el plan y seis lentes, más un escéptico adversarial, auditan el diff. Sin bloqueos, un agente de release abre el PR; con un bloqueo, la tarea se detiene en la puerta humana.
Módulo 1
Architect
Desglosa la especificación en un DAG de subtareas acotadas.
Módulo 2
Scout
Monta el contexto mínimo por subtarea bajo un presupuesto de tokens.
Módulo 3
Coder
Genera el parche atómico de la subtarea aprobada.
Módulo 4
Verifier
Corre typecheck, lint y tests y reintenta con el stdout crudo.
Módulo 5
Gatekeeper
Deja el diff en la puerta humana y cometea o revierte.
Módulo 6
Janitor
Purga el contexto y abre la siguiente subtarea.
Guardarraíles
Hechos reales, no supuestos
Planifica sobre el repositorio real
Antes de planificar, el harness detecta el lenguaje, el gestor de paquetes y los comandos de verificación del repositorio. El plan y los criterios de aceptación usan esos hechos, no supuestos.
Ejecuta en un checkout temporal
El repositorio configurado se clona en un directorio temporal por proyecto y cada tarea ramifica desde ahí, sin tocar el árbol de trabajo de tu máquina.
Recuerda lo que aprende
Cada fase (plan, contexto, parches, revisión y release) queda en la memoria del proyecto, de modo que el harness arrastra el contexto entre tareas y sesiones.
Siguiente paso
Empieza por una tarea
Elige un proyecto, toma un ticket de Jira y deja que el harness proponga el cambio. Tú revisas y apruebas.