Ключові висновки

Контекст дорожчий за модель. Дві 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 році, ніж гонка за «найрозумнішою» моделлю без розуміння конвеєра.