Интеграция с IDE: grounding и review

1. IDE не отменяет terminal-first, а делает его проверяемым

Две крайности: сидеть только в терминале, веря, что Claude всё понял сам, — или тащить всё в IDE, забыв, что workflow начинается из проекта в терминале. Роли разные. Терминал — пульт: запуск, режимы, вывод команд, контроль сессии. IDE — место, где изменение видно: точный фрагмент, diff в контексте файла, сравнение «до/после».

Главная мысль: IDE не отменяет terminal-first workflow, а делает его проверяемым. Claude вы по-прежнему запускаете из корня и управляете через CLI. Но на чтении кода и проверке diff IDE снижает шанс, что вы поверите красивому ответу вместо реального изменения. В терминале Claude звучит убедительно, иногда слишком. IDE возвращает разговор в инженерную плоскость: вот файл, строка, соседний метод, фактическое изменение. С формулировкой спорить можно долго. Diff либо устраивает вас, либо нет.

2. Grounding делает не Claude умнее, а ваш запрос конкретнее

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

Откройте файл расчёта возврата из нашего Commerce OS:

import java.math.BigDecimal;

public class RefundService {
    public BigDecimal calculateRefund(BigDecimal total, BigDecimal discount) {
        return total.subtract(discount);
    }
}

На запрос «исправь расчёт возврата» Claude гадает: о каком месте речь, искать ли другие файлы, менять ли сигнатуру, трогать ли соседей. Сравните с запросом из выделения в IDE:

Проверь выделенный метод.
Нужна минимальная правка без изменения сигнатуры.
Сначала объясни риск, потом покажи diff.

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

Ещё две вещи почти бесплатно: упоминание файлов и диапазоны строк. Вместо «посмотри компонент со статусом» — «проверь support/TicketRow.tsx» или «сравни строки 18–30 с паттерном в соседнем файле». Точнее привязка — меньше сюрпризов в diff.

IDE не делает Claude умнее — делает конкретнее ваш запрос. Конкретность — половина качества. Вторая половина — проверка глазами, к ней вернёмся ниже.

3. Берите ту IDE, которой уже пользуетесь

Здесь включается соблазн устроить войну редакторов: VS Code против IntelliJ IDEA, WebStorm, PyCharm и всего зоопарка. Для курса бесполезно. Нужна стабильная поверхность, где удобно читать код и проверять изменения. По задачам лекции обе экосистемы делают одно: открыть проект, выделить фрагмент, передать Claude как контекст, увидеть diff рядом с кодом, перейти к файлу, посмотреть историю. Разница — в интерфейсе, горячих клавишах и том, что идёт «из коробки».

Вывод: берите то, чем уже пользуетесь. Живёте в IntelliJ IDEA, WebStorm, PyCharm — не переезжайте ради моды. Основной инструмент VS Code — не переучивайте руки. Курс не про выбор IDE, а про связку Claude + код + проверка.

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

4. Плагин IDE — надстройка над CLI, не замена

С выбором определились — подружите IDE с Claude Code. Способов установки, как и у CLI, несколько; выбирайте тот, что укладывается в ваш workflow.

Запомните: плагин не заменяет CLI и не работает без него. Это надстройка над уже установленным Claude Code. Не прошли установку и первый запуск CLI из предыдущей лекции — сначала туда. Иначе плагин встанет, но скажет, что не видит работающего CLI или авторизации.

Установка в VS Code

Два честных пути, оба нормальные.

Путь первый — auto-install через CLI. Удобнее всего, если CLI уже стоит. Откройте проект в VS Code, откройте встроенный терминал (Ctrl+` или View → Terminal), запустите claude. CLI обнаружит, что вы внутри VS Code, и предложит поставить расширение. Согласитесь — установится автоматически.

Путь второй — через Extensions Marketplace. Если автоустановка не сработала или хотите поставить заранее:

1. Откройте Extensions (Cmd+Shift+X на macOS / Ctrl+Shift+X на Windows и Linux)
2. В поиске введите: Claude Code
3. Выберите официальное расширение от Anthropic
4. Нажмите Install

После установки в боковой панели появится иконка Claude — обычно слева. Это панель разговора с Claude внутри IDE. Иконки не видно — смотрите в Activity Bar, она бывает свёрнута в ....

Что проверить сразу: откройте панель Claude, выделите фрагмент кода, нажмите «обсудить с Claude» (название кнопки зависит от версии). Разговор начался — связка CLI + IDE работает. Плагин ругается на отсутствие CLI — значит, CLI не установлен или не в PATH той среды, из которой запущен VS Code. На Windows частый случай: VS Code из Windows-окружения, CLI в WSL. Вернитесь к таблице из предыдущей лекции и сверьте, в одной ли среде CLI, проект и IDE.

Установка в JetBrains (IntelliJ IDEA, WebStorm, PyCharm, GoLand и др.)

Логика та же: автоустановка через CLI либо Marketplace.

Путь первый — auto-install через CLI. Откройте проект в любой IDE семейства JetBrains, откройте встроенный терминал (View → Tool Windows → Terminal или Alt+F12), запустите claude. CLI определит IDE и предложит установить плагин. Согласитесь. Часто нужен перезапуск IDE — это нормально для всех JetBrains-плагинов.

Путь второй — через Plugins Marketplace:

1. Settings/Preferences → Plugins (Cmd+, на macOS / Ctrl+Alt+S на Windows и Linux)
2. Перейдите на вкладку Marketplace
3. В поиске введите: Claude Code
4. Выберите официальный плагин от Anthropic
5. Нажмите Install
6. Перезапустите IDE по приглашению

После перезапуска в правой панели (по умолчанию) появится Tool Window с Claude — точное место зависит от версии. Не видите — View → Tool Windows → Claude Code или через Find Action (Cmd+Shift+A / Ctrl+Shift+A).

Момент, который удивляет: плагин ставится в каждую IDE отдельно. Пользуетесь и IntelliJ IDEA, и WebStorm — ставьте в обе: общая платформа, но плагины конфигурируются по продукту. Зато auth работает один раз: авторизовались в CLI — плагин подхватит то же.

Авторизация плагина

Обычно плагин использует ту же авторизацию, что и CLI. Прошли login в CLI (claude в терминале, через браузер) — плагин её увидит и заработает. Отдельного входа не нужно.

Плагин при первом запуске просит залогиниться отдельно — значит, не видит вашу CLI-сессию. Причина та же, что у «плагин не видит CLI»: разные окружения, пути, shell. Лечится запуском IDE из той же среды, где живёт CLI. На Linux и macOS обычно решается само. На Windows — смотрите, откуда запущена IDE: Windows-native или WSL.

Маленькая проверка работоспособности

Чтобы убедиться, что интеграция живая, а не просто иконка в панели, прогоните минимальный сценарий:

1. Откройте любой файл проекта.
2. Выделите 5–10 строк кода.
3. Откройте панель Claude.
4. Попросите коротко: «Объясни выделенный фрагмент».
5. Получите ответ, в котором Claude действительно ссылается на выделенный код.

Claude ссылается на ваш код, упоминает имена методов или переменных из него — связка работает. Ответ общий («обычно такой код делает X») — выделение не прокинулось, плагин работает как обычный чат. Разбирайтесь с настройками или версией.

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

5. Открытый файл — не контекст. Контекст вы передаёте явно

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

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

Объясни, что делает выделенный метод и какие у него граничные случаи.

Исправь только выделенный фрагмент в файле payments/RefundService.java.
Не меняй сигнатуру метода и не трогай соседние классы.

Сравни строки 18–30 в support/TicketRow.tsx
с существующим паттерном в orders/OrderBadge.tsx.

Лишнего нет — есть рамка. Вы не душите ИИ, а помогаете ему не расползаться за границы задачи. Умную правку Claude всё равно предложит, но в пределах коридора.

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

6. Diff показывает правду, текст — нет

У ИИ-инструментов вечная проблема: они отлично объясняют, что якобы сделали. Иногда лучше, чем делают. Поэтому IDE ценна не на «получить ответ», а на прочитать diff в контексте файла. Лишний импорт, тронутую сигнатуру, полфайла переформатированного кода IDE покажет без сантиментов.

Claude посмотрел на метод расчёта возврата и предложил правку:

 public BigDecimal calculateRefund(BigDecimal total, BigDecimal discount) {
-    return total.subtract(discount);
+    BigDecimal safeDiscount = discount == null ? BigDecimal.ZERO : discount;
+    return total.subtract(safeDiscount);
 }

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

Запомните формулу: Claude предлагает изменение, IDE показывает его в контексте, решение принимает человек. Тут и ломается слепое доверие. Смотрите только на текст — примете красивое объяснение за качество. Смотрите на diff — принимаете решение по фактам. Так вы и ловите красный флаг: просили поправить строчку, а Claude полез в конфигурацию сборки.

7. Чат рядом с кодом: сверяйте обещание с фактом

IDE держит разговор и код рядом. Попробуйте иначе: читать план в одном окне, переключаться в редактор, возвращаться в чат, открывать diff — и забыть, что Claude обещал не менять. Внимание расползается, проверка буксует.

Когда история, файл и diff рядом, проверка спокойнее. Claude пишет: «Изменю только RefundService.java, сигнатуру не трогаю». Вы смотрите на файл и убеждаетесь. Или видите, что в изменениях внезапно ещё один файл, которого в плане не было. IDE помогает не столько редактировать, сколько сверять обещание с фактом — не нужно держать в голове, где был метод, что обещал Claude, какие строки выделяли. Перед глазами и контекст, и предложение, и результат.

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

8. Сценарий Commerce OS: где рождается решение

В Commerce OS оператор поддержки жалуется: при подготовке возврата интерфейс падает, если скидка в заказе не заполнена. Проект вы открыли в терминале и запустили Claude Code, но решение рождается в IDE.

Откройте payments/RefundService.java, найдите метод, выделите его — не весь файл, не пакет, а конкретное место. Дальше просите приземлённое:

Проверь выделенный метод расчёта возврата.
Нужна минимальная правка только в этом файле.
Сначала объясни проблему, потом покажи diff.

Claude отвечает, что риск в discount == null, и предлагает тот самый маленький diff. В IDE видно не только patch, но и то, что вокруг: сигнатура не изменилась, соседние методы не тронуты, файл не разъехался по форматированию, лишних правок нет. Только теперь — «да, это похоже на нормальную правку».

В короткой схеме связка такая:

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

Как только это получается спокойно, встаёт следующий вопрос: как держать процесс безопасным в реальном репозитории — с понятным состоянием Git, разумными разрешениями и инструкциями проекта, которые не дают Claude работать на авось.