IDE vNext: среда для инженера и его агентов

Будущее IDE не сводится к вопросу, переживёт ли привычный редактор распространение агентов. Текст и графы, десятки параллельных исполнителей, внутренние платформы, несовместимость инструментов и возможность проследить изменение до работающей системы ставят перед нами более широкий выбор: что именно мы собираемся интегрировать и какую трудность убрать у инженера.

Моя отправная точка проста: сначала представить будущую работу, затем двигаться назад к необходимым инструментам. Если значительная часть реализации делегируется, в центре рабочего дня оказываются выбор проблемы, уточнение ограничений, разбиение задачи, проверка доказательств и решение о выпуске. Редактор кода остаётся полезным, но перестаёт описывать всю деятельность человека.

Эта позиция продолжает статью «Когда код пишет агент: что остаётся инженерией». Количество сгенерированного кода — слабая мера автоматизации. Можно поручить агенту почти все строки и всё равно самостоятельно принять каждое важное решение. И наоборот: вручную дописать несколько функций, уже потеряв понимание того, зачем и как устроено решение. Новая среда должна помогать удерживать смысл задачи и проверять результат.

Представим команду, которая меняет правила расчёта комиссии в .NET-сервисе. Агент способен подготовить реализацию, обновить тесты и написать пояснение. Но кто выяснил, распространяется ли новое правило на возвраты? Что произойдёт со старыми договорами? Кто заметит, что тесты лишь повторяют ошибочную трактовку требования? Это мысленный пример: скорость печати здесь почти ничего не говорит о готовности изменения.

Полезный главный объект среды — задача с договорённостью о результате. У неё есть исходная проблема, ограничения, актуальная версия требований, исполнители, изменения, независимые проверки и человек, принимающий решение. Чат, дерево файлов, граф зависимостей и терминал становятся разными представлениями этой работы. Тогда спор о том, какой интерфейс победит, можно заменить проверяемым вопросом: через какое представление инженер быстрее замечает существенную ошибку?

Есть и возражение: для локальной правки знакомая IDE может оставаться самым дешёвым способом работы. Не каждой задаче нужен отдельный центр управления. Поэтому я бы обсуждал несколько режимов одной среды: непосредственную работу с кодом, делегирование ограниченной задачи и управление долгим процессом. Хороший переход между ними важнее торжественного объявления конца программирования.

В слове IDE сегодня легко смешать четыре слоя. Первый — интерфейс человека: просмотр изменений, навигация, отладка и решения. Второй — агентная обвязка, которая управляет шагами модели, инструментами, состоянием и восстановлением. Третий — среда исполнения с файлами, процессами, сетью и правами. Четвёртый — платформа организации: сервисы, выпуск, наблюдаемость и правила доступа. Они связаны, но не обязаны принадлежать одному приложению.

Терминал удобен как общий доступ к инструментам: команды можно повторять, компоновать и запускать без графической оболочки. Это весомое преимущество. Но поток текста сам по себе не даёт человеку общей картины зависимостей, очереди решений и последствий нескольких одновременных изменений. Из этого не следует, что всё исполнение нужно переселить в процесс редактора. Интерфейс и исполняющий агент могут развиваться независимо.

Уже есть конкретные движения в эту сторону. В публикации VS Code об Agent Host от 26 августа 2026 года сессия выделена в отдельный слой, с которым взаимодействуют клиенты и адаптеры агентов. Это архитектурный сигнал, а не доказательство победы одного продукта. Он показывает, что даже внутри существующей IDE можно переосмыслить владельца состояния задачи.

Семантика кода — полезный актив старых IDE

Для аудитории DotNext здесь особенно интересен Roslyn. Его API компилятора и рабочих пространств дают доступ к синтаксису, символам, семантической модели и структуре решения; эти слои не зависят от компонентов Visual Studio. Значит, знания о программе можно предоставлять агенту без требования управлять мышью в редакторе.

Такой доступ уже появляется в продуктах. Документация Rider описывает встроенный с версии 2025.2 MCP-сервер: внешний клиент может обращаться к сборке, диагностике, конфигурациям запуска и инструментам работы с символами. В перечне есть семантическое переименование. Это конкретное направление развития: IDE предоставляет свои возможности как вызываемые операции. Но набор инструментов нужно проверить на выбранной версии Rider и реальном C#-решении — общий протокол не доказывает полноту поддержки языка.

Мой инженерный вывод: агенту полезно предложить операцию «найди ссылки на этот символ в конкретной сборке», когда она точнее поиска совпадений текста. Но статический анализ тоже имеет границу: он не объясняет автоматически бизнес-правило, внешнего потребителя API или поведение динамического кода. Следует проверять, для какого класса задач семантический инструмент сокращает ошибки и стоимость. Наличие богатого API ещё не гарантирует, что агент правильно выберет и применит его.

В разборе совместной эволюции модели, инструментов и процесса я рассматривал их как взаимозависимую систему. Отсюда требование к IDE vNext: открыть полезные способности среды агентам и человеку, сохранив явные границы. Одна универсальная команда с неограниченными полномочиями лишает нас именно тех гарантий, ради которых строилась инженерная платформа.

Представим шестнадцать агентов на четырёх мониторах. Это мысленный пример перегрузки внимания: если каждый исполнитель приносит человеку текстовый поток, увеличение параллелизма легко превращается в ускоренное производство непрочитанных сообщений.

Я бы начал с ограничения одновременно начатой работы. Пять агентов полезны, если выполняют действительно независимые задачи и их результаты можно независимо проверить. Если все меняют один контракт, общую схему данных или один участок кода, возникает очередь согласования. Разделение файлов и отдельных рабочих копий предотвращает часть механических конфликтов; смысловое противоречие между решениями остаётся.

Авторская модель из статьи о дешёвом коде: ускорение реализации может переместить очередь к проверке и выпуску. Реальное ограничение нужно измерить в своей команде.

Прежде чем добавлять панели, стоит определить, когда среда должна отвлечь инженера от текущей работы уведомлением и попросить принять решение. Например, агенту нужно уточнить требование, разрешить конфликт между изменениями, согласовать превышение бюджета или получить разрешение на действие. Такой запрос должен объяснять, почему агент не может продолжить самостоятельно и что требуется от человека. Обычный ход работы можно показывать как компактный статус с подробностями по запросу.

Полезная карточка работы отвечает на несколько вопросов: какой результат обещан, что уже изменено, какая проверка выполнена, почему выполнение остановилось и какое решение требуется. По нажатию инженер должен попадать в конкретный фрагмент изменения, лог проверки или источник ограничения. Сообщение «агент работает» слишком мало помогает принять решение; пересказ всей истории тоже дорог для внимания.

Граф подходит для зависимостей, временная шкала — для событий, сравнение версий — для изменений, текст — для неоднозначного смысла. Нет причины объявлять один из этих форматов универсальным. Иерархия с агентом-координатором тоже может помочь, но она добавляет стоимость координации и риск потери важной детали при передаче отчёта. Человек должен иметь доступ к исходным свидетельствам, а не только к уверенной сводке координатора.

Как проверить такой интерфейс? Дать инженеру несколько задач с заранее известными конфликтами и измерить время обнаружения, число пропущенных проблем и затраты на переключение контекста. Затем сравнить с привычным способом работы. Это предлагаемый эксперимент, а не готовый отраслевой норматив. Он проверяет пользу интерфейса там, где красивая демонстрация почти всегда выглядит убедительно.

Стоит ли объединять IDE и внутреннюю платформу разработки, IDP? Довод в пользу объединения: инженеру нужен весь цикл в одном месте — код, выпуск, метрики и откат. Мой вопрос — в ценности такого объединения: если эти возможности уже есть, добавление вкладки ещё не делает рабочий сценарий лучше.

Содержательное требование звучит иначе: по задаче нужно найти изменение, по изменению — собранный артефакт, по артефакту — конкретное развёртывание, по нему — наблюдаемое поведение. Это связь сущностей и версий. Совпадения имён недостаточно: сервис мог переименоваться, версия могла попасть только в часть окружений, а метрика — описывать сразу несколько компонентов.

Задача → изменение → артефакт → развёртывание → наблюдение → решение

В большой организации препятствие часто находится между системами и командами. Каталог сервисов, учёт расходов, дежурства и телеметрия могут описывать один продукт разными способами. Универсальному агенту приходится угадывать соответствия. Он способен настойчиво обходить API, но настойчивость не превращает неоднозначное сопоставление в достоверное. Если нет общей идентичности и понятных правил доступа, новый интерфейс лишь делает этот долг менее заметным.

Поэтому я бы вкладывался в несколько надёжных возможностей платформы: получить состояние сервиса за выбранный период; показать состав выпуска; найти владельца; выполнить разрешённое действие; подтвердить его результат. У каждой возможности должны быть область действия, компактный ответ, понятная ошибка и сведения о происхождении данных. Агент может составлять сценарий из таких операций, сохраняя человеку возможность проверить каждую связь.

Например, запрос «что изменилось в сервисе расчёта комиссии за час?» должен вернуть версии, окружение, временной диапазон и источники наблюдений. Допустим, после выпуска новой версии выросло число ошибок. Агент может убедительно объяснить это дефектом в новом коде, хотя причина — сбой внешнего сервиса. Если по такому непроверенному объяснению автоматически вернуть предыдущую версию, можно отменить исправное изменение и не устранить сбой. Поэтому среда должна показывать, какими данными подтверждается причина ошибки, и явно сообщать, когда это лишь гипотеза.

Здесь проходит граница ответственности: платформа отвечает за проверяемые факты и разрешённые операции; агент — за выбор последовательности в рамках задачи; инженер — за требования и принятие существенных решений. Это предлагаемое разделение ролей, которое стоит оспорить на круглом столе. Оно не требует единственного окна, зато требует договорённостей между владельцами систем.

Рассмотрим ситуацию: команда использует несколько инструментов, а правила проекта приходится раскладывать по разным файлам и проверять на расхождения. За этим стоит более широкий вопрос — что организация действительно контролирует при смене агента. Возможность выбрать другую модель в списке ещё не означает возможность перенести рабочий процесс.

MCP описывает подключение инструментов; Agent Client Protocol — взаимодействие редактора с агентом. Это разные границы. JetBrains описывает подключение агентов через ACP, сохраняя собственную среду работы инженера. Такие проекты делают композицию практичнее, но протокол подключения не стандартизует инженерное суждение.

На дату проверки документация ACP отдельно отмечает, что полная поддержка удалённых агентов ещё разрабатывается. Совместимость локального подключения нельзя автоматически переносить на любой облачный сценарий.

Даже общий текст инструкций разные системы могут читать в разной последовательности, с разными ограничениями контекста и правилами подтверждения. А незавершённая задача включает не только сообщения: есть выбранная версия репозитория, результаты инструментов, фоновые процессы, полномочия и неудачные попытки. Потеряв их, новый агент способен повторить уже отвергнутый путь или принять старую проверку за актуальную.

Моя практическая позиция из статьи о конфигурациях агентного стека — разделять заменяемые компоненты и собственные договорённости команды. Требование к результату, правила доступа и независимая приёмка должны оставаться понятными за пределами одного продукта. Специфические удобства поставщика можно использовать, если известна цена выхода из них.

Небольшой тест переносимости выглядит так: остановить задачу после первого проверяемого результата и передать её другому инструменту. Сможет ли он найти актуальную версию, понять незакрытые вопросы, повторить проверку и продолжить работу без пересказа всего чата? Необязательно переносить внутреннее состояние модели побитово. Важно сохранить инженерные обязательства и достаточно свидетельств для следующего шага.

При этом полная взаимозаменяемость тоже стоит денег. Интегрированный продукт может давать более удобный процесс именно потому, что контролирует все части. На круглом столе интереснее обсудить минимальную переносимую границу и условия выхода, чем требовать одинакового поведения от всех инструментов. И отдельно спросить поставщиков, какие данные и результаты останутся доступны пользователю после смены продукта.

Идея полной прослеживаемости — связать модель, инструменты, нескольких агентов и работающую систему — требует разделить две задачи. Первая — понимать, что реально произошло и какие свидетельства доступны. Вторая — полностью объяснить внутренние причины ответа модели. Для инженерного допуска нам нужна первая; журнал действий сам по себе не решает вторую.

Минимальная цепочка доказательств связывает версию требования, исходный код, конкретные вызовы инструментов, полученное изменение, результаты проверок и решение о выпуске. У проверок должно быть понятно, к какому состоянию они относятся. Зелёный тест на предыдущей версии не доказывает корректность текущей. Уверенный текст агента тоже не заменяет проверку.

OpenTelemetry развивает соглашения для телеметрии GenAI, включая вызовы моделей и инструментов. Это полезный технический слой для корреляции событий. Моё требование к среде шире: связывать эту телеметрию с задачей, изменением и критериями приёмки. И хранить только необходимые данные с контролем доступа: бесконечное сохранение содержимого запросов не является обязательным условием наблюдаемости.

Полезное направление показывает и описание Anthropic обвязок для долгих задач: сохранение состояния между сессиями и явная проверка результата помогают продолжать работу. Это опыт конкретного поставщика, а не универсальная гарантия надёжности. Для собственной системы всё равно нужно проверить, что агент не выдаёт частичное выполнение за завершение.

Что должно происходить перед принятием изменения

Вернёмся к примеру с комиссией. Я хочу видеть исходное правило и его неоднозначности, перечень затронутых случаев, изменения в коде и независимую проверку инвариантов. Если агент сам написал реализацию и тесты из одной ошибочной предпосылки, успешный запуск этих тестов не снимает проблему. Независимость означает иной источник ожидаемого результата: согласованные примеры, ранее зафиксированные ограничения или отдельную проверку специалиста.

Граница полномочий должна исполняться вне текста просьбы к модели. Читать логи, менять рабочую копию, публиковать изменение и выполнять операцию в рабочей системе — разные действия. Для опасной операции нужна проверка разрешения на конкретный объект и состояние. Изолированная среда ограничивает часть побочных эффектов; она не исправляет неверное требование и не заменяет проверку доступа к внешнему сервису.

В моей текущей позиции выпуск существенных изменений подтверждает человек. Пересмотр этой границы возможен для заранее выделенного класса обратимых действий с независимым допуском и проверенным восстановлением. Это условие будущего расширения автономии, а не разрешение убрать человека из любого процесса. Даже откат требует доказательства: отмена кода не обязательно отменяет уже записанные данные или отправленные сообщения.

Хороший вопрос к создателям IDE: покажите задачу, в которой агент ошибся. Как инженер обнаруживает ошибку, останавливает дальнейшие действия и восстанавливает состояние? Демонстрация отказа расскажет о зрелости среды больше, чем очередной успешный проход по заранее подготовленному примеру.

Если новая среда позволяет запускать больше агентов, это ещё не означает рост производительности команды. Нужно учитывать результат и весь человеческий труд вокруг него. В статье об экономике AI в разработке я предлагаю считать принятую работу; в более позднем разборе инженерии уточняю границу между фактическими расходами и отдельно оцениваемым риском.

Стоимость принятой задачи = фактические затраты на исполнение, проверку и переделки / число сопоставимых принятых задач

В числителе остаются и неудачные попытки. Если десять запусков дали два пригодных результата, нельзя делить стоимость только двух удачных запусков на два. Человеческое время оценивается по согласованной ставке; время ожидания измеряется отдельно как задержка процесса. Ожидаемые потери от риска тоже стоит показывать отдельно, чтобы не складывать их второй раз с уже учтёнными расходами на инциденты.

Есть хороший повод не доверять одному впечатлению. В рандомизированном исследовании METR 2025 года 16 опытных разработчиков выполняли 246 задач в знакомых им открытых проектах; доступ к изученным тогда AI-инструментам увеличил время выполнения в среднем на 19%. Это результат конкретной выборки и инструментов начала 2025 года. Он не доказывает, что агенты вообще замедляют разработку.

Обновление METR от 24 февраля 2026 года особенно важно читать вместе с первым исследованием: авторы описывают смещения отбора участников и задач, мешающие надёжно оценить текущий эффект. Нельзя превратить старое замедление в вечный закон или новые наблюдения — в универсальное обещание ускорения. Практический вывод скромнее: собственный процесс нужно измерять, а ощущение удобства отделять от результата.

Есть и положительный результат. В трёх полевых экспериментах Cui и соавторов с 4 867 разработчиками объединённая оценка показала рост числа завершённых задач примерно на 26%. Но это эксперименты 2022–2023 годов с помощником автодополнения, опубликованные в версии работы 2025 года, а не проверка автономных агентов 2026 года. Среди авторов есть сотрудники Microsoft. Работу оценивали по метрикам компаний, включая запросы на включение изменений. Вместе с METR это аргумент в пользу конкретного вопроса: кому, на каких задачах и при каком процессе помогает инструмент?

Я бы сравнивал инструменты на нескольких типах реальной работы: локальное исправление, изменение сквозного контракта и диагностика проблемы в эксплуатации. Для каждого типа нужны одинаковые критерии приёмки и сопоставимая сложность. Порядок использования инструментов стоит менять, иначе обучение на первой попытке будет выглядеть преимуществом второго продукта. Небольшой пилот даст материал для решения своей команды, но не рейтинг для всей индустрии.

Именно поэтому вопрос «сколько агентов одновременно поддерживает IDE?» слишком слаб. Сильнее спросить: сколько проверенных изменений проходит через систему, сколько человеческого внимания это требует и как ведёт себя стоимость при неудаче. Такая постановка соединяет интерфейс, обвязку, платформу и экономику в один проверяемый сценарий.

Я предлагаю обсудить вопросы, по которым возможны разные инженерные ответы. Для каждого важно получить конкретный пример, демонстрацию или измеримый критерий: так станет понятно, в чём участники расходятся и как проверить их доводы.

Первый неудобный вопрос поставщикам: что в вашем продукте останется ценным, если модель станет заметно сильнее? Возможные ответы — семантика кода, управляемое исполнение, доказательства результата, интеграция с организацией, удобство принятия решений. Но каждый ответ нужно подтвердить сценарием, а не количеством функций.

Второй вопрос командам: какую собственную несогласованность вы сейчас поручаете агенту преодолевать заново? Если он каждый раз сопоставляет сервисы, права и окружения, возможно, полезнее исправить одну возможность платформы. Это не отменяет пользу агента; это делает её дешевле и надёжнее.

Третий вопрос инженерам: какое действие вы готовы делегировать полностью и на основании какого свидетельства? Ответ «когда модель перестанет ошибаться» не задаёт рабочего критерия. Список допустимых действий, независимых проверок, ограничений и способов восстановления уже позволяет построить эксперимент.

Два горизонта вместо одной картинки будущего

На ближайший горизонт я бы проверял совместную работу привычных редакторов, семантических инструментов, отдельных агентных сессий и платформенных операций. На более дальний — среду, в которой основной объект взаимодействия станет намерением, ограничениями и доказательством результата, а код будет одним из доступных уровней детализации. Это мой сценарий развития, не прогноз с гарантированной датой.

У него есть условие опровержения: если стоимость независимой проверки и восстановления не снижается, людям придётся чаще возвращаться к непосредственной работе с кодом. Поэтому за вопросом «кто построит дом для агентов?» для меня стоит другой практический интерес: кто поможет инженеру сохранить понимание и ответственность при растущей скорости исполнения. Этот дом может иметь несколько интерфейсов. Но у него должны быть понятные правила, проверяемые результаты и выход, которым действительно можно воспользоваться.