Autonomía acotada: workflows deterministas y métricas para agentes de código

Ayer leí una idea que resume bien hacia dónde deberíamos llevar el desarrollo asistido por agentes: workflows programáticos y deterministas, reforzados por métricas cuantificables.

La idea aparece también en el vídeo Pi Extensible Workflows: Full Guide. El objetivo no es lanzar más agentes ni escribir prompts más largos, sino dejar de confiar en que un modelo recordará todas las condiciones y sabrá cuándo ha terminado correctamente.

Ese control no existe en el modelo. Debe existir alrededor de él.

El problema no es la autonomía

Un agente puede leer un repositorio, modificar archivos, ejecutar comandos, corregir errores y coordinar otros agentes. Pero sigue siendo un sistema probabilístico: puede omitir una comprobación, reducir el alcance de la solución, perder contexto o declarar que una tarea está terminada porque un test concreto pasa.

Pedirle que «continúe hasta que todo esté bien» delega en el modelo la definición de «todo» y de «bien».

La autonomía no es el problema. El problema es que el agente sea simultáneamente ejecutor, árbitro y fuente única de evidencia.

Workflows como límites ejecutables

Un workflow programático cambia el reparto de responsabilidades. El agente decide cómo resolver una tarea; el workflow decide:

qué fases existen y cuáles pueden ejecutarse en paralelo;
qué información recibe cada agente;
qué comandos y comprobaciones son obligatorios;
qué condiciones permiten avanzar;
cuántos reintentos existen;
cuándo una ejecución falla definitivamente.

Un prompt puede pedir:

Implementa la funcionalidad y asegúrate de que todos los tests pasan.

Un workflow puede imponer:

1. Analizar requisitos.
2. Implementar en una rama aislada.
3. Ejecutar tests y análisis estático.
4. Medir cobertura, duplicación y complejidad.
5. Ejecutar una revisión independiente.
6. Aceptar solo si todos los gates pasan.

El agente mantiene libertad durante la ejecución, pero no puede redefinir el criterio de éxito. Ese es el límite correcto: autonomía en la ejecución, determinismo en la validación.

No todo debe ser otro agente

Analizar requisitos, proponer una solución o revisar cambios sí requiere criterio. Comprobar el código de salida de un comando, limpiar un worktree o verificar que un commit está integrado no necesita inteligencia generativa.

Agente → propone y modifica
Herramienta → ejecuta y mide
Workflow → decide si se puede avanzar
Agente → corrige si un gate falla
Workflow → vuelve a medir

Usar código determinista para tareas deterministas reduce coste, latencia y superficie de error. También evita gastar contexto en trabajo que una shell, un compilador o un analizador ya resuelven mejor.

Métricas como contrato de calidad

Los gates deben basarse, siempre que sea posible, en evidencia verificable:

Cobertura: conviene medir ramas y código nuevo, no solo líneas totales. Una línea ejecutada no implica que su resultado haya sido comprobado.
Mutation score: comprueba si los tests detectan cambios reales de comportamiento. Es más caro, así que puede reservarse para lógica de dominio, permisos, cálculos críticos o código modificado.
Duplicación: resulta más útil impedir que aumente en código nuevo que perseguir un porcentaje global perfecto.
Complejidad ciclomática: señala funciones difíciles de entender y probar, aunque el número nunca sustituye al criterio técnico.
Seguridad: vulnerabilidades críticas, secretos o permisos inseguros deben bloquear la entrega, no quedar como recomendaciones opcionales.

Las métricas tampoco son garantías automáticas. Si solo exigimos cobertura, aparecerán tests que ejecutan líneas sin comprobar comportamiento. Si solo exigimos complejidad baja, la lógica puede fragmentarse en funciones pequeñas e igualmente difíciles de entender.

Por eso deben medir riesgos distintos y, cuando sea posible, comparar el cambio con la rama base. El código nuevo no debería empeorar el sistema aunque el promedio global todavía parezca aceptable.

Cerrar el circuito

Medir no sirve si el resultado no cambia la ejecución. Un pipeline mínimo podría ser:

analyze → plan → implement
                     ↓
        tests + análisis + métricas
                     ↓
             revisión independiente
                     ↓
                quality gate
               ↙            ↘
       corregir y repetir    entregar

El gate no debería interpretar la prosa del agente. Debe consumir resultados estructurados:

{
  "tests": { "passed": true },
  "coverage": { "branchDelta": 1.2 },
  "mutation": { "score": 82.1 },
  "duplication": { "newCode": 0.4 },
  "complexity": { "delta": 0 },
  "security": { "critical": 0 }
}

Los límites deben definirse antes de ejecutar y quedar versionados. Los números concretos dependerán del repositorio y del riesgo de cada módulo; lo importante es que las reglas sean explícitas y reproducibles.

Pi Taskflow y el siguiente paso

Esta es la razón por la que estoy configurando pi-taskflow en Pi. Sus fases permiten separar análisis, planificación, ejecución, revisión y verificación. Los modelos más capaces pueden reservarse para decisiones de mayor riesgo, mientras que los modelos rápidos se ocupan de exploración o comprobaciones mecánicas.

La parte importante no es tener muchos agentes. Es que cada uno tenga una responsabilidad acotada y que el resultado pase por gates externos al modelo.

Los flujos con paralelismo o reintentos también necesitan límites de tiempo, tokens, coste y número de intentos. Una condición imposible no debería convertirse en una cadena indefinida de ejecuciones.

La regla es sencilla: ningún bucle de autonomía sin una condición de salida verificable y un límite de seguridad.

El control real no está en el prompt

Más contexto, reglas y recordatorios ayudan, pero no resuelven el problema fundamental: el modelo sigue interpretando las instrucciones y decidiendo si las ha cumplido.

El control real debe desplazarse hacia fuera: workflows definidos como software, comandos reproducibles, métricas verificables, límites de coste, aislamiento de cambios y revisión independiente.

No se trata de eliminar la autonomía, sino de hacer que opere dentro de un sistema que pueda decir no.

Los agentes pueden decidir cómo llegar a una solución. No deberían decidir solos si la solución es aceptable.