VS Code 1.136 bringt Agent Merge für Pull Requests

Visual Studio Code 1.136 bringt eine Vorschaufunktion namens Agent Merge. Sie übergibt einen offenen Pull Request an einen KI-Agenten. Der beantwortet Review-Kommentare, repariert fehlgeschlagene Prüfungen und löst Merge-Konflikte, bis der Request bereit ist. Microsoft datiert die Release Notes auf den 2. September 2026.

Ein Pull Request ist eine vorgeschlagene Codeänderung, die auf Review wartet. Bis zum Merge folgt oft eine zähe Schleife aus Kommentaren, Korrekturen und erneuten Tests. Agent Merge zielt auf diese Schleife, nicht auf das Schreiben des Codes.

Was Agent Merge tatsächlich tut

Microsofts Release Notes beschreiben die Funktion in einem Satz. "Agent Merge helps you take a pull request across the finish line", heißt es dort. "It asks an agent to address review feedback, fix failed checks and merge conflicts, and rerun workflows."

In diesem Satz stecken vier getrennte Aufgaben.

Aufgabe	Was der Agent tut
Review-Feedback	Liest Kommentare der Reviewer und ändert den Code
Fehlgeschlagene Prüfungen	Diagnostiziert einen fehlschlagenden Test oder Lint-Lauf und behebt ihn
Merge-Konflikte	Löst Konflikte gegen den Zielbranch auf
Workflows	Startet die Prüfungen neu und wiederholt den Zyklus

Der Agent merged nichts von selbst. Die Freigabe bleibt bei einem Menschen. Die Release Notes sagen nicht, welche Git-Hosting-Anbieter unterstützt werden.

Wie man sie einschaltet

Agent Merge ist standardmäßig aus. Microsoft sichert sie hinter einer Einstellung namens chat.agentMerge.enabled.

Diese Einstellung einzuschalten startet ebenfalls noch nichts. Man aktiviert die Funktion weiterhin pro Sitzung. Es gibt drei Wege hinein: die Schaltfläche Agent Merge, den Befehl "Enable Agent Merge for Active Session" oder das Agents-Fenster.

Dieser Zuschnitt pro Sitzung ist bemerkenswert. Das ist kein Hintergrunddienst, der Ihr Repository beobachtet und Commits schiebt.

Die übrigen Agenten-Änderungen in 1.136

Agent Merge kommt zusammen mit mehreren kleineren Änderungen an Sitzungen.

• Unterstützung für Multi-Root-Workspaces, als experimentell markiert, für Copilot- und Claude-Sitzungen
• Workspace-Auflösung, mit der ein Agent ein Projekt am Namen erkennt
• Eine Sitzungshierarchie, die verwandte Chats als Kinder einer übergeordneten Sitzung zeigt
• Benachrichtigungen, wenn eine Sitzung auf Ihre Freigabe wartet
• Lesbare Brotkrumen für Dateien, die eine Sitzung erzeugt hat
• Ein neu gestaltetes Sitzungs-Eingabefeld mit gebündelten Bedienelementen

Auch die Chat-Oberfläche änderte sich. Neu sind experimentelle Chat-Hintergründe, Diktier-Steuerung für Unternehmensadministratoren und Verbesserungen für Screenreader.

Was das für Entwickler bedeutet

Das Interessante hier ist nicht die Codeerzeugung. Es ist, dass der Agent jetzt Ihre Continuous Integration und Ihre Pull-Request-Warteschlange bedient. Das sind gemeinsam genutzte Systeme, und der Wirkungsradius ist größer als ein Editorpuffer.

Achten Sie besonders auf die Konfliktauflösung. Von den vier Aufgaben ist sie die eine, bei der eine falsche Antwort trotzdem kompiliert und trotzdem die Tests besteht. Ein Agent kann einen Konflikt lösen, indem er still die Änderung eines anderen verwirft, und nichts weiter unten beschwert sich. Lesen Sie diese Diffs Zeile für Zeile, wie ein Rebase, das Sie nicht selbst gemacht haben.

Das Budget ist die zweite Prüfung. Die Schleife startet Workflows neu, bis die Prüfungen grün sind. Ein instabiler Test wird damit zu einem Agenten, der gegen einen zufällig fehlschlagenden Test antritt. Rechnet Ihre CI nach Minuten ab, setzen Sie vorher eine Obergrenze. Ein synthetisches Rechenbeispiel des Telemetry-Gründers auf DuckDBs Diskussionsforum beziffert die Kosten pro akzeptierter Aufgabe auf 0,75 $ mit gescheiterten Versuchen und 0,30 $ ohne. Wir haben berichtet, wie GitHub Copilot Code Review auf Azure Repos abzurechnen begann, und dieselbe Frage gilt für alles, was in Ihrem Namen Pipelines neu startet.

Ihre eigentlichen Kontrollen bleiben unverändert, und sie stehen nicht in dieser Einstellungsdatei. Branch-Protection-Regeln, Pflicht-Reviewer und Pflicht-Status-Checks entscheiden weiterhin, was landen darf. Die Einstellung regelt, ob ein Agent weitere Commits auf den Branch schieben darf. Sie regelt nicht, was Ihr Repository annimmt.

Nehmen Sie das Vorschau-Etikett vorerst ernst. Schalten Sie die Funktion auf einem eigenen Branch ein, bei einem Pull Request, der ohnehin fast grün ist, und lesen Sie jeden erzeugten Commit. Untersuchungen zu Coding-Agenten zeigten, dass sie sich über die Wahl des Werkzeugs uneinig sind, weit häufiger als ihr Marketing nahelegt. Ein Agent, der sich bei einem Merge-Konflikt sicher und zugleich irrt, ist der Fehlerfall, für den Sie planen sollten.