IDE vNext: Who Will Build a Home for AI Agents?

Anatoly Kulakov opens with a question about the environment that might replace a collection of agent terminals. Alexander Polomodov starts from the engineer’s job: choose a problem, describe requirements and acceptance criteria, delegate implementation, and notice when the work drifts. A code editor would no longer be the sole center of this environment. He presents a direction, not a finished design. Andrey Berezniker adds the internal-platform perspective: both engineers and agents could benefit from knowing where a method is used, how neighboring systems depend on it, and what load it receives. Such context provides a reason to integrate tools beyond building another editor.

Dmitry Ivanov recalls why IDEs succeeded: common actions became fast, and experienced users could turn thought into action through keyboard shortcuts. He compares that fluency to playing a piano. Agent tools often replace immediate feedback with waiting across several windows. A future environment should recover professional fluency at this new level. Oleg Chirukhin places agents in the history of rising abstraction: another way to translate a description into an executable program. That step does not remove complexity; it changes what people must understand and control.

Andrey challenges the suggestion that writing code has become unimportant. Generated volume still has to be read and checked, and it also consumes model context. People remain accountable for the outcome. Natural language is not always the fastest interface either: a shortcut for finding symbol usages can beat composing a request and waiting for an agent. A useful environment therefore needs multiple interaction methods. Easier delegation does not make verification unnecessary.

Oleg describes a project containing hundreds of Markdown files used as a program description. Building a prototype was easy; changing a few foundational terms led to days of repairs. Conventional IDEs have a program model that supports algorithmic renaming, while a language model performs a probabilistic transformation. Alexander qualifies his position by distinguishing product engineering: a business feature needs clear intent, a verifiable outcome, and successful operation. Accountability remains, but the engineer’s responsibilities may span the entire change, including builds, deployment, and service health. Code details remain available when someone needs to investigate them.

The discussion of tabs becomes a discussion of attention. Oleg describes watching many terminals across several screens: possible, but exhausting. Alexander asks what event actually requires intervention. For a bounded task, someone can return when the result is ready; that approach does not address a system being built continuously over days. Oleg says he watches the project evolve so he can retain an understanding of its major changes. Otherwise, implementation can move far beyond the state he still understands. These are different supervision scenarios, not necessarily one universal chat interface.

Oleg suggests visual representations that convey activity without requiring constant reading. The panel does not settle on a format. Dmitry defends text as a familiar foundation and recalls earlier attempts at visual programming. Oleg disputes treating all those tools as failures, citing continuing use of MPS. The practical direction is cautious: some results suit pictures, some interactions suit selection, and text still has a role. Alexander suggests requesting the representation needed for a particular question, such as service health, rather than continually moving between permanent panels. The discussion leaves the detailed interface open.

Andrey recounts two colleagues independently editing a document with models and then struggling to merge their work. Handing the conflict to another model risks introducing meaning neither author intended. Oleg describes converting Markdown into a structured internal representation and merging separate branches. This is an attempt to make specification changes manageable through structure. A tree, however, cannot by itself decide between incompatible intentions.

Alexander separates textual conflicts from semantic ones. If one person refines a particular requirement while another changes an independent implementation area, explicit change boundaries help preserve mergeability. Requests to make the same system more distributed and more monolithic require a human decision; combining text cannot reconcile them. Dmitry suggests a future IDE could support specification syntax, navigation between entities, and links from requirements to code. These are proposed capabilities, not an agreed universal specification language or an established method for automatically resolving architectural disagreement.

Asked why companies do not combine their efforts into one IDE, Andrey points to infrastructure differences. Large organizations need deep integration with their own systems; editor foundations already exist, while additional value comes from the surrounding workflow. Smaller companies might assemble an environment from existing layers and open tools. Oleg emphasizes the transition period: industrial products should make use of engineers’ existing skills. He also favors context-preparation tools that work with different agents rather than tying the whole workflow to one supplier.

Dmitry expects IDEs and development platforms to converge in purpose, but doubts everyone will adopt one system. Organizations already depend on different code hosts, documents, and integrations, and migration has a cost. Alexander returns to user intent: someone may want an answer about a service incident or business data rather than a tour of logs and dashboards. Platforms should expose capabilities to agents while keeping professional tools available for detailed investigation. His example of teaching executives shows interest in that interaction, alongside unresolved access and security questions. The session ends without a single shared IDE proposal. Integration, useful delegation, and retaining an understanding of the outcome remain the main directions.