IDE vNext: a workspace for engineers and their agents

The future of IDEs extends beyond whether familiar editors will survive the spread of agents. Text and graphs, dozens of parallel workers, internal platforms, incompatible tools and the ability to trace a change through to a running system raise a broader question: what exactly are we trying to integrate, and which difficulty are we trying to remove for the engineer?

My starting point is straightforward: first imagine the future work, then work backward to the tools it needs. When much of implementation is delegated, choosing a problem, clarifying constraints, breaking down the task, evaluating evidence and deciding whether to release become central to the working day. A code editor remains useful, but no longer describes everything the person does.

This continues the argument in “When Agents Write the Code: What Remains Engineering”. The amount of generated code is a poor measure of automation. You can delegate almost every line to an agent and still make every important decision yourself. Conversely, you can finish a few functions by hand after losing your understanding of why the solution exists and how it works. The new environment should help people retain the purpose of a task and verify its outcome.

Imagine a team changing the rules for calculating a commission in a .NET service. An agent can implement the change, update the tests and write an explanation. But who established whether the new rule applies to refunds? What happens to existing contracts? Who will notice that the tests merely repeat a mistaken interpretation of the requirement? This is a hypothetical example: typing speed tells us almost nothing about whether the change is ready.

A useful primary object for the environment is a task with an agreed outcome. It has an original problem, constraints, a current version of the requirements, people or agents carrying out the work, changes, independent checks and a person making the decision. Chat, the file tree, a dependency graph and the terminal become different views of that work. Instead of debating which interface will win, we can ask a testable question: which view helps an engineer spot a consequential error sooner?

There is a reasonable objection: for a local edit, a familiar IDE may remain the least expensive way to work. Not every task needs its own control center. I would therefore discuss several modes within one environment: working directly with code, delegating a bounded task and managing a long process. Moving smoothly between them matters more than ceremonially announcing the end of programming.

It is easy to conflate four layers under the term IDE today. The first is the human interface: inspecting changes, navigating, debugging and making decisions. The second is the agent harness, which manages model steps, tools, state and recovery. The third is the execution environment, with its files, processes, network and permissions. The fourth is the organization’s platform: services, releases, observability and access rules. These layers are connected, but do not have to belong to one application.

The terminal is a convenient common way to access tools: commands can be repeated, composed and run without a graphical shell. That is a substantial advantage. But a stream of text alone does not give a person an overall picture of dependencies, pending decisions and the consequences of several simultaneous changes. This does not mean all execution has to move into the editor’s process. The interface and the executing agent can evolve independently.

There are already concrete moves in this direction. In VS Code’s August 26, 2026 article about Agent Host, the session becomes a separate layer with which clients and agent adapters interact. This is an architectural signal, rather than evidence that one product has won. It shows that even an existing IDE can reconsider which component owns task state.

Code semantics are a useful asset of established IDEs

Roslyn is particularly relevant to a DotNext audience. Its compiler and workspace APIs provide access to syntax, symbols, the semantic model and solution structure; these layers do not depend on Visual Studio components. Knowledge of a program can therefore be made available to an agent without requiring it to operate the editor with a mouse.

This access is already appearing in products. Rider’s documentation describes a built-in MCP server available since version 2025.2: an external client can access builds, diagnostics, run configurations and tools for working with symbols. Semantic renaming is among the listed operations. This is a concrete direction for development: the IDE exposes its capabilities as callable operations. But the tool set needs testing against the chosen Rider version and an actual C# solution; a common protocol does not establish complete language support.

My engineering conclusion is that an agent should have an operation such as “find references to this symbol in this particular assembly” when it is more precise than a text search. Static analysis has limits, too: it does not automatically explain a business rule, an external API consumer or the behavior of dynamic code. We should test which classes of tasks become cheaper and less error-prone with semantic tools. A rich API does not guarantee that an agent will choose and use it correctly.

In my analysis of how models, tools and the development process evolve together, I treated them as an interdependent system. This leads to a requirement for IDE vNext: expose the environment’s useful capabilities to agents and people while preserving explicit boundaries. A single universal command with unrestricted authority removes precisely the guarantees the engineering platform was built to provide.

Imagine sixteen agents across four monitors. This is a thought experiment about attention overload: if every worker brings the person a stream of text, increasing parallelism can easily become a faster way to produce unread messages.

I would start by limiting work in progress. Five agents are useful when their tasks are genuinely independent and their results can be checked independently. If all of them change the same contract, shared data schema or area of code, coordination becomes a queue. Separate files and working copies prevent some mechanical conflicts; contradictions between the meanings of their solutions remain.

The author’s model from the article on cheap code: faster implementation can move the queue to verification and release. The actual constraint needs to be measured in your team.

Before adding panels, decide when the environment should draw an engineer away from their current work with a notification asking for a decision. For example, an agent may need a requirement clarified, a conflict between changes resolved, a budget increase approved or permission to act. The request should explain why the agent cannot proceed independently and what the person needs to decide. Routine progress can appear as a compact status with details available on demand.

A useful task card answers a few questions: what outcome was promised, what has changed, what was checked, why execution stopped and what decision is needed. A click should take the engineer to the relevant part of the change, a verification log or the source of a constraint. “The agent is working” offers too little help in making a decision; recounting the entire history is also expensive in terms of attention.

Graphs suit dependencies, timelines suit events, version comparisons suit changes and text suits ambiguous meaning. There is no reason to declare any one format universal. A hierarchy with a coordinating agent can help, too, but adds coordination costs and the risk of losing an important detail in the report passed upward. The person needs access to the original evidence, as well as the coordinator’s confident summary.

How could we test such an interface? Give an engineer several tasks with known conflicts and measure detection time, missed problems and the cost of switching context. Then compare this with their usual way of working. This is a proposed experiment, not an established industry standard. It tests the value of an interface in an area where a polished demonstration almost always looks convincing.

Should we combine the IDE with an internal developer platform, or IDP? The argument for doing so is that an engineer needs the whole cycle in one place: code, release, metrics and rollback. My question concerns the value of that combination: if these capabilities already exist, adding a tab does not by itself improve the workflow.

The substantive requirement is different: use a task to find its change, the change to find the built artifact, the artifact to find a particular deployment and the deployment to find observed behavior. This connects entities and versions. Matching names is insufficient: a service may have been renamed, a version may have reached only some environments, and a metric may describe several components at once.

Task → change → artifact → deployment → observation → decision

In a large organization, the obstacle often lies between systems and teams. The service catalog, cost accounting, on-call arrangements and telemetry may describe the same product in different ways. A general-purpose agent has to guess how they correspond. It can persistently traverse APIs, but persistence does not make an ambiguous mapping reliable. Without shared identity and clear access rules, a new interface merely makes this debt less visible.

I would therefore invest in a few reliable platform capabilities: retrieve a service’s state for a selected period, show the contents of a release, find an owner, perform an authorized action and confirm its result. Each capability needs a defined scope, a compact response, an understandable error and information about where the data came from. An agent can assemble a workflow from these operations while allowing a person to verify each connection.

For example, “what changed in the commission calculation service over the past hour?” should return versions, the environment, the time range and the sources of observations. Suppose errors increase after a new version is released. An agent might convincingly attribute them to a defect in the new code, even though an external service outage is responsible. Automatically restoring the previous version on the strength of that unverified explanation could undo a sound change without resolving the outage. The environment should therefore show the evidence supporting the diagnosis and clearly state when it is only a hypothesis.

This suggests a division of responsibility: the platform provides verifiable facts and authorized operations; the agent chooses a sequence within the task; the engineer defines the requirements and makes consequential decisions. This is a proposed allocation of roles that is worth challenging at the roundtable. It does not require a single window, but does require agreements between system owners.

Consider a team that uses several tools and has to distribute project rules across different files, then check them for divergence. The broader question is what an organization actually controls when it changes agents. Selecting a different model from a list does not necessarily make a workflow portable.

MCP describes how tools connect; the Agent Client Protocol covers communication between an editor and an agent. These are different boundaries. JetBrains describes connecting agents through ACP while retaining its own environment for the engineer. Such projects make it more practical to combine components, but a connection protocol does not standardize engineering judgment.

As of the verification date, ACP’s documentation specifically notes that full support for remote agents is still being developed. Compatibility with a local connection cannot automatically be assumed to extend to every cloud workflow.

Even identical instructions may be read in different orders by different systems, with different context limits and approval rules. An unfinished task contains more than messages: it includes the selected repository version, tool results, background processes, permissions and failed attempts. If these are lost, the next agent may repeat an approach that has already been rejected or treat an old check as current.

My practical position in the article on agent stack configurations is to separate replaceable components from the team’s own agreements. Outcome requirements, access rules and independent acceptance must remain understandable outside any one product. Provider-specific conveniences are worth using when the cost of leaving them is known.

A small portability test would look like this: stop a task after its first verifiable result and hand it to another tool. Can it find the current version, understand the outstanding questions, repeat the check and continue without a retelling of the whole chat? There is no need to transfer the model’s internal state bit for bit. What matters is preserving the engineering commitments and enough evidence for the next step.

Full interchangeability also has a cost. An integrated product may offer a more convenient workflow precisely because it controls every part. At the roundtable, discussing a minimum portable boundary and the conditions for leaving a product would be more useful than demanding identical behavior from every tool. We should also ask providers which data and results remain available to users after they switch products.

Complete traceability—connecting the model, tools, several agents and the running system—requires us to separate two objectives. The first is to understand what actually happened and what evidence is available. The second is to fully explain the internal reasons for the model’s response. Engineering acceptance needs the first; an action log alone does not solve the second.

A minimum chain of evidence connects the requirement version, source code, specific tool calls, resulting change, verification results and release decision. Checks must identify the state to which they apply. A passing test on the previous version does not establish that the current one is correct. Confident prose from an agent is no substitute for verification either.

OpenTelemetry is developing conventions for GenAI telemetry, including model and tool calls. These provide a useful technical layer for correlating events. My requirement for the environment goes further: connect this telemetry to the task, change and acceptance criteria. Store only the necessary data, with access controls; retaining prompt contents indefinitely is not a prerequisite for observability.

Anthropic’s account of harnesses for long-running tasks also points in a useful direction: preserving state between sessions and explicitly checking results help work continue. This is one provider’s experience, not a universal reliability guarantee. In your own system, you still need to establish that the agent does not present partial progress as completion.

What should happen before a change is accepted

Return to the commission example. I want to see the original rule and its ambiguities, the cases affected, the code changes and independent checks of the invariants. If the agent derives both the implementation and tests from the same mistaken premise, passing those tests does not resolve the problem. Independence means using a different source for the expected outcome: agreed examples, previously recorded constraints or a separate specialist review.

The boundary of authority must be enforced outside the text of the request to the model. Reading logs, changing a working copy, publishing a change and performing an operation in a production system are different actions. A dangerous operation requires checking permission for the specific object and state. A sandbox limits some side effects; it does not correct a mistaken requirement or replace access checks for an external service.

My current position is that a person approves the release of consequential changes. Revisiting that boundary is possible for a predefined class of reversible actions with independent release gates and tested recovery. This is a condition for a future expansion of autonomy, rather than permission to remove people from every process. Even rollback needs evidence: reverting code does not necessarily reverse data already written or messages already sent.

A useful question for IDE builders is: show us a task in which the agent made a mistake. How does the engineer detect it, stop further actions and restore state? A demonstration of failure tells us more about the environment’s maturity than another successful run through a prepared example.

An environment that lets us run more agents does not necessarily improve a team’s productivity. We need to account for the outcome and all the human work around it. In my article on the economics of AI in development, I propose measuring accepted work; in the later article on engineering, I refine the distinction between actual expenditure and separately assessed risk.

Cost per accepted task = actual execution, verification and rework costs / number of comparable accepted tasks

The numerator includes unsuccessful attempts. If ten runs produce two usable results, we cannot divide only the cost of the two successful runs by two. Human time is valued at an agreed rate; waiting time is measured separately as process latency. Expected losses from risk should also be reported separately, so that they are not added a second time to incident costs already accounted for.

There is a good reason to distrust impressions alone. In METR’s 2025 randomized study, 16 experienced developers completed 246 tasks in open-source projects they knew well; access to the AI tools studied at the time increased completion time by an average of 19%. This result concerns that particular sample and the tools of early 2025. It does not establish that agents slow down development in general.

METR’s February 24, 2026 update is especially important to read alongside the first study: the authors describe participant and task selection biases that prevent a reliable estimate of the current effect. We cannot turn the earlier slowdown into an eternal law, or the newer observations into a universal promise of acceleration. The practical conclusion is more modest: measure your own process, and distinguish perceived convenience from results.

There is also a positive result. In three field experiments by Cui and colleagues involving 4,867 developers, the pooled estimate showed an increase of roughly 26% in completed tasks. However, these were 2022–2023 experiments with an autocomplete assistant, reported in the paper’s 2025 version, rather than an evaluation of autonomous agents in 2026. The authors include Microsoft employees. Work was evaluated using company metrics, including pull requests. Read alongside METR, this supports a specific question: whom does the tool help, on which tasks and within which process?

I would compare tools on several kinds of real work: a local fix, a change to a contract that spans the system and diagnosis of a production problem. Each kind needs consistent acceptance criteria and comparable difficulty. Tool order should vary, otherwise learning from the first attempt can look like an advantage of the second product. A small pilot can inform a decision for your team, but cannot rank tools for the entire industry.

This is why “how many agents does the IDE support at once?” is too weak a question. A stronger one asks how many verified changes pass through the system, how much human attention that requires and what happens to the cost when something fails. Framed this way, the interface, harness, platform and economics become part of one testable workflow.

I propose discussing questions that admit different engineering answers. Each calls for a concrete example, a demonstration or a measurable criterion, so we can see where participants disagree and how to test their arguments.

The first uncomfortable question for providers: what in your product will remain valuable if the model becomes substantially stronger? Possible answers include code semantics, controlled execution, evidence of results, integration with the organization and support for making decisions. But each answer needs a scenario behind it, rather than a feature count.

The second question is for teams: which of your own inconsistencies do you currently ask the agent to resolve from scratch? If it has to reconcile services, permissions and environments every time, improving one platform capability may be more useful. That does not diminish the agent’s value; it makes that value cheaper and more reliable to obtain.

The third question is for engineers: which action are you prepared to delegate completely, and based on what evidence? “When the model stops making mistakes” is not an operational criterion. A list of permitted actions, independent checks, constraints and recovery methods is enough to start designing an experiment.

Two horizons instead of one picture of the future

In the near term, I would test familiar editors working together with semantic tools, separate agent sessions and platform operations. Further out, I would explore an environment where intent, constraints and evidence of results become the primary objects of interaction, with code available as one level of detail. This is my development scenario, not a forecast with a guaranteed date.

There is a condition that would undermine it: if the cost of independent verification and recovery does not fall, people will have to return to working directly with code more often. Behind “who will build a home for agents?” lies my practical concern: who will help engineers retain understanding and responsibility as execution gets faster? That home may have several interfaces. But it needs clear rules, verifiable results and an exit that people can actually use.