VS Code 1.136 ajoute Agent Merge pour finir les pull requests

Visual Studio Code 1.136 ajoute une fonction en préversion nommée Agent Merge. Elle confie une pull request ouverte à un agent d'IA. Celui-ci répond aux commentaires de revue, corrige les vérifications en échec et résout les conflits de fusion jusqu'à ce que la demande soit prête. Microsoft date ses notes de version du 2 septembre 2026.

Une pull request est une modification de code proposée, en attente de revue. La faire fusionner suppose souvent une boucle lente de commentaires, de correctifs et de tests relancés. Agent Merge vise cette boucle, pas l'écriture du code elle-même.

Ce que fait réellement Agent Merge

Les notes de version de Microsoft décrivent la fonction en une phrase. "Agent Merge helps you take a pull request across the finish line", y lit-on. "It asks an agent to address review feedback, fix failed checks and merge conflicts, and rerun workflows."

Quatre tâches distinctes tiennent dans cette phrase.

Tâche	Ce que fait l'agent
Retours de revue	Lit les commentaires des relecteurs et modifie le code
Vérifications en échec	Diagnostique un test ou un lint qui échoue, puis le corrige
Conflits de fusion	Résout les conflits face à la branche cible
Workflows	Relance les vérifications, puis répète le cycle

L'agent ne fusionne rien de lui-même. L'approbation reste à une personne. Les notes de version ne disent pas quels hébergeurs Git sont pris en charge.

Comment l'activer

Agent Merge est désactivé par défaut. Microsoft la garde derrière un réglage nommé chat.agentMerge.enabled.

Activer ce réglage ne déclenche rien non plus. Vous activez encore la fonction session par session. Il y a trois entrées : le bouton Agent Merge, la commande "Enable Agent Merge for Active Session", ou la fenêtre Agents.

Ce découpage par session mérite d'être noté. Ce n'est pas un service d'arrière-plan qui surveille votre dépôt et pousse des commits.

Les autres changements sur les agents dans 1.136

Agent Merge arrive avec plusieurs changements plus discrets sur les sessions.

• Prise en charge des espaces de travail multi-racines, marquée expérimentale, pour les sessions Copilot et Claude
• Une résolution d'espace de travail qui laisse un agent identifier un projet par son nom
• Une hiérarchie de sessions qui montre les discussions liées comme enfants d'une session parente
• Des notifications quand une session attend votre approbation
• Un fil d'Ariane lisible pour les fichiers créés par une session
• Un champ de saisie de session redessiné, avec les contrôles rassemblés

La surface de discussion a changé aussi. La version ajoute des arrière-plans de discussion expérimentaux, des contrôles de dictée pour les administrateurs d'entreprise et des améliorations pour les lecteurs d'écran.

Ce que cela signifie pour les développeurs

L'élément intéressant ici n'est pas la génération de code. C'est que l'agent pilote désormais votre intégration continue et votre file de pull requests. Ce sont des systèmes partagés, et le rayon d'action dépasse un tampon d'éditeur.

Surveillez surtout la résolution de conflits. Des quatre tâches, c'est la seule où une mauvaise réponse compile quand même et passe quand même les tests. Un agent peut résoudre un conflit en écartant discrètement la modification d'un collègue, et rien en aval ne s'en plaindra. Lisez ces diffs ligne à ligne, comme un rebase que vous n'avez pas fait vous-même.

Le budget est le deuxième point à vérifier. La boucle relance les workflows jusqu'à ce que les vérifications passent. Un test instable devient donc un agent qui s'acharne contre un test qui échoue au hasard. Si votre intégration continue se facture à la minute, posez un plafond avant d'activer cela. Un exemple chiffré synthétique, publié par le créateur de Telemetry sur le forum de DuckDB, situe le coût par tâche acceptée à 0,75 $ en comptant les échecs et à 0,30 $ sans eux. Nous avons raconté comment GitHub s'est mis à facturer la revue de code Copilot sur Azure Repos, et la même question vaut pour tout ce qui relance des pipelines à votre place.

Vos vrais garde-fous n'ont pas bougé, et ils ne sont pas dans ce fichier de réglages. Les règles de protection de branche, les relecteurs obligatoires et les vérifications obligatoires décident encore de ce qui peut atterrir. Le réglage décide si un agent peut pousser d'autres commits sur la branche. Il ne décide pas de ce que votre dépôt accepte.

Prenez l'étiquette de préversion au sérieux pour l'instant. Activez la fonction sur une branche qui vous appartient, sur une pull request déjà presque au vert, et lisez chaque commit produit. Des travaux sur les agents de programmation montrent qu'ils divergent sur l'outil à choisir bien plus souvent que leur discours commercial ne le laisse croire. Un agent sûr de lui et dans l'erreur sur un conflit de fusion : voilà le mode de défaillance à anticiper.