Ключевые выводы

Контекст дороже модели. Две IDE с одной и той же LLM дают разный результат, если по-разному индексируют репозиторий, режут контекст и подключают LSP. Узкое место чаще в том, что попало в промпт, а не в названии флагмана.

Код для машины — это три слоя: текст (патч, grep), символы (LSP: типы, ссылки, диагностика) и семантика репозитория (векторные представления, поиск по кодовой базе). Надёжные правки используют все три; слабые — только текст.

Tab, чат и агент — не «уровни одной кнопки». Автодополнение, диалог и агент с терминалом — разные продуктовые режимы с разной областью риска. Путать их — как использовать дрель для варки супа.

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

Человек остаётся владельцем патча. IDE ускоряет написание; ответственность за слияние, продакшен и архитектуру не делегируется расширению.

Эволюция: от редактора к агентной среде

История не началась с ChatGPT. Она началась с того, что IDE научились понимать структуру, а не только показывать символы.

1980–2000‑е: подсветка синтаксиса, отладчик, рефакторинг «переименовать символ» в одном языке. Редактор знал мало о проекте целиком.

2010‑е: Language Server Protocol (LSP) — единый протокол между редактором и анализатором языка. Переход к определению, поиск ссылок, диагностика, автодополнение по типам. IDE стала видеть символы, не только строки.

2010‑е (параллельно): Git внутри IDE — blame, diff, stage. Код стал версионируемым артефактом, с которым работают визуально.

2021: GitHub Copilot — встроенное автодополнение по контексту открытого файла и соседних вкладок. Модель предсказывает следующий фрагмент; человек принимает Tab. Революция скорости на локальном участке.

2022–2023: чат в IDE — объяснение, рефакторинг, «напиши тест». Контекст чаще ограничен явно выделенным кодом или файлом.

2024: многофайловые правки — Composer, «редактировать проект», патчи на несколько файлов за один запрос. IDE перестала быть однофайловой.

2025–2026: агентный цикл — модель сама ищет файлы, запускает grep и терминал, применяет правки итерациями; MCP подключает внешние инструменты; фоновые агенты (облачные исполнители, агент кодирования в CI) работают в отдельной ветке или VM.

Важно: каждый этап не отменял предыдущий. LSP по-прежнему подсвечивает ошибку, которую агент внес за секунду до слияния. Git по-прежнему показывает blame, когда «улучшение» оказалось чужим патчем из прошлого спринта. Встроенное автодополнение не исчез — оно осталось самым дешёвым режимом для рутины.

Параллельная линия — удалённая разработка: Codespaces, Gitpod, облачная IDE. AI-агент логично продолжает эту траекторию: среда, где код, терминал и модель живут рядом, а не в трёх разных вкладках браузера.

Эволюция сдвинула единицу работы: от символа → файла → подсистемы → репозитория + окружение. Каждый шаг умножил полезность и умножил цену ошибки.

Что значит «работать с кодом» для машины

Разработчик думает классами, контрактами, потоками данных. Модель в IDE по умолчанию получает текст. Между ними — несколько слоёв, которые хорошие инструменты склеивают.

Слой 1: текст

Поиск по строкам (grep, ripgrep), патч, поиск и замена. Быстро, предсказуемо, не требует компиляции. Слабость: не видит переименование через re-export, не понимает, что два текста «похожи», но семантически разны.

Слой 2: символы (LSP)

Language Server знает AST-подобную модель: типы, импорты, ссылки, неиспользуемые символы, ошибки компиляции. IDE показывает диагностику агенту или человеку. Это слой «где править безопасно» и «что сломается сразу».

Слой 3: семантика репозитория

Векторные представления, индекс кодовой базы, @-упоминания файлов и папок. Ответ на «где живёт логика оплаты?» без точного имени файла. Слабость: индекс устаревает, похожие фрагменты путаются, редкий путь не попал в top‑k.

Почему одного слоя мало. Только текст → агент правит не тот модуль. Только LSP → не видит архитектурный документ или конфиг деплоя. Только векторные представления → «находит похожее», но не гарантирует актуальность.

Как IDE применяет правки

Большинство AI-IDE не просят модель «переписать весь файл» на каждый шаг. Чаще:

• Блоки поиска и замены — минимальный патч, проще ревью;
• Перезапись целого файла — для маленьких файлов или сильной перестройки;
• Применение unified diff — как git apply, с риском маркеров конфликта.

Человек в виде сравнения изменений видит зелёное/красное; LSP подсвечивает синтаксические и типовые ошибки после применения. Поэтому цикл «Агент → диагностика → исправление» часто быстрее, чем один огромный патч без обратной связи от компилятора.

Конфликт слияния и конфликт агента — разные вещи. Агент может успешно применить патч в вашей ветке, но сломать контракт с соседним сервисом, который LSP не видит. Это возвращает к экономике риска тестирования: IDE не знает цену вашего отказа, если вы не задали её в rules и CI.

Мой опыт. На легаси-монолите Tab + LSP часто достаточны внутри одного модуля. Сквозная фича через пять пакетов без агента и без явного @ контекста — лотерея. Подробнее про границу «генерация vs инженерия» — в статье про то, где заканчивается код и начинается инженерия.

Фоновые и облачные агенты

Отдельный класс — агент вне вашего ноутбука: задача в очереди, работа в VM или удалённой ветке, результат — PR или патч на ревью. Вы не видите каждый вызов инструмента в реальном времени; вы видите итог и лог. Это ближе к задаче CI, чем к автодополнению по Tab.

Плюс: длинные задачи не держат IDE открытой. Минус: цикл обратной связи длиннее, контекст «на момент старта» устаревает, если параллельно сливают другие PR. Для продакшен-критичных систем фоновый агент без жёсткого CI и без ревью ответственного — тот же риск, что «джун сделал за выходные», только быстрее.

Анатомия современной AI-IDE

На примере Cursor (форк VS Code) — та же логика у большинства AI-IDE, различаются детали.

Оболочка редактора

VS Code, JetBrains Platform, Zed — оболочка для вкладок, LSP, Git, терминала, расширений. AI — надстройка, но всё ещё опирается на диагностику LSP и файловую модель рабочей области.

Индексация репозитория

При открытии проекта строится или обновляется индекс: файлы, векторные представления, иногда игнорируемые пути (.gitignore, .cursorignore). Большие бинарники и node_modules обычно исключены. Устаревший индекс — классический сбой: агент «не видит» ваш свежий файл, пока индекс не догнал.

Сборка контекста

В промпт попадает не «весь репозиторий», а бюджет:

• открытые файлы и курсор;
• явное выделение;
• @file, @folder, @codebase, @docs;
• rules (постоянные инструкции проекта);
• skills (сценарии для типовых задач);
• история чата в сессии;
• вывод последних вызовов инструментов.

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

Практическое следствие: не полагайтесь на «агент сам найдёт» для критичных инвариантов. Явно прикрепляйте контракт, схему, миграцию, ADR — или держите их в rules. Бюджет контекста — общий котёл: длинный чат с вчерашним экспериментом вытесняет файл с типами, без которых агент начнёт выдумывать поля.

Автодополнение по Tab под капотом

Tab — не «мини-ChatGPT». Обычно это отдельная быстрая модель или тот же LLM с узким окном: текущий файл, несколько строк до/после курсора, иногда соседние вкладки. Задача — предсказать продолжение, а не спланировать рефакторинг. Поэтому Tab блестяще пишет map/filter, скучный JSON и повторяющиеся тесты — и плохо «понимает», что вы меняете архитектурный инвариант на другом конце репозитория.

Режимы: Tab, чат, агент

Это разные продукты, не «слайдер смелости». Tab не должен запускать миграцию БД. Агент не нужен для переименования переменной в одном файле.

flowchart LR
  Index[Index_and_LSP]
  Context[Context_assembly]
  Model[LLM]
  Tools[Tools_edit_shell]
  Human[Human_review]
  Index --> Context --> Model --> Tools --> Human

Монорепозиторий, микросервисы и границы контекста

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

Практика, которая работает:

• Rules с явными границами — «пакет @app/billing не импортирует @app/catalog напрямую»;
• Корни рабочей области — открывать подпапку монорепозитория, если задача локальна (меньше шума в индексе);
• Контрактные тесты между сервисами — агент не видит соседний репозиторий, пока вы не подключите его через submodule, MCP или явный @.

В компании с несколькими репозиториями IDE почти всегда видит одну локальную копию. Сквозная фича «API + consumer + mobile» требует либо нескольких окон, либо MCP к внутренней документации и спецификациям API, либо человека, который собирает контекст вручную. Ожидание «агент сам найдёт всё в GitHub org» обычно ломается на правах доступа и лимитах поиска.

Мой опыт. В монорепозитории из 2000+ файлов Tab в одном пакете остаётся безопасным; агент без @folder на нужный пакет слишком часто «улучшает» соседний модуль с похожим именем. Сузьте рабочую область — и качество патча растёт без смены модели.

Цикл агента: план → инструмент → наблюдение → патч

Агентный режим — не один ответ, а цикл:

1. План — разбить задачу (явно или неявно).
2. Инструмент — read_file, grep, list_dir, загрузка из сети, инструмент MCP.
3. Наблюдение — stdout, линтер, результат теста, размер патча.
4. Патч — применить правку; повторить или завершить.

Типичные инструменты:

• Чтение / поиск — найти, где живёт поведение.
• Правка — поиск и замена или запись целого файла; качество зависит от размера патча.
• Терминал — test, build, npm, git; наибольший риск в корпоративном контуре.
• Обратная связь линтера — диагностика как сигнал «ещё итерация».

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

Пример цикла (упрощённо)

Задача: «добавь валидацию email в форму регистрации».

1. Агент ищет register / signup → находит компонент формы и обработчик API.
2. Читает оба файла + схему DTO.
3. Патч: zod/yup rule на клиенте, validator на сервере.
4. Запуск unit-теста → красный (забыл крайний случай с адресами через плюс).
5. Патч теста + исправление regex → зелёный.
6. Предлагает патч человеку.

На шаге 4 LSP мог бы поймать типовую ошибку раньше, если типы общие. На шаге 2 без @ схемы агент мог бы не увидеть общий пакет @app/validation — и продублировать правило несовместимо с остальным API.

С управлением такими циклами в SDLC пересекается агентная инженерия — там про процессы команды; здесь про механику IDE.

Мой опыт. Агент на «добавь поле в форму + API + тест» экономит час, если контракт API уже описан в rules. Агент на «разберись, почему падает прод ночью» без логов и без явной области задачи — генератор лишних патчей.

Сравнение экосистем (2026)

Без рейтингов «лучший» — оси, по которым выбирают.

CLI vs IDE. CLI-агент удобен в CI, для пакетного рефакторинга, для серверов без GUI. IDE-агент — для быстрого цикла обратной связи с LSP и визуальным сравнением изменений. На инциденте в продакшене я чаще начинаю с логов + чат; агента подключаю, когда область файлов понятна.

JetBrains и «глубина языка»

В семействе IntelliJ AI часто опирается на богатый PSI (Program Structure Interface) — глубже, чем минимальный LSP. Рефакторинг «изменить сигнатуру интерфейса и все имплементации» исторически был сильной стороной JetBrains. AI-слой здесь — продолжение: модель + уже существующие безопасные рефакторинги, а не только текстовый патч.

Zed и скорость

Zed делает ставку на производительность редактора и совместную работу. AI в таких редакторах — ещё один слой; выигрыш — когда цикл обратной связи упирается в лаг UI, а не только в задержку модели.

Детальное «что выбрать команде» — в planned satellite developer-ai-toolchain-2026; эта статья — как устроено, не список покупок.

MCP и расширяемость

Model Context Protocol (MCP) — стандарт «IDE/агент ↔ внешний инструмент»: Jira, Slack, БД только для чтения, внутренняя документация, статус развёртывания. IDE перестаёт быть островом; агент получает живые данные, не только файлы.

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

Ограничения и типичные сбои

Устаревший индекс — агент правит старую версию или «не находит» новый файл. Лечение: переиндексировать, явный @file, обновить.

Неверный файл — семантически похожий модуль из другого ограниченного контекста. Лечение: rules с границами, контрактные тесты.

Избыточный рефакторинг — «заодно улучшил» 40 файлов. Лечение: узкий промпт, маленькие PR, запрет побочных правок в rules.

Зелёный патч — красный прод — тесты не покрыли инвариант; см. экономику стоимости ошибок: дешёвая генерация не отменяет цену отказа.

Утечка контекста — секреты в промпте, .env в индексе. Лечение: файлы исключений, режим приватности, pre-commit hooks.

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

Как отлаживать «странный» патч

Если результат неожиданный, проверьте по порядку:

1. Что реально попало в контекст — какие файлы, rules, обрезанные фрагменты (в Cursor — список прикреплённого контекста).
2. Свежесть индекса — новый файл мог не попасть в векторные представления.
3. Режим — Tab vs агент дают разную «смелость»; чат без инструментов не должен менять 20 файлов.
4. LSP после применения — диагностика показывает синтаксис/типы, но не бизнес-инварианты.
5. Размер патча — если >15–20 файлов без вашего запроса, остановите и сузьте задачу.

Лог цикла агента (вызовы инструментов, stderr) — ваш главный артефакт для разбора после сбоя. Без него «модель ошиблась» не воспроизводится. В командах со стендом оценки такие прогоны иногда сохраняют как эталонные прогоны для регрессии — см. ai-eval-harness-2026.

Корпоративный контур

В компании IDE — точка доступа с доступом к коду:

• Приватность / нулевое хранение — данные не на обучение; иногда только корпоративный API.
• Белый список моделей и провайдеров — соответствие требованиям, регион данных.
• Запрет терминала или только песочница для агента.
• Аудит — кто какой патч принял; связка с SSO.
• Сканирование секретов на уровне репозитория + IDE ignore.

См. также безопасную разработку с ИИ и стенд оценки для агентных изменений — ai-eval-harness-2026.

Отдельный вопрос — кто владеет rules. Если каждый разработчик кладёт свои .cursor/rules, получается зоопарк. Зрелые команды выносят базовые rules в репозиторий, версионируют их как код и ревьюят так же, как конфиг lint. Rules — это архитектура контекста, не личные заметки.

Внедрение в команде без хаоса

Типичный путь зрелой организации:

1. Пилот — 5–10 инженеров, один репозиторий, режим приватности, запрет фоновых агентов.
2. Базовые rules — стек, команды CI, границы модулей; PR на rules так же, как на конфиг eslint.
3. Руководство по агентам — какие задачи разрешены (шаблонный код, тесты), какие запрещены (деплой в прод, миграции БД без DBA).
4. Метрики — не «сколько строк сгенерировано», а время до слияния, доля откатов, падение CI после PR от агента.
5. Проверка безопасности — .cursorignore, белый список MCP, DLP на вставки в чат.

IDE не заменяет ревью кода. Наоборот: чем шире область действия агента, тем строже ревью человеком на архитектуру и безопасность. Planned satellite code-review-ai-era-2026 разберёт чеклист для ревьюера; здесь важно: корпоративный контур начинается с политик, а не с закупки лицензий.

Как выбирать режим под задачу

Правило: чем выше цена ошибки, тем уже область действия агента и тем больше доказательств (тесты, ревью, канареечный выпуск). На платежах и правах — чат с явным контекстом + человек; не «агент до зелёного CI».

Skills и rules как «архитектура контекста»

Rules — постоянные ограничения: стиль, команды тестов, запреты («не трогать /billing без ревью архитектора»). Skills — упакованные сценарии: «опубликовать статью», «прогнать research pipeline». Оба попадают в системный слой до вашего промпта.

Без rules агент опирается на среднее по обучающим данным — а ваш репозиторий редко совпадает с «средним GitHub». С rules IDE становится ближе к документу онбординга, который модель реально читает каждый раз. Planned satellite ai-ide-rules-skills-playbook-2026 развернёт это в командное руководство; здесь достаточно понимать: rules — не магия, а дешёвый способ снизить цену ошибки без смены модели.

Анти-паттерны

• «Агент, сделай всё» без критериев готовности — патч на 80 файлов и усталость ревьюера.
• Длинный чат на неделю — контекст забит устаревшими гипотезами.
• Игнор диагностики — слияние с красным LSP «потому что агент сказал готово».
• Одинаковый режим для всех задач — Tab на архитектуре, агент на опечатке.

Что сделать на этой неделе

1. Rules — 10–20 строк: стек, границы модулей, «не трогать без теста», команды проверки.
2. Ignore — убедиться, что .env, ключи, dist/, огромные артефакты не индексируются.
3. Одна задача для агента с критериями готовности: «готово = тест X зелёный, патч ≤ N файлов».
4. Карта слепых зон — что модель не видит (флаги, cron, внешние вебхуки); допишите в rules или docs.

Следующий логичный материал кластера — ревью кода в эпоху AI (planned: code-review-ai-era-2026): что проверять человеку после патча агента.

FAQ

Дальнейшее чтение

• Агентная инженерия в 2026 — процессы команды вокруг агентов.
• Где заканчивается генерация кода — философия ответственности.
• MCP в продакшене — инструменты за пределами репозитория.
• Экономика стоимости ошибок — цена отказа vs скорость генерации.
• Стенд оценки для агентов — проверка результата агента в CI.
• Безопасная разработка с ИИ — политики и угрозы.

IDE 2026 года — не «умнее программист». Она быстрее собирает контекст и быстрее предлагает патчи. Кто понимает конвейер — тратит меньше токенов на хаос и меньше ночей на откат патча агента. Следующий шаг после этой статьи — не смена IDE, а дисциплина контекста: rules, ignore, режим под задачу и честное ревью патча. Это заметно дешевле в 2026 году, чем гонка за «самой умной» моделью без понимания конвейера.