У 2026‑му інтеграція штучного інтелекту в IDE перестала бути «фічею для галочки» й перетворилася на повноцінний робочий шар над кодом. Один із тих, хто системно показує, як це виглядає в реальному розробницькому середовищі, — популярний техноблогер Tech With Tim. У великому гайді зі свого робочого сетапу він детально розібрав, як PyCharm працює з AI‑агентами, різними моделями та локальними LLM — від підключення Claude і GPT до Ollama та LM Studio.
Це не історія про ще один «чатик збоку», а про те, як IDE перетворюється на універсальний хаб для керування моделями та інфраструктурою навколо них.
Не лише JetBrains: IDE як універсальний AI‑хаб
Ключова ідея: розробник не має бути прив’язаний до одного вендора чи одного агента. У PyCharm AI‑шар побудований як відкрита система, де базовий JetBrains‑агент — лише опція за замовчуванням, а не обмеження.
У вікні AI Assistant користувач може обрати агентів на кшталт Claude Code, Codex або Junі і працювати з ними безпосередньо з редактора. Це знімає типову для багатьох IDE прив’язку до «рідного» AI‑сервісу. Наявний каталог агентів (через ACP‑директорію) дає змогу додавати сторонні рішення, а не чекати офіційних інтеграцій.
Таким чином, PyCharm виступає не як «оболонка для одного асистента», а як платформа, що дозволяє:
- обирати різні агентні обв’язки над моделями,
- комбінувати їх в одному проєкті,
- перемикатися між ними залежно від задачі.
Це важливо саме для професійних сценаріїв: команди й окремі інженери можуть експериментувати з різними агентами та не ламати при цьому основний воркфлоу в IDE.
Агент проти моделі: що тут насправді головне
Ще одне принципове розділення — між агентами та моделями. У класичному уявленні «модель = сервіс, з яким ви спілкуєтеся». У PyCharm усе інакше: модель — лише «двигун», а реальну поведінку визначає агентний шар над нею.
Агент описується як coding harness — спеціалізований набір інструментів, який запускає підлеглу модель і обгортає її додатковими можливостями. Власне LLM «просто перетворює текст у текст», тоді як агент:
- додає інструменти (від роботи з файлами до виклику MCP‑серверів),
- займається контекст‑інжинірингом,
- реалізує специфічну логіку взаємодії з кодом та IDE.
Claude, Codex, Juni у цьому підході — це не «ще одні моделі», а саме agent harnesses або model harnesses, які надають свої набори функцій і спосіб роботи з тією ж самою підлеглою моделлю.
Показовий момент: всередині одного агента (наприклад, Juni) можна вибрати модель GPT 5.5, а потім переключитися в агент Codex — і там теж використати GPT 5.5. Різниця не в моделі, а в harness або інфраструктурі навколо моделі. Одна і та ж LLM поводитиметься інакше, тому що:
- агенти по‑різному формують промпт,
- по‑різному керують інструментами,
- по‑різному організовують контекст.
Цим пояснюється знайомий багатьом ефект: дві різні IDE чи два різні AI‑асистенти «на одному й тому ж GPT» дають зовсім різну користь у реальному проєкті. У PyCharm це розділення винесено на рівень інтерфейсу: розробник явно обирає не просто модель, а поєднання «агент + модель».
Як IDE дозволяє обійтися без JetBrains‑кредитів
Для багатьох інженерів критичною є можливість контролювати, через чий тариф ідуть AI‑запити. PyCharm не зачиняє користувача в моделі монетизації JetBrains.
У налаштуваннях Providers and APIs можна переглянути, які агенти на що «підписані». Наприклад:
- Claude агент може працювати через JetBrains AI subscription,
- Juni повністю керується JetBrains‑обліковкою.
Та ключовий момент у тому, що розробник може підключити власний GPT‑акаунт. Достатньо залогінитися зі своїм ChatGPT (або відповідним обліковим записом), і далі будь‑яке використання піде через особисту підписку, а не JetBrains AI.
Це дає одразу кілька наслідків для професійного середовища:
- компанія може використовувати корпоративний GPT‑акаунт із власними політиками,
- не потрібно купувати додаткові кредити в JetBrains, якщо інфраструктура вже побудована навколо окремих AI‑постачальників,
- розробник не втрачає доступ до улюбленої IDE, навіть якщо JetBrains‑підписка обмежена, зате є оплачені токени в іншому сервісі.
Фактично PyCharm перетворюється на тонкий клієнт, який уміє маршрутизувати запити до різних бекендів, не втручаючись у фінансові чи облікові схеми компанії.
Від хмари до локалки: Gemini, Ollama, LM Studio та інші провайдери
Ще одна важлива грань — підтримка не лише хмарних, а й локальних та сумісних із OpenAI постачальників. У тих же налаштуваннях Providers and APIs доступна можливість додати:
- провайдери на кшталт Gemini,
- будь‑що сумісне з OpenAI API,
- локальні хости на базі LM Studio,
- локальні інстанси через Ollama.
Сценарій підключення локальної моделі виглядає доволі прямолінійно: у списку провайдерів обирається Ollama, вказується його URL, відмічаються потрібні функції — і після цього можна починати використовувати локальні моделі в AI‑чаті IDE. Аналогічно з LM Studio: PyCharm підключається до нього, і всі моделі, підняті там, стають доступними безпосередньо з редактора.
Це суттєво змінює картину для команд, які:
- працюють з чутливими даними й не можуть виводити код у хмару,
- тестують експериментальні локальні LLM,
- будують гібридну інфраструктуру, де частина запитів іде в хмару, а частина — на локальний GPU.
IDE в цьому випадку стає єдиною точкою входу, з якої розробник може непомітно для себе «перестрибувати» з хмарного GPT 5.5 на локальну модель в LM Studio, змінюючи лише налаштування провайдера.
Коли «агент важливіший за модель»
На практиці все це веде до доволі нетривіального висновку: у повсякденній роботі розробника різниця між моделями часто менш помітна, ніж різниця між agent harnesses.
Саме harness:
- вирішує, які інструменти підключати (MCP‑сервери, робота з Git, БД, файловою системою),
- структуровано підсовує моделі релевантний код,
- реалізує правила й скіли (рутини типу «як у цьому проєкті деплоїться сервіс»),
- адаптує поведінку моделі до конкретної IDE й стеку.
У результаті той самий GPT 5.5 під Juni всередині PyCharm буде поводитися не так, як під іншим агентом у сторонній системі. IDE‑інфраструктура додає «важку артилерію» у вигляді:
- правил, які завжди інжектяться в промпти,
- скілів, що документують та автоматизують повторювані воркфлоу,
- підключених MCP‑серверів, наприклад GitHub MCP для роботи з репозиторіями.
Саме ця надбудова робить AI інструментом професійної розробки, а не просто «розумним автодоповненням».
Висновки: IDE як фронтенд до вашої AI‑інфраструктури
Підхід, який демонструє PyCharm, показує, як може виглядати зріла інтеграція AI в робоче середовище програміста. Кілька принципів тут особливо помітні:
- агентний шар відділено від моделей, і саме він визначає характер взаємодії з кодом;
- IDE не нав’язує одного постачальника — можна використовувати Claude, Codex, Juni, власний GPT‑акаунт чи локальні LLM;
- PyCharm працює як універсальний фронтенд до AI‑інфраструктури: від хмарних API до локальних хостів, не руйнуючи звичний дебаг, навігацію та роботу з БД.
Для розробників це означає, що вибір IDE більше не зводиться до питання «чи є там AI‑підказки». Насправді ключове — наскільки IDE дозволяє керувати агентами, провайдерами й локальними моделями, не змінюючи інженерних практик. У цьому сенсі PyCharm показує приклад того, як можна поєднати класичний інструментарій професійної розробки з гнучким, але контрольованим використанням LLM у повсякденній роботі.
Джерело
How I Set Up Python for Professional AI Development — Tech With Tim