GitLab a Automatisé l'Intégralité du Cycle de Merge Request avec Developer Flow
GitLab 19.0 a ajouté Developer Flow — un agent opérant sur l'ensemble du cycle MR. Analyse les commentaires des relecteurs, résout les conflits, explore des bas

L'IA a accéléré l'écriture de code, mais elle n'a pas amélioré le travail autour des merge requests. Les développeurs doivent toujours assigner des relecteurs, traiter les retours sur plusieurs rounds, résoudre les conflits et rebase les branches avant la fusion. Le goulot d'étranglement s'est déplacé du code vers le processus, mais les outils ne se sont pas adaptés. GitLab 19.0 change cela.
Developer Flow Fonctionne sur l'Ensemble du Cycle MR
Auparavant, Developer Flow résolvait une seule tâche : transformer un issue en merge request. Cela automatisait la configuration de routine entre "ce qui doit être fait" et "voici le MR pour examen". Mais c'était une seule tâche, et une fois que le MR était ouvert, tout le reste était manuel — feedback en round-robin, conflits, reconstructions de branches.
Maintenant, le même noyau d'agent IA fonctionne sur tout le cycle de vie d'un MR. Vous pouvez le lancer depuis n'importe quel stade : depuis un issue avec un bouton Generate MR, assigner le compte de service Duo Developer directement à un issue ou MR, ou simplement écrire une @mention dans n'importe quel commentaire. L'agent récupère le contexte de la conversation et travaille sur le même MR au lieu d'en créer un nouveau.
Qu'est-ce que l'agent fait exactement :
- Traite les retours des relecteurs sur plusieurs rounds dans un seul MR
- Résout les conflits de merge sur les branches longue durée
- Explore les bases de code inconnues et recommande des approches
- Divise les MR surdimensionnés en parties logiques
- Implémente de nouvelles fonctionnalités à partir de zéro
Sous le capot, Developer Flow fonctionne comme une boucle d'agent unique avec un ensemble complet d'outils de développeur : lecture de fichiers, grep, édition et exécution de commandes. L'agent décide lui-même quel outil utiliser et quand. C'est la base architecturale qui permet à un seul agent de participer tout au long du cycle MR.
Comment l'Agent Apprend à Connaître Votre Projet
C'est le moment clé qui distingue Developer Flow des autres outils d'IA pour le code. L'agent lit AGENTS.md — un fichier qui décrit les commandes bash non évidentes, les conventions du projet, les spécificités de l'environnement et les décisions architecturales. Avec agent-config.yml, l'agent reçoit un environnement avec les bonnes dépendances, outils et configuration. Il peut exécuter des tests, invoquer des pre-commit hooks et boucler avant de faire un commit. Vous donnez à l'agent une machine qui connaît vos standards, et le résultat répond aux exigences au lieu de créer du travail supplémentaire.
Résolution des Conflits et l'Étape Finale
Un conflit de merge est l'une des tâches les plus pénibles du processus MR. Vous devez garder simultanément l'intention des deux branches à l'esprit, analyser les modifications dans un éditeur de texte sans exécuter les tests. Plus la base de code est grande, plus la probabilité que des bugs apparaissent dans la résolution manuelle est élevée. Pour les équipes travaillant avec des backports et des MRs en cascade sur différentes branches de version, c'est un coût constant sur la vélocité.
GitLab 19.0 ajoute un bouton Resolve with Duo (en beta) : l'agent lit l'intention du MR, examine les deux branches, sélectionne une stratégie de résolution, édite les fichiers et pousse le résultat. Il laisse un commentaire avec un résumé du conflit et le chemin de la solution — le prochain relecteur n'a pas besoin de reconstruire la solution et la piste d'audit reste intacte. Séparément, pour la fin du processus MR, une fonctionnalité one-click rebase and merge a été ajoutée (également en beta). Auparavant, pour les équipes avec un historique semi-linéaire, c'était : rebase, puis merge. Maintenant c'est un clic.
Une Nouvelle Catégorie d'Outils
C'est une partie d'un changement plus large dans le monde des outils de développement IA. La première vague a accéléré l'écriture de code. La deuxième a ajouté une fenêtre de chat. Maintenant, des agents sont créés qui participent au processus de travail plutôt que d'aider à un moment unique. Developer Flow démontre ce modèle : le développeur reste au-dessus du cycle, gérant et examinant, tandis que l'agent effectue le travail.