update · TowCue Editorial Team
VS Code Agent Merge can now carry pull requests through review, CI, and conflicts
VS Code 1.136 puts Agent Merge in public preview, letting an agent address review feedback, failed checks, and merge conflicts until a pull request is ready to merge. Here is where it helps and where human controls still matter.
Quick answer
Microsoft released Visual Studio Code 1.136 on September 2, 2026, and one of its most workflow-relevant AI changes is Agent Merge, now in public preview.
Agent Merge is designed to keep a pull request moving after the first coding pass. Instead of stopping when code is written, the agent can work through review feedback, failed checks, and merge conflicts, rerun workflows, and continue until the pull request is ready to merge.
GitHub highlighted the feature again in its September 4 Copilot weekly release roundup, alongside broader agent-session improvements in VS Code. The important TowCue angle is not “AI can merge code.” It is that the automation boundary is moving from code generation into the much messier PR completion loop.
That can remove repetitive engineering work, but it also raises a control question: which failures should an agent fix automatically, and which ones still require a human decision?
For related guidance, see TowCue's AI agent best-practices guide, guide to choosing an AI tool for work, and GitHub Copilot model deprecation checklist.
What Agent Merge actually does
VS Code describes Agent Merge as a loop that helps take a pull request "across the finish line."
When enabled for an agent session, it can:
- address pull request review feedback
- fix failed checks
- resolve merge conflicts
- rerun workflows
- repeat the cycle until the pull request is ready to merge
The feature is currently preview, and VS Code exposes it behind the chat.agentMerge.enabled setting. It can be enabled for a session from the Agents window.
That scope matters. Agent Merge is not just autocomplete, inline editing, or a one-shot coding agent. It operates after a change has already entered the review-and-CI system.
Why this matters more than another coding benchmark
Most AI coding demos focus on the first half of software delivery: write a feature, fix a bug, or generate a patch.
In real teams, a large amount of engineering time comes after that first patch:
- a reviewer requests a change
- a test fails
- a lint rule blocks the build
- the branch drifts from main
- a merge conflict appears
- CI is rerun
- another review round starts
This is where small interruptions accumulate.
Agent Merge tries to automate that repeated loop. If it works reliably, its value is less about generating more code and more about reducing the number of human handoffs required to get an already-approved direction into a mergeable state.
That is a different productivity metric.
Where it is likely to help first
Repetitive review feedback
Agent Merge is a good fit when review comments are concrete and bounded:
- rename a confusing variable
- add a missing test
- update error handling
- make a type narrower
- fix formatting or lint issues
- adjust documentation to match the implementation
These are tasks where the intent is already clear and the main cost is execution.
Failed CI with understandable causes
An agent can also be useful when checks fail for reasons that are visible in logs and can be reproduced locally or in the workspace.
Examples include test regressions, formatting failures, type errors, and dependency-related issues with clear diagnostics.
Merge conflicts with obvious intent
Some conflicts are mechanical. If one branch renamed a helper and another changed its call site, the correct resolution may be easy to infer and verify.
But this category needs stronger review than lint fixes because a syntactically valid conflict resolution can still be semantically wrong.
Where human approval should remain strong
Agent Merge should not be treated as a reason to remove release judgment.
TowCue would keep explicit human review for at least these cases:
- security-sensitive changes
- authentication and authorization logic
- payment or billing code
- database migrations with destructive effects
- infrastructure or production configuration
- large dependency upgrades
- ambiguous product requirements
- tests that fail because expected behavior itself is unclear
- conflicts where two branches represent competing business logic
The key distinction is simple:
Agents are strongest when the desired outcome is already defined. Humans remain essential when the desired outcome itself is the question.
The hidden risk: optimizing for green checks instead of correct software
A PR can become "merge-ready" without becoming correct.
If an agent is told to make CI green, it may have several possible routes:
- fix the implementation
- update the test
- weaken the test
- change configuration
- suppress a warning
- remove a failing path
Only some of those preserve the original intent.
This is why the most important Agent Merge control is not the feature toggle. It is the quality of the acceptance criteria around the task.
Before allowing a long autonomous repair loop, teams should define:
- what behavior must not change
- which files or systems are off-limits
- whether tests may be edited
- whether dependencies may be changed
- what evidence the agent must return
- which actions require human confirmation
That is the same boundary-setting principle TowCue recommends in the AI agent best-practices guide.
A low-risk way to test Agent Merge
Do not start with a critical production pull request.
Use a small set of representative, reversible PRs and measure the complete loop.
Step 1: choose bounded PRs
Pick changes with clear tests and low business risk. Maintenance work, small bug fixes, and internal tooling are better first candidates than billing or authentication.
Step 2: preserve the human merge gate
Let Agent Merge address feedback and CI, but keep final merge approval manual during the trial.
Step 3: track intervention rate
For each PR, record:
- how many review comments the agent resolved correctly
- how many CI failures it fixed
- how many times a human had to redirect it
- whether it edited tests or requirements unexpectedly
- whether the final diff became larger than necessary
Step 4: compare against the old workflow
Measure elapsed time and human attention, not just token use.
If the agent consumes more compute but removes four context switches and two manual CI repair cycles, it may still be economically useful.
Step 5: expand only by task class
Do not turn the feature on broadly because five easy PRs succeeded. Expand first to PRs with similar failure patterns and similar risk.
Agent Merge is part of a bigger shift in VS Code
VS Code 1.136 also adds several agent-management features around the same idea:
- chat sessions that organize related conversations and show which ones need attention
- agent session notifications when a session finishes or needs input
- multi-root workspace support in experimental form, so agent sessions can work across folders
- an Agent Host architecture for persistent agent sessions across VS Code windows
Taken together, the direction is clear: the editor is becoming a control surface for multiple long-running agent sessions, not just a place where one assistant answers one prompt.
Agent Merge is important because it connects those sessions to the part of development that determines whether work actually ships.
Who should test it now
Agent Merge is most relevant for:
- teams with high pull-request volume
- developers who already use coding agents for implementation
- repositories with reliable automated tests and CI
- teams where review feedback is often concrete and repetitive
- maintainers who spend significant time shepherding small PRs through checks
It is less compelling for repositories with weak test coverage, unclear ownership, or highly subjective review criteria. Automation works best when the surrounding engineering system gives the agent strong signals.
TowCue take
Agent Merge is a more meaningful developer-workflow update than another model entering a picker.
The bottleneck in AI-assisted development is increasingly not "can the model write code?" It is can the system move work through review, validation, repair, and merge without creating more supervision overhead than it removes?
VS Code and GitHub are clearly trying to automate that second half.
TowCue would not enable full autonomy first. We would use Agent Merge as a PR repair assistant before treating it as a release agent:
- let it resolve bounded feedback
- let it repair reproducible CI failures
- require evidence for every change
- keep final approval human
- expand autonomy only after measuring intervention and regression rates
If that process works, the productivity gain is not "more lines of AI-generated code." It is fewer stalled pull requests and fewer interruptions between implementation and merge.
Research sources
- Visual Studio Code 1.136 release notes (released September 2, 2026)
- GitHub Copilot weekly releases — August 31 (published September 4, 2026)
- GitHub Copilot app technical preview (background on Agent Merge and PR workflow)