Інтеграція з IDE: grounding і ревʼю

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 одразу видно: змінився лише потрібний метод чи зачеплено сусідні? Чи не внеслося форматування в півфайлу? Чи з’явилися зайві імпорти? Чи не пішов агент переписувати те, про що його не просили? Зміна читається не як абстрактний patch, а як частина живого файлу: сусідній код, стиль проєкту, чи вписується правка в оточення.

Запам’ятайте формулу: 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 працювати навмання.