GitLab Automatizó Todo el Ciclo de Merge Request con Developer Flow

En GitLab 19.0, el agente de IA Developer Flow ya no se limita a escribir código: ahora gestiona todo el ciclo de vida del merge request, desde el manejo de los comentarios del revisor y la resolución de conflictos de fusión hasta la fusión final. Este es el siguiente paso tras el lanzamiento de Developer Flow del año pasado, que entonces solo sabía convertir un issue en un MR listo.

Qué cambió en GitLab 19.0

Según el blog de GitLab, hasta ahora la IA solo aceleraba la escritura de código, mientras que todo el trabajo entre la apertura de un merge request y su fusión seguía siendo manual: asignar revisores, ronda tras ronda de gestión de comentarios, desenredar conflictos, hacer rebase antes de la fusión — cada paso requería la atención del desarrollador. El cuello de botella simplemente se desplazó, y las herramientas no se adaptaron a él.

Developer Flow se lanzó el año pasado y resolvía una sola tarea: convertir un issue en un merge request, automatizando el trabajo preparatorio rutinario entre el planteamiento de la tarea y la aparición del MR para revisión. Pero en cuanto se creaba el MR, el trabajo iterativo posterior sobre él seguía siendo completamente manual.

La nueva versión de Developer Flow cierra precisamente esa brecha: el mismo agente de IA ahora gestiona los comentarios de los revisores, resuelve conflictos en ramas de larga duración, se orienta en código desconocido y divide en partes los MR demasiado grandes, junto con la resolución autónoma de conflictos de fusión y la función de rebase-y-fusión en un clic.

Cómo se conecta el agente al trabajo sobre un MR

Developer Flow puede lanzarse en cualquier etapa del trabajo sobre una tarea. Hay tres puntos de entrada: el botón Generate MR directamente en el issue, la asignación de la cuenta de servicio Duo Developer directamente al issue o al MR, o un nuevo disparador mediante una mención con @ en cualquier hilo de discusión del issue o del merge request.

La diferencia clave respecto a la versión anterior es que el agente retoma la conversación y continúa el trabajo sobre el mismo MR, en lugar de crear uno nuevo que luego habría que revisar manualmente desde cero. Combinado con la resolución autónoma de conflictos de fusión y la función de rebase-y-fusión en un clic, esto reduce el volumen de trabajo manual en todo el tramo entre la apertura del MR y su fusión final.

Una nueva categoría de herramientas de IA para el desarrollo

GitLab describe Developer Flow como parte de una nueva categoría, aún en formación, de herramientas de IA para código. La primera ola de estas herramientas aceleraba la escritura de la siguiente línea de código (autocompletado), la segunda dio a los desarrolladores una ventana de chat para hacer preguntas. Lo que surge ahora es algo fundamentalmente distinto: agentes que participan en el trabajo durante todo su desarrollo, y no en un momento puntual y fijo.

Según la formulación de GitLab, los desarrolladores ahora pueden mantenerse «por encima del ciclo» — delegar tareas y verificar el resultado, mientras el agente se ocupa de la ejecución directa: revisiones, conflictos, refactorización de MR demasiado grandes y estudio de partes desconocidas de la base de código.

¿Qué es Developer Flow en GitLab 19.0?

Developer Flow es el agente de IA de GitLab que, en la versión 19.0, amplió su área de responsabilidad desde la creación de un merge request hasta todo su ciclo de vida: la gestión de los comentarios de los revisores, la resolución de conflictos de fusión en ramas de larga duración, el estudio de código desconocido y la división de MR demasiado grandes en partes. Funciona junto con la resolución autónoma de conflictos y el rebase-y-fusión en un clic.

¿En qué se diferencia la nueva versión de

Developer Flow de la del año pasado?

El lanzamiento de Developer Flow del año pasado automatizaba solo una etapa: convertir un issue en un merge request, es decir, la preparación rutinaria entre el planteamiento de la tarea y la aparición del MR para revisión. El trabajo posterior sobre un MR ya creado seguía siendo completamente manual. En GitLab 19.0, el mismo agente sigue trabajando sobre el mismo MR incluso después de su creación: gestiona los comentarios, resuelve conflictos y participa en pulirlo hasta la fusión.

¿Cómo se lanza Developer Flow en un merge request?

Hay tres formas: pulsar el botón Generate MR en el issue, asignar la cuenta de servicio Duo Developer directamente al issue o al merge request, o mencionar al agente mediante un disparador con @ en cualquier hilo de discusión del issue o del MR. En todos los casos, el agente retoma el contexto de la discusión y continúa el trabajo sobre el MR ya existente, en lugar de crear uno nuevo.