IDE vNext: кто построит дом для ИИ-агентов?

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

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

Андрей возражает против предположения, что писать код стало неважно. Созданный объём приходится читать и проверять; он же занимает контекст модели. Ответственность за результат по-прежнему несёт человек. Естественный язык тоже не всегда ускоряет работу: найти использования символа горячей клавишей быстрее, чем сформулировать запрос агенту и дождаться ответа. Значит, полезная среда должна сочетать способы взаимодействия, а не заставлять каждое точное действие проходить через разговор. Удобство делегирования не делает проверку лишней.

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

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

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

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

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

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

Дмитрий ожидает смыслового сближения IDE и платформ разработки, но сомневается в появлении одной системы для всех. Компании уже используют разные хранилища кода, документы и интеграции; переезд имеет цену. Александр возвращает разговор к намерению пользователя: человеку часто нужен ответ о проблеме сервиса или данных, а не самостоятельный обход журналов и панелей. Возможности платформы следует делать доступными агентам, сохраняя профессиональные инструменты для подробного исследования. Его пример обучения руководителей показывает интерес к такому взаимодействию, но также упирается в вопросы доступа и безопасности. Финал остаётся открытым: готового общего проекта IDE нет, есть направления работы — интеграция, удобное делегирование и сохранение понимания результата.