2026 means stabilizing AI tools, not launching new ones
2026 isn't about new AI capabilities — it's about stabilizing the ones we already have. For product counsel, governance built on shifting tools is governance built on sand.
Three months into 2026 — which is roughly three decades in AI time — and this piece from December is still landing. Worth revisiting.
The core argument held: 2026 was always going to be about stabilizing what already exists, not launching the next thing. Developers convinced about LLM capability still needed convincing that these tools could actually hold up over time. That hasn't changed.
1. Improving visibility and management of Model Context Protocol (MCP)
Since Model Context Protocol (MCP) has quickly become the accepted way agents interact with external tools, there will have to be more effort to keep the MCP servers under control — either with central management or clearer dashboards. While developers have enjoyed the improved workflows that connectivity brings, the management of these has been a bit ad hoc. The success of MCP seems to work across silos, as non-technical staff want their agent requests to talk to Slack, etc. These internal connections kind of answer the "what's going on in my own business?" queries. Which means developers will be busy setting up MCP servers.
If there will be a lot of active MCP servers in an organization, then management of them will start to become more significant. The more things people find to do with MCP, the more concerns will appear.
For product counsel, this is where the governance questions get concrete. Every MCP server connection is a data access decision — which agents can reach which internal tools, what information flows through those connections, and who authorized it. If management has been ad hoc so far, that means permission structures have been ad hoc too. Legal teams should be asking right now: do we have visibility into what MCP connections exist across the organization, and do our data access controls actually cover agent-to-tool interactions?
2. Supporting parallel task execution for senior engineers
This year saw apps like Conductor and Verdant AI explicitly support running tasks in parallel — effectively defining a task and leaving an LLM to execute it in the background while starting a new one. While you can generally ask any agentic CLI to run a task in the background, more apps will support parallel running as a workflow in 2026.
One thing to note about executing these: to work on the same codebase, the target code needs to be isolated. This usually means making a new branch for each task and then putting the code into a fresh folder, which is what git worktrees does. You then merge the work back into the main branch. All this git fiddling plays slightly against the "vibe coding" moniker — but LLM tools will always gravitate towards being most useful to senior developers.
It is also only devs with solid experience who can quickly evaluate whether a change is safe enough to entrust to an agent… or not. And it is the senior developers who are already used to interruptions throughout the day, in this case coming from agents completing tasks at different times.
In practice, this means the human-in-the-loop question isn't binary. It's a judgment call that requires deep domain knowledge — exactly the kind of contextual expertise that governance frameworks tend to assume exists but rarely specify how to verify.
3. Clarifying the roles of agentic CLI vs. desktop applications
When we first saw Claude Code running in a terminal session, it immediately got developers to define tasks in English instructions. Hence the term Agentic Command Line Interface (CLI). This was in sharp relief to using an IDE like VS Code.
Built in TypeScript and React, Claude Code ran in any terminal shell, allowing it to share an immediate environment and start in the same directory as the project to be worked on. This felt comfortable for many developers. There have been quite a few similar CLI apps released since then. The ability to also pass shell commands on the same prompt (implemented most cleanly in Warp) helped to reduce the friction of app swapping.
But many desktop versions were also released, such as Claude Desktop, which offered the advantages of UI honed on macOS or Windows. For example, you get nice file and folder views, along with more control over the request and response UI components. From an enterprise point of view, managing a desktop app is a bit easier too. However, exactly how the desktop app compares to the CLI version can still be unclear.
In 2026, I expect all major providers to make it clearer how they will support both their CLI and desktop versions of LLM products. Each version may have different communities, but they shouldn't be treated as separate entities. For product teams, that translates to clearer procurement decisions — and for legal teams, clearer contract scoping on what exactly is being licensed.
4. Integrating paid services and agent-driven commerce
How agents successfully request paid services — agent-driven commerce — has to surface at some stage. There isn't a screaming demand for this, but eventually an agent will need to call upon a paid service in the background — or use a more expensive model in a task that the caller doesn't have an explicit payment plan for. Most of us are simultaneously suspicious and accepting of the "machine-to-machine economy." There is no point in autonomy that has to stop at the till. There may be various attempts to start addressing this over the year, especially for products that can use multiple models. This is particularly true for developers running local LLMs who only want to call cloud LLMs for the deeper tasks.
This is where product counsel needs to pay close attention. Agent-driven commerce raises questions about authorization, spending limits, contract formation, and liability when an autonomous system commits to a paid service without explicit human approval for that specific transaction. The contractual frameworks for this don't exist yet in any mature form.
5. Addressing the challenges of VS Code forks in AI development
The Microsoft Visual Studio Code forking problem has to be addressed a little more closely. We have seen quite a few non-Microsoft apps that are actually forks of VS Code under the covers — Cursor was an early example. While using the extension model within VS Code isn't really good enough to support LLMs, forks have limitations too. The problem with finding other extensions in a less secure independent marketplace will probably remain an issue. In some respects Microsoft has successfully captured the market, leaving the competition to join or fragment. Google launching its own VS Code fork, Antigravity, brought the whole issue to a head again.
Too many product teams have seen a VS Code fork as a quick win, without ever really asking themselves if they have serious plans to buy their own home — or whether they will rent forever. Then they forget that their rental contract prevents them from hammering nails into the wall. But there are likely to be new approaches to get around this in 2026.
For product counsel, the forking problem is a licensing and supply chain risk question. Organizations building on forks need to understand their dependency exposure — what happens when Microsoft changes the upstream terms, or when the fork falls behind on security patches that the marketplace no longer delivers reliably.
So what?
This has been the breakout year for agentic AI tools, especially the agentic CLI, and I would expect 2026 will be about securing that ground. Developers don't need to be convinced about what LLMs can achieve, but they do need to be convinced that the available products can be trusted to support their workflows over time.
That trust question is the connective thread across all five of these trends. MCP management, parallel execution oversight, CLI-versus-desktop clarity, agent commerce, VS Code forking — each one is a stability problem masquerading as a feature problem. For product counsel and legal leaders, the message is clear: governance frameworks built on shifting tooling are governance frameworks built on sand. The organizations that get 2026 right will be the ones that resist the growth-stock impulse and invest in making what already exists actually reliable.
David Eastman
