Agent-Orchestrated Development: el próximo modelo del desarrollo de software

Durante los últimos dos años aparecieron cientos de artículos sobre cómo la Inteligencia Artificial está cambiando el desarrollo de software. La mayoría gira alrededor de una idea conocida: el desarrollador usa una herramienta de IA para escribir código más rápido, generar documentación o acelerar tareas repetitivas. Es una realidad que ya forma parte del día a día de muchos equipos.

Pero después de varios meses incorporando herramientas de IA en proyectos reales, en Suris creemos que está empezando a suceder algo más interesante. La conversación dejó de centrarse solo en asistentes inteligentes y empezó a girar alrededor de cómo coordinamos varias capacidades trabajando al mismo tiempo.

Esto es una reflexión de primera mano sobre lo que estamos observando en proyectos reales, y sobre las preguntas que todavía no sabemos responder. No esperes una guía de implementación ni un framework cerrado: el campo es demasiado nuevo para eso. Y no somos los únicos que lo vemos. Un análisis reciente de Forrester sobre el desarrollo de software agéntico en 2026 describe esta misma transición y la señala como el punto de inflexión del año.

El modelo que ya conocemos: desarrollo asistido por IA

La primera etapa de adopción fue simple. Un desarrollador incorporó herramientas de IA a su flujo de trabajo habitual. La dinámica seguía siendo la conocida. Lo que empieza a aparecer ahora es una segunda etapa, donde la unidad de trabajo deja de ser una persona con una herramienta y pasa a ser una persona coordinando varias.

Etapa 1 · Ya conocida — Desarrollo asistido por IA

• Una persona, una tarea, una interacción

• La IA como asistente del desarrollador

• Generación de código y documentación

• Testing y análisis técnico acelerados

• El profesional sigue siendo el centro del proceso

Etapa 2 · Emergente — Agent-Orchestrated Development

• Una persona coordina múltiples agentes

• Procesos paralelos, no secuenciales

• Varios flujos de trabajo simultáneos

• La coordinación determina la calidad

• La responsabilidad sigue siendo humana

Para muchos equipos, la primera etapa todavía es una enorme oportunidad de mejora. No hay que apurarse a saltar a la siguiente si la base no está consolidada. Pero vale entender hacia dónde se mueve el campo para tomar mejores decisiones hoy.

Lo que estamos empezando a observar

En algunos proyectos ya no vemos únicamente a un desarrollador interactuando con una herramienta. Vemos varios procesos ocurriendo en paralelo. La persona toma una decisión de arquitectura mientras distintas capacidades trabajan en simultáneo: una investiga alternativas, otra genera pruebas, otra revisa código, otra documenta cambios, otra recopila información.

El trabajo deja de ser completamente secuencial y empieza a parecerse a una orquestación. La pregunta central cambia.

Ya no es “¿cómo me ayuda esta herramienta?”. Pasa a ser “¿cómo coordino varias capacidades para resolver mejor este problema?”. Ese desplazamiento de pregunta es, en sí mismo, una señal de que algo estructural está cambiando.

— Ezequiel Sansón, Chief AI Officer · Suris Code

Agent-Orchestrated Development: qué significa

Todavía no existe una definición universal para este concepto, y eso en parte es lo que lo hace interesante de explorar. En términos simples, es un modelo donde una persona coordina capacidades especializadas que colaboran en distintas etapas del ciclo de desarrollo.

Forrester describe este momento como el paso de los TuringBots (asistentes de IA integrados en herramientas individuales) a agentes que colaboran en todo el ciclo de vida del desarrollo. En lugar de pedirle a una herramienta que genere código, los equipos delegan una intención (“construí esta funcionalidad”) mientras los agentes descomponen el trabajo, generan artefactos, corren tests y preparan releases. Las personas siguen siendo responsables. Lo que cambia es cuánto de la ejecución puede distribuirse.

Tres cosas no cambian en este modelo, y conviene decirlo con claridad:

• La responsabilidad sigue siendo humana. Quién responde por el resultado es la persona, no el proceso automatizado.

• Las decisiones siguen siendo humanas. La arquitectura, el criterio técnico, el juicio sobre qué construir y qué no: todo eso requiere experiencia y contexto que ningún agente tiene.

• La comprensión del negocio sigue siendo humana. Un agente puede generar código correcto para un requerimiento mal entendido. La persona es quien sabe si el requerimiento está bien planteado.

Lo que cambia es la escala del trabajo que puede ejecutarse en simultáneo. Durante años valoramos a profesionales capaces de participar en varios proyectos a la vez. Hoy empieza a emerger otra capacidad igual de valiosa: gestionar múltiples flujos de trabajo paralelos dentro de un mismo proyecto.

La nueva unidad de medida: de “líneas de código por hora” a “flujos de trabajo coordinados por persona”

La productividad en un entorno de orquestación no se mide igual que en uno de asistencia. Quien gestiona bien cinco procesos paralelos puede producir en una jornada lo que antes llevaba mucho más. La métrica de “código por hora” ya no captura eso, y esa brecha entre lo que medimos y lo que genera valor es uno de los problemas más urgentes que tenemos para resolver.

Lo que cambia para los equipos y el talento

Cuando aparecen varios procesos trabajando en simultáneo, las habilidades más valiosas empiezan a desplazarse. Algunas capacidades técnicas siguen siendo importantes; otras ganan protagonismo rápido.

Pierden protagonismo relativo: velocidad de escritura de código, memorización de APIs y sintaxis, generación de boilerplate, búsqueda y síntesis de documentación, testing manual repetitivo.

Ganan protagonismo: formular mejores preguntas y prompts, validar resultados y detectar inconsistencias, decidir con información abundante, priorizar y mantener contexto, gestionar complejidad y coordinar flujos, comunicar decisiones técnicas con claridad.

Este desplazamiento tiene implicancias directas en cómo formamos profesionales y cómo evaluamos talento. La diferencia entre dos desarrolladores con acceso a las mismas herramientas rara vez está en la herramienta. Está en cómo la usan: en la calidad de las preguntas que hacen, en qué tan rápido detectan que un output está mal y en si pueden sostener coherencia en un proceso distribuido.

Lo que esto cambia en cómo contratamos en Suris

En la selección de talento técnico usamos análisis asistido por IA para el screening inicial. Pero lo que más nos interesa evaluar en las entrevistas ya no es solo el conocimiento técnico acumulado. Nos importan la curiosidad, la capacidad de aprendizaje, la adaptación al cambio y, cada vez más, la habilidad de gestionar contexto y coordinar varias tareas con criterio.

El conocimiento técnico importa, igual que siempre. Lo que pasa es que cuando las herramientas amplifican la ejecución, lo que diferencia a los mejores profesionales es justo lo que la herramienta no puede hacer por ellos.

El proceso de adaptación: dónde están los nuevos focos

Nada de esto pasa de un día para el otro. Lo más interesante de estos meses fue darnos cuenta de que el foco del trabajo se corrió de lugar, más que la velocidad que ganamos. Coordinar varios agentes a la vez se parece a conducir un equipo, y eso pide poner la atención en cosas distintas de las que pedía programar solo.

Tres focos nuevos que fuimos descubriendo en proyectos reales.

De escribir a coordinar. Un buen desarrollador escribiendo código no es automáticamente bueno coordinando cinco procesos en paralelo. Es otra habilidad: repartir trabajo, sostener el contexto de cada flujo, decidir qué mirar primero. Es una curva, y vale nombrarla en lugar de asumir que se aprende sola.

La review pasó a ser el centro de atención. Cuando varios agentes terminan casi al mismo tiempo, la calidad del resultado se juega en la review. La generación se volvió rápida; revisar bien sigue pidiendo criterio humano, y ahí aprendimos que hay que poner el tiempo y la cabeza. Si uno deja la atención puesta en producir y descuida la revisión, el resultado lo siente.

Sostener la coherencia del conjunto. Con el trabajo repartido en varios flujos, cada parte puede estar bien y el todo no cerrar. Mantener la mirada del conjunto, mientras se construye en paralelo, es un foco que el trabajo secuencial antes resolvía casi solo.

Qué fuimos ajustando

Ninguno de estos focos tiene una fórmula cerrada todavía. Lo que tenemos son ajustes que fuimos haciendo a medida que entendíamos mejor dónde mirar:

• Cuántos flujos orquesta una persona a la vez lo medimos por lo que esa persona puede revisar bien.

• La review entró en la planificación, con tiempo propio. Dejó de ser el paso que se hace apurado al final.

• Escalonamos la salida de los agentes para que no caiga todo junto, y sumamos una primera revisión entre agentes antes de que mire un humano.

• Tratamos la orquestación como una habilidad que se entrena, igual que en su momento entrenamos prompt engineering.

• Cuando la base no está sólida, seguimos con lo secuencial. No todo proyecto gana con orquestación, y forzarla antes de tiempo agrega ruido.

Lo contamos porque esta parte, la del aprendizaje, es la que casi nadie publica. Y porque la forma de avanzar en algo nuevo es ir descubriendo dónde poner el foco mientras lo recorrés.

Las preguntas que todavía no tienen respuesta

Estamos en una etapa muy temprana. Sería deshonesto presentar esto como un framework cerrado cuando la mayoría de las preguntas relevantes siguen abiertas. Algunas las estamos abordando con los ajustes que contamos arriba. Otras todavía no sabemos responderlas, y son las que más nos ocupan:

• ¿Cómo se mide la productividad cuando parte del trabajo lo ejecutan procesos automatizados en paralelo?

• ¿Qué métricas tradicionales dejan de tener sentido y con qué las reemplazamos?

• ¿Cómo cambia el rol del desarrollador senior cuando la ejecución se distribuye?

• ¿Qué habilidades deberían desarrollar los profesionales que recién empiezan su carrera en este contexto?

• ¿Cómo gobernamos un entorno donde la superficie de decisiones automatizadas crece todo el tiempo?

Ninguna tiene respuesta definitiva todavía, y desconfío de quien diga que sí la tiene. Lo que tenemos son hipótesis que estamos poniendo a prueba en proyectos reales. Cuando tengamos datos más sólidos, los compartimos.

Nuestra visión

En Suris pensamos la IA como una herramienta más en una línea histórica conocida: el compilador, el framework, la nube, y ahora agentes que ejecutan en paralelo. Cada una amplió lo que una persona podía hacer. Ninguna reemplazó el criterio de quien la usa.

Lo que cambia ahora es la escala. Por primera vez trabajamos en entornos donde varias capacidades pueden actuar en paralelo sobre un mismo problema. El desarrollador no pierde importancia; cambia el tipo de trabajo que hace.

Entender cómo diseñar, coordinar y gobernar esos entornos va a ser uno de los desafíos más interesantes de los próximos años. No tenemos todas las respuestas. Pero sí la convicción de que vale la pena hacer las preguntas correctas ahora, mientras el campo todavía se está definiendo.

Esta conversación recién empieza. Y las empresas que participen en ella, en lugar de esperar a que otros la resuelvan, van a estar mejor paradas para lo que viene.