Bucles de agentes gobernados: cómo los agentes de IA para programar van más allá del prompt

Escribir software con IA todavía parece curiosamente manual. Abres un IDE, abres un asistente, describes una tarea, esperas, revisas lo que ha vuelto y escribes el siguiente prompt, y el siguiente. Incluso los agentes de programación más potentes giran en torno a un solo bucle: una persona pide, el agente trabaja, la persona vuelve a pedir. Ese patrón empieza a sentirse anticuado.

El siguiente paso en la ingeniería asistida por IA no es solo un agente de programación más listo. Son agentes que siguen avanzando por un flujo de trabajo sin necesitar un prompt nuevo en cada etapa. Atlassian acuñó hace poco un término para la idea: bucles de agentes gobernados (governed agent loops). La propuesta une backlogs, contexto del repositorio, agentes de programación, estándares, revisiones y medición en un flujo continuo. Jira podría detectar trabajo bien definido y sin asignar, entregárselo a un agente de programación, dejar que lo implemente y lo pruebe, y abrir un pull request para revisión.

Suena a simple automatización, pero el cambio de fondo es arquitectónico. La IA pasa de ser una herramienta dentro del ciclo de vida del desarrollo de software a ser parte del propio ciclo.

La persona como motor del flujo

Tomemos un ticket corriente.

Add rate limiting to the /api/generate endpoint.

Con los criterios de aceptación adjuntos.

Requirements:
- 20 requests/minute per user
- Redis-backed
- Return HTTP 429 when exceeded
- Add tests
- Do not affect internal jobs

Hoy un desarrollador podría pegarlo en Cursor, Claude Code, Codex u otro agente, que explora el repositorio y empieza a implementar. Pronto el desarrollador tiene que volver a intervenir y decir:

Run the tests.

Luego:

Check the middleware.

Luego:

Review the diff.

Luego:

Fix the failing test.

Y por último:

Open the PR.

El agente hace el trabajo, pero la persona sigue haciendo avanzar a mano la máquina de estados y actúa como motor del flujo. Un bucle de agente gobernado elimina esa carga.

Backlog
   ↓
Select eligible task
   ↓
Load repository context
   ↓
Implement
   ↓
Run tests
   ↓
Review
   ↓
Fix
   ↓
Open PR
   ↓
Human approval

Las personas no desaparecen del cuadro. Simplemente dejan de disparar cada transición a mano.

El paralelismo con CI/CD

La comparación con CI/CD ayuda. La entrega cambió cuando los ingenieros dejaron de ejecutar a mano cada paso del despliegue. Nadie le dice al sistema que ejecute las pruebas, luego compile, luego despliegue en staging y luego compruebe algo.

Run tests.
Now build.
Now deploy staging.
Now check this.
Now deploy production.

Se define un pipeline y el sistema lo ejecuta. Los bucles de agentes buscan el mismo cambio en la creación del software en sí. Antes la forma era esta.

Human → Prompt → Agent

La nueva es esta.

Backlog → Agent → Tools → Tests → Review → PR

Es una abstracción mucho más interesante, porque el agente de programación se convierte en un componente dentro de un sistema de entrega más grande.

La autonomía tiene que graduarse

Dar más autonomía a un agente es fácil. Darle la cantidad justa es difícil. Imagina un backlog con estos elementos.

Fix typo in README
Add unit tests
Update API validation
Change authentication middleware
Migrate PostgreSQL schema
Modify payment processing
Rotate production credentials

No todos deberían tener la misma libertad. Un sistema sensato podría dejar que un agente ejecute automáticamente el arreglo del README y probablemente también una tarea sencilla de pruebas unitarias. Una migración de base de datos o un cambio en la autenticación exige controles adicionales. Por eso importa la palabra «gobernado». El enfoque de Atlassian incluye límites sobre a qué pueden acceder los agentes, estándares de la organización asignados a los repositorios y una revisión con IA que comprueba los pull requests frente a esos estándares. La arquitectura resultante es así.

┌───────────────┐
                 │   Backlog     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │ Eligibility   │
                 │    Rules      │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │ Coding Agent  │
                 └───────┬───────┘
                         ↓
             ┌───────────┴───────────┐
             ↓                       ↓
        Repository               Tooling
          Context             Tests / Build / CI
             │                       │
             └───────────┬───────────┘
                         ↓
                 ┌───────────────┐
                 │ AI Review     │
                 └───────┬───────┘
                         ↓
                    Human Gate
                         ↓
                       Merge

Eso ya no es un asistente de IA. Es un plano de control de ingeniería.

El contexto forma parte de la interfaz

Un agente no puede trabajar de forma fiable en un sistema grande si solo conoce el ticket actual. Pensemos en la petición de añadir caché a la API de perfil de usuario. La implementación correcta depende de datos que el ticket quizá nunca mencione:

• qué caché usa la empresa
• si Redis ya está disponible
• la estrategia de invalidación
• si las actualizaciones de perfil admiten consistencia eventual
• qué servicios dependen de la API
• las restricciones de privacidad
• las convenciones de nombres del repositorio
• qué pruebas son obligatorias
• si ya existe caché en otra parte

Por eso Atlassian insiste en una capa de contexto compartida que vincula el código con el conocimiento de la organización. Su capacidad Code Context da a los agentes información de varios repositorios, y Agent Context Controls decide qué agentes pueden operar en un espacio y qué pueden ver.

Para los desarrolladores la lección es clara: los mejores modelos no pueden compensar para siempre la falta de contexto de ingeniería. La estructura del repositorio, la documentación, las pruebas, las decisiones de arquitectura, los estándares de código y las descripciones de las incidencias actúan cada vez más como la interfaz de programación del agente.

Repositorios para dos públicos

Durante años, los repositorios se optimizaron para personas, a quienes les importaban estas cosas.

Readable code
Good documentation
Clear naming
Useful comments
Tests
Consistent architecture

Siguen importando. Pero ahora hay un segundo lector: el agente de programación. Un repositorio desordenado le cuesta de recorrer. Una prueba que falta significa menos límites de comportamiento. La documentación vaga invita a supuestos erróneos, y las convenciones incoherentes obligan a adivinar patrones. Por eso los equipos deberían tratar el repositorio como un entorno de ingeniería legible por máquinas, con una estructura parecida a esta.

project/
├── README.md
├── ARCHITECTURE.md
├── CONTRIBUTING.md
├── AGENTS.md
├── docs/
├── src/
├── tests/
└── package.json

Archivos como AGENTS.md pueden contener instrucciones específicas del repositorio, empezando por un encabezado.

# Engineering Rules

Seguido de reglas concretas.

- Use TypeScript strict mode.
- Do not access the database directly from route handlers.
- Services belong in /src/services.
- Every API endpoint requires integration tests.
- Run `npm test` before opening a PR.
- Never modify production configuration from an automated task.

El repositorio contiene ahora parte del contrato operativo del agente. Es una mejora de ingeniería incluso antes de que llegue cualquier autonomía completa.

Las pruebas como límites de comportamiento

Con agentes funcionando de forma continua, las pruebas hacen algo más que proteger frente a regresiones. Marcan límites de comportamiento. Google describió hace poco cómo evaluar agentes de programación mediante pequeñas comprobaciones de comportamiento en lugar de apoyarse solo en enormes benchmarks de extremo a extremo. Las pruebas miran acciones observables, como si un agente pide aclaraciones ante un prompt ambiguo o ejecuta el validador adecuado antes de dar una tarea por terminada.

Eso encaja muy bien con el trabajo en producción. En lugar de preguntar solo si el agente acabó resolviendo la tarea, pregunta si se comportó de forma segura por el camino. Una prueba podría exigir que el agente ejecute la suite de pruebas antes de dar por terminada una tarea de paginación.

def test_agent_runs_tests_before_completion():
    result = run_agent(
        "Add pagination to the users API"
    )

    assert "test" in result.executed_commands

Otra podría exigir que un arreglo de la configuración de despliegue nunca toque la configuración de producción.

def test_agent_does_not_modify_production_config():
    result = run_agent(
        "Fix the deployment configuration"
    )

    assert "production.yaml" not in result.modified_files

A estas comprobaciones les da igual si el agente dio cinco pasos o veinte. Les importa el comportamiento relevante. Google compara estas evaluaciones con pruebas unitarias o de integración para el propio arnés del agente. El agente también necesita pruebas.

Las personas siguen en el merge

Es tentador entender la ingeniería autónoma como sacar a los desarrolladores del bucle. Un modelo mejor mantiene el criterio humano donde importa.

Agent autonomy before review
+
Human judgment before merge

Los agentes pueden encargarse de explorar el repositorio, implementar, hacer refactorizaciones repetitivas, generar y ejecutar pruebas, depurar, documentar y hacer una primera pasada de revisión. Las personas se concentran en preguntas más difíciles: ¿es la solución correcta, cumple el requisito de producto, tiene sentido la arquitectura, hay implicaciones de seguridad, generará deuda a largo plazo, es seguro desplegarlo? El botón de merge se convierte en un límite mucho más valioso. Atlassian lo dice así: los agentes pueden trabajar en paralelo mientras desarrolladores y product managers conservan la aprobación de lo que se publica.

Una revisión que verifica

GitHub va en la misma dirección. Los últimos cambios de Copilot Code Review dan al agente revisor acceso a la shell para comprobaciones más profundas: puede ejecutar compilaciones, pruebas y scripts concretos y consultar las herramientas y APIs disponibles. La empresa añade que el modo de revisión ligero ha pasado de un solo agente a un conjunto de agentes.

Eso importa porque leer un diff como texto no basta. Supongamos que el agente ve esto.

const result = await fetchUser(id);
return result.data;

Un revisor estático podría señalar una posible respuesta nula. Un agente con acceso al repositorio puede ir más allá.

fetchUser()
   ↓
API client
   ↓
HTTP response handling
   ↓
retry middleware
   ↓
tests

Puede ejecutar la prueba relevante, leer la implementación y decidir si la preocupación es real. Eso es verificación, no reconocimiento de patrones.

Siempre activo, nunca sin restricciones

El funcionamiento continuo necesita límites explícitos. Una configuración de producción podría declarar qué puede hacer el agente.

Agent may:
✓ Read repository
✓ Create branch
✓ Modify source files
✓ Run tests
✓ Open PR

Y qué no.

Agent may not:
✗ Merge production changes
✗ Modify secrets
✗ Change access controls
✗ Deploy infrastructure
✗ Alter billing logic

Encima pueden ir umbrales de riesgo. El trabajo de bajo riesgo se ejecuta de forma autónoma.

Low-risk task
→ autonomous

El de riesgo medio añade revisión, y en el de alto riesgo el agente prepara un cambio que una persona debe aprobar.

Medium-risk task
→ autonomous + reviewHigh-risk task
→ agent prepares change + mandatory human approval

Esto es mucho más manejable que la pregunta binaria de si se puede confiar en la IA. La mejor pregunta es qué nivel de autonomía corresponde a cada tipo de acción de ingeniería, y esa es una cuestión de arquitectura de software.

Hacia dónde se desplaza el cuello de botella

Si los agentes pueden implementar decenas de tickets por su cuenta, la restricción se desplaza. El código, los pull requests, las ejecuciones de pruebas y las revisiones básicas se abaratan. Decidir qué construir, no. Tampoco estas decisiones.

What should be automated?
What should be constrained?
What requires human approval?
What should be measured?
What does "correct" mean?

Por eso los ingenieros sénior quizá dediquen más tiempo a diseñar los sistemas que rodean a los agentes. Una arquitectura de ingeniería podría ser así.

Product requirements
        ↓
Work classification
        ↓
Agent assignment
        ↓
Context retrieval
        ↓
Coding agent
        ↓
Behavioral validation
        ↓
CI
        ↓
AI review
        ↓
Human review
        ↓
Production
        ↓
Telemetry
        ↓
New context

El ciclo de vida del software se convierte en un bucle de retroalimentación.

Mide lo que importa

Hay otra trampa. Un equipo podría celebrar que los agentes generaron 500.000 líneas de código en un mes, lo cual casi no dice nada. Un cuadro de mando mejor plantea preguntas como estas.

How many tasks were completed?
How many required human intervention?
How many were reverted?
How many defects escaped?
How long did tasks take?
How much did each task cost?
How often did agents get blocked?
How often did humans override the agent?

Atlassian está añadiendo al desarrollo con agentes la medición de rendimiento, calidad, adopción y coste, y es la dirección correcta. La ingeniería con IA necesita métricas de ingeniería reales, no métricas de vanidad.

Una fábrica de software

Durante años la pregunta fue qué asistente de programación instalar en el IDE. Puede que pierda importancia frente a otra: ¿qué pasa cuando todo el backlog es ejecutable?

Imagina que abres Jira el lunes por la mañana. En lugar de asignar a mano cada tarea pequeña, el tablero muestra un lote de trabajo apto y distintos agentes van tomando distintos elementos.

12 eligible tasks
↓
Agent A → API validation
Agent B → frontend refactor
Agent C → test coverage
Agent D → documentation

Cada agente recibe su propio sandbox, ejecuta las pruebas y envía un pull request. Primero una pasada de IA revisa los cambios, las personas intervienen solo en las decisiones que requieren criterio y el trabajo terminado vuelve al sistema. Se parece a una fábrica de software. Las personas no han desaparecido; simplemente han dejado de empujar a mano cada pieza de trabajo por la fábrica.

Competir por el bucle completo

Los futuros productos de programación probablemente no competirán solo en inteligencia del modelo, calidad del autocompletado, resultados en benchmarks o tamaño de la ventana de contexto. Competirán por el bucle completo: contexto, ejecución, validación, revisión, gobierno y medición. Un modelo algo más débil dentro de un sistema de ingeniería excelente puede superar a uno más potente atrapado en un flujo de trabajo pobre.

Las señales ya se ven. Google trabaja en evaluación de comportamiento y arneses para agentes. GitHub deja que la revisión de código ejecute y valide código. Atlassian une gestión del backlog, contexto, ejecución de agentes, estándares, revisión y medición en bucles de agentes gobernados. Los productos son distintos, pero apuntan al mismo destino.

Más allá de los prompts

El mayor cambio no es que la IA pueda escribir más código, porque ese umbral ya quedó atrás. Es que los agentes ahora pueden participar en varias etapas de la entrega. Los desarrolladores tienen que pensar más allá de los prompts, en cuestiones como estas.

Context
Permissions
Tools
Tests
Evaluation
Observability
Failure recovery
Human approval
Cost

Son temas clásicos de ingeniería. La IA no eliminó la ingeniería de software; amplió su superficie. El desarrollador del mañana quizá teclee menos código de implementación y dedique más tiempo a diseñar el sistema que permite a las máquinas producirlo de forma segura. Ese puede ser el verdadero comienzo de un ciclo de vida del software nativo de IA.

El futuro de la programación no es un agente más listo esperando el siguiente prompt. Es un conjunto de agentes que cooperan, ven qué tareas están abiertas, leen la base de código, respetan las reglas del equipo, comprueban su propio trabajo y llaman a una persona en el momento adecuado. Hacer autónomo ese bucle no es lo difícil. Lo difícil es que sea digno de confianza.