Orquestación de agentes de IA: del roadmap al pull request
Cómo orquestar agentes de programación con IA: tareas, contexto, implementación, revisión independiente y recuperación, con un ejemplo de desarrollo.
La orquestación de agentes de programación con IA coordina la planificación, las dependencias, la implementación y la revisión alrededor de agentes que modifican código. Define qué debe hacer cada agente, qué contexto recibe y cómo su resultado llega a un ingeniero que pueda evaluarlo.
Un buen flujo conserva el motivo del cambio durante todo el trabajo. Quien implementa necesita saber qué debe ocurrir, quien revisa necesita comprobarlo y el ingeniero que integra el pull request necesita entender qué sigue siendo incierto.
¿Qué necesita coordinación más allá de una sesión de programación?
Un agente puede inspeccionar un repositorio, implementar un cambio y ejecutar comprobaciones durante una sesión. Cuando el trabajo crece, todavía hay que conectar esa sesión con el objetivo de producto, coordinar cambios dependientes y decidir qué ocurre después de una interrupción o un hallazgo de revisión.
| Responsabilidad | Pregunta que debe responder el flujo |
|---|---|
| Alcance | ¿Qué resultado observable de producto entrega este cambio? |
| Contexto | ¿Puede el siguiente agente encontrar el código, las restricciones y las decisiones que necesita? |
| Dependencias | ¿Qué cambios pueden avanzar por separado y cuáles comparten un contrato? |
| Revisión | ¿Quién comprueba el comportamiento completo contra el resultado esperado? |
| Recuperación | ¿Qué trabajo sigue siendo útil si una sesión se interrumpe o falla una comprobación? |
| Entrega | ¿Qué necesita el ingeniero para decidir si integra el cambio? |
Ejecutar varios agentes al mismo tiempo no responde por sí solo estas preguntas. Un cambio pequeño puede necesitar un implementador y una revisión separada. Las sesiones adicionales tienen sentido cuando hay responsabilidades independientes y cada resultado tiene un consumidor claro.
Un ejemplo práctico: exportar la actividad de un proyecto
Imaginemos un equipo que quiere permitir la descarga de la actividad de un proyecto en CSV. Es un ejemplo práctico, no el informe de un despliegue de cliente. Sigue el recorrido de roadmap, iniciativa, backlog, implementación y revisión de la página de Ad Actum.
Empieza por el resultado
La prioridad del roadmap es facilitar que los clientes compartan la actividad de sus proyectos. La primera iniciativa es pequeña: un miembro autorizado puede exportar la actividad que ya tiene permiso de ver, con el mismo filtro de fechas de la pantalla.
Esa definición delimita el trabajo. Los envíos programados, el correo electrónico y los informes de toda la organización pueden esperar. Son otras capacidades, no requisitos para una primera exportación útil.
El resultado debe poder observarse: un miembro selecciona fechas, descarga un archivo y obtiene los mismos registros permitidos que en la pantalla. Una persona sin acceso al proyecto no puede exportarlo.
Dale a cada tarea el contexto que necesita
El backlog puede expresar tres responsabilidades conectadas:
| Responsabilidad | Contexto para el agente | Resultado que revisar |
|---|---|---|
| Producir la exportación | Consulta de actividad, permisos, semántica de fechas y columnas | Un endpoint con las mismas reglas de acceso y filtros |
| Permitir su uso | Pantalla existente, descarga, carga y errores | Una acción de descarga funcional en la pantalla |
| Revisar el cambio | Resultado esperado, código modificado y datos locales | Evidencia de que la interfaz, el endpoint y los datos coinciden |
Referencia archivos y contratos reales después de inspeccionar el repositorio. Un prompt que pide “usar los permisos habituales” está incompleto si el agente que lo recibe no puede encontrar esos permisos.
Coordina la implementación según sus dependencias
Acuerda la solicitud y la respuesta antes de construir el botón. El trabajo puede avanzar por separado cuando el contrato es estable; dos agentes que modifican la misma consulta necesitan coordinación.
La entrega entre agentes debe incluir el comportamiento implementado, las comprobaciones relevantes y las preguntas pendientes. Si el backend cambia el significado del filtro de fechas, el agente de interfaz y quien revisa necesitan saberlo. Una sesión de agente terminada con éxito no demuestra por sí sola que la función esté completa.
En este ejemplo, unos datos locales con dos proyectos y registros en distintas fechas permiten inspeccionar el resultado. No hacen falta datos de clientes para demostrar el flujo.
Revisa la función desde su entrada normal
Sigue la descarga desde el botón hasta la consulta y de vuelta al archivo. Prueba un rango vacío, otro con registros y un usuario sin acceso. Comprueba la respuesta de la interfaz cuando falla la petición. Define un límite de tamaño o una exportación en segundo plano si el volumen esperado lo requiere.
La revisión debe producir correcciones concretas cuando el comportamiento difiera del resultado acordado. También debe señalar los límites de la evidencia: una muestra pequeña no demuestra el rendimiento con un gran volumen de producción.
Separa la implementación de su aprobación. Dale a quien revisa el comportamiento esperado, el código resultante y las comprobaciones disponibles. Pídele que siga la función desde su entrada normal, en vez de tratar el relato del implementador como prueba de que funciona. Un defecto de control de acceso pendiente sigue siendo un defecto aunque la sesión del agente haya terminado con éxito.
Recupera una ejecución interrumpida sin perder el trabajo
Supongamos que el endpoint y sus comprobaciones locales están completos, pero la sesión de interfaz se interrumpe antes de conectar el botón de descarga. Conserva los cambios de código y registra qué resultado se comprobó. La siguiente sesión necesita ese estado, la responsabilidad pendiente de interfaz y cualquier cambio en el contrato de solicitud o respuesta.
Repetir toda la función desde el prompt original puede duplicar trabajo o sobrescribir una corrección válida. Reanudar también requiere cuidado: inspecciona el repositorio actual antes de asumir que el endpoint sigue presente o que sus comprobaciones todavía describen el código.
En este ejemplo, la recuperación termina cuando el siguiente agente puede completar el botón, ejecutar el mismo escenario de exportación y llevar los hallazgos pendientes a revisión. Un registro de que la sesión anterior terminó no basta.
Facilita la evaluación del pull request
Explica qué puede hacer ahora el usuario, qué comportamiento se comprobó y cualquier límite relevante. Incluye lo necesario para repetir el escenario. El equipo de ingeniería conserva la decisión de integrar el cambio.
Esa continuidad es el propósito de la orquestación de agentes: la intención del negocio se conserva al pasar por planificación, implementación y revisión. Ad Actum explora este flujo con equipos de la beta privada; las capacidades y el despliegue se acuerdan para cada piloto.
Para profundizar en un riesgo concreto, lee el ejemplo de revisión de autorización entre clientes.