У новому великому розборі на каналі Tech With Tim автор показує, як перетворити хаотичне «vibe coding» з AI‑чатом у браузері на справжній професійний інженерний процес. У центрі — PyCharm як повноцінна IDE, глибоко інтегрована з AI‑агентами, базами даних, дебагером, MCP‑серверами та правилами для агентів. Це не про написання «коду будь‑що‑будь» з моделлю, а про те, як працювати як інженер, який відповідає за великий кодовий базис.
Коли AI вже недостатньо просто «підказувати код»
Відправна точка проста й жорстка: коли мета — стати професійним софтверним інженером, спосіб використання AI доводиться змінювати. Просте безкінечне «промптінг» моделі вже не працює як основний інструмент.
У професійному контексті виникають інші задачі. Потрібно заходити в код і реально його читати. Потрібно шукати визначення типів і функцій, розуміти, як пов’язані модулі. Потрібно запускати дебагер і дивитися на стан змінних у момент виконання. А коли модель ламається, генерує некоректний код чи конфігурації, все це доводиться виправляти руками — і для цього потрібен відповідний інструментарій.
Саме тут з’являється контраст між «vibe coding» у браузері та роботою в IDE. Професійний підхід, який демонструється в PyCharm, не покладається виключно на «cloud code» і відповіді моделі. Він поєднує AI з класичним набором інженерних засобів: повноцінним редактором, дебагером, профайлером, інтегрованою роботою з БД, Git, а також додатковими AI‑компонентами — MCP‑серверами, правилами та skills.
IDE як центр професійного AI‑воркфлоу
Серцевина підходу — перехід до професійної IDE, спеціально заточеної під Python. PyCharm тут розглядається не просто як «редактор з підсвіткою», а як середовище, що дозволяє зрозуміти й контролювати великий проєкт.
У типовому AI‑проєкті на FastAPI всередині PyCharm одночасно живуть:
- код, розбитий на модулі (schemas, repositories, database, маршрути API);
- середовище виконання й пакети, які можна переглядати та ставити безпосередньо з IDE;
- інтегрований перегляд структури файлів, типів і роутів;
- Git‑панель із гілками, комітами й дифами;
- інструменти для роботи з проблемами в коді, попередженнями та помилками.
Це «надбудова» над кодом, якої бракує при роботі в CLI або в простому редакторі. Вона дає змогу швидко переходити до визначень, переглядати типи, ловити помилки ще до запуску застосунку. І саме в цей екосистемний простір вставляється AI — не як зовнішній чат, а як інтегрований агент, який «бачить» структуру проєкту та працює в тих же межах, що й розробник.
Тут же підкреслюється: весь цей стек «не просто так». Різноманітні панелі, вікна структур, переглядачі БД і комітів існують, щоб полегшити життя саме у великих професійних проєктах, де просто «згенерувати ще трохи коду» вже недостатньо, а головне завдання — розуміти, що відбувається в системі.
Агент проти моделі: як AI вписується в інженерний процес
Окрема лінія — як саме у такій IDE використовується AI. У PyCharm це не просто один «бот», а система агентів та моделей.
Важливе розрізнення: агент — це не сама модель, а «хавнес» (harness), тобто оболонка навколо моделі. Модель лише перетворює текст на текст, тоді як агент додає:
- інструменти (skills);
- правила, що завжди інжектуються в контекст;
- інтеграцію з MCP‑серверами;
- контекстне інженеринг запитів, пов’язаний із IDE і проєктом.
У межах одного й того ж агента можна вибирати різні моделі, наприклад GPT‑5.5. Але той самий GPT‑5.5 у Juni, Codex чи іншому агенті поводитиметься по‑різному, оскільки змінюється саме «обв’язка»: які інструменти та контекст йому надають, як формуються запити.
На практиці це помітно, наприклад, у роботі агента Juni. Зазвичай він спочатку досить детально планує все, перш ніж просто стрибати в код. Такий підхід добре підходить для структурованих задач і великих фіч, але може відчутно збільшувати час до першої версії коду. У PyCharm навіть створюється окрема папка з планами — своєрідний вбудований spec‑driven підхід, який фіксує, над чим саме зараз працює агент.
У підсумку, AI у цьому воркфлоу — не автономний «кодогенератор», а учасник процесу, який:
- створює структуру проєкту;
- підлаштовується під наявні правила та skills;
- використовує додаткові інструменти через MCP;
- а далі передає контроль людині й класичним засобам IDE — дебагеру, тестам, переглядачам БД.
Тести, HTTP‑запити й база даних в одному середовищі
Один із ключових елементів професійної роботи — валідація того, що код реально працює. Тут PyCharm пропонує одразу кілька шарів.
По‑перше, для FastAPI при створенні проєкту автоматично з’являється файл test_main.http. Це не просто нотатки, а робочий інструмент, який дозволяє прямо з IDE надсилати HTTP‑запити до API, зберігати їх і бачити відповіді. Таким чином формується окремий файл із тестами для ендпоїнтів, де:
- зберігаються тіла запитів і заголовки;
- фіксуються відповіді у вигляді JSON;
- видно, який статус‑код повернувся, які дані реально створюються.
Це корисно, коли ендпоїнтів багато, і їх треба регулярно перевіряти, не стрибаючи між терміналом, браузером і якимись зовнішніми тулінгами.
По‑друге, у проєкті на FastAPI з локальною SQLite‑базою IDE дозволяє:
- вказати діалект SQL як SQLite;
- підключити сам файл бази даних як джерело даних;
- переглядати таблиці, індекси й рядки безпосередньо з PyCharm;
- запускати SQL‑запити в інтегрованому консольному режимі.
Після підключення БД зникають попередження на SQL‑рядках у коді, а IDE отримує змогу не лише підсвічувати синтаксис, а й реально виконувати запити та показувати вміст таблиць. Це особливо помітно при тестуванні CRUD‑операцій: розробник може відправити HTTP‑запит на створення книги, побачити JSON‑відповідь у test_main.http і тут же відкрити відповідну таблицю в переглядачі БД, щоб переконатися, що рядок з’явився.
Таке поєднання HTTP‑тестів та інтегрованої БД замінює розрізаний воркфлоу на «запустив — подивився лог у терміналі — відкрив інший тул для БД» і створює єдине контрольоване середовище всередині IDE.
Дебагер замість print: як розбиратися з помилками
Ще одна принципова межа між «vibe coding» і професійною роботою — спосіб налагодження. Придрук значень через print у логах тут прямо протиставляється використанню вбудованого дебагера.
У PyCharm дебагер працює нативно для Python‑проєктів. Сценарій виглядає так:
- У потрібних місцях ставляться breakpoints — червоні точки в «гуттері» біля номерів рядків.
- Застосунок запускається не в звичайному режимі, а в debug‑режимі.
- Поки код не дійшов до точки зупинки, все працює «як зазвичай».
- Коли виклик заходить у функцію з breakpoint’ом, виконання зупиняється, застосунок ніби «заморожується».
Далі IDE пропонує повний набір інструментів: перегляд усіх локальних змінних, стану об’єктів, їхніх полів, стеку викликів. Можна пошагово проходити кодом: «крокувати» по рядках, заходити всередину функцій або, навпаки, «перестрибувати» через них, виходити з поточного фрейму.
Практичний ефект відчутний навіть на невеликому FastAPI‑проєкті: коли HTTP‑тест запускає кілька ендпоїнтів, один із них «натрапляє» на breakpoint — і розробник в реальному часі бачить, наприклад, ID книги, об’єкт, що приходить із репозиторію, і те, як він трансформується перед поверненням у відповідь. Це той випадок, коли стає очевидно, чому застосунок «веде себе дивно» — замість того, щоб гадати по логах.
Найголовніше ж — дебагер стає звичним інструментом при роботі з великим застосунком. У такому режимі AI вже не «підміняє» собою розуміння коду, а допомагає скоротити дорогу до першої версії, після чого починається звичний для інженера цикл: тестування, дебаг, перегляд стану, виправлення, повторний запуск.
MCP, правила та skills: як формалізувати поведінку агента
На наступному рівні з’являється інфраструктура навколо AI‑агента. Мова йде про Model Context Protocol (MCP), правила (rules) і skills.
MCP‑сервери додають агенту зовнішні можливості. Показовий приклад — офіційний GitHub MCP‑сервер. Після додавання його в налаштуваннях PyCharm через HTTP‑конфігурацію й передачі йому GitHub personal access token агент отримує «інструменти» для роботи безпосередньо з GitHub. У підсумку досить у чаті попросити:
- створити новий публічний репозиторій;
- запушити весь код поточного проєкту;
- налаштувати віддалений origin для подальшої роботи.
І агент, користуючись MCP‑сервером, виконає це, а розробник зможе спостерігати, як у Git‑панелі IDE з’являються нові коміти, remote‑репозиторій і push‑операції.
Правила — ще один шар керування агентом. У PyCharm для них є окрема папка в проєкті. Кожне правило — markdown‑файл, текст якого автоматично додається до промпту при кожному зверненні до агента. Наприклад, можна створити правило з інструкцією: «Завжди коміть основні зміни в Git перед тим, як продовжити». Таке правило стає частиною «постійної пам’яті» агента щодо цього проєкту, а якщо папку з правилами закомітити в репозиторій, їх успадкують усі члени команди.
Skills — більш складні, але потужні сутності. Це повторно використовувані сценарії або інструкції, які агент може читати й за потреби виконувати. У PyCharm є вбудований Skill Hub, де можна:
- переглядати вже встановлені skills;
- встановлювати нові з каталогу (наприклад, skill із порадами з безпеки чи бекенд‑гайдом);
- імпортувати власні skills, додані в окрему директорію.
Агент може як користуватися заздалегідь встановленими skills, так і створювати нові на запит розробника. Наприклад, можна попросити: сформувати skill, який описує стек поточного проєкту — мову, фреймворк, основні бібліотеки. Агент створює markdown‑файл у директорії skills для конкретного агента, прописує там опис і зміст; надалі, коли його прямо або опосередковано просять уточнити стек, він читає цей файл і використовує його як «правду» про проєкт.
Разом MCP, rules і skills перетворюють агента з «розумної автодоповнювалки» на керований компонент інженерного процесу, з чітко окресленими можливостями, політиками й знаннями, які можна версіонувати разом із кодом.
Вихід із CLI та «чистого промптінгу»
У фіналі звучить дуже конкретна мета: показати, як налаштовується професійний воркфлоу, щоб розробники вийшли з CLI‑інструментів і режиму «просто промптити модель», і перейшли до роботи у повноцінній IDE з AI як інтегрованою частиною процесу.
Тут важлива не лише можливість «написати код швидше», а саме повний цикл: від генерації структури проєкту й маршрутизаторів до налаштування БД, тестування HTTP‑запитів, підключення MCP‑серверів, написання правил і skills, запуску дебагера й навігації по великому кодовому базису.
Професійність у цьому підході означає не те, що AI використовується менше, а те, що він використовується інакше. Модель перестає бути «чарівною чорною скринькою», яка сама «щось зробить», а стає співучасником інженерного воркфлоу, вбудованим у середовище, де головними інструментами залишаються розуміння коду, можливість дослідити його поведінку та керовані інструменти для зміни й налагодження.
Джерело
YouTube: How I Set Up Python for Professional AI Development