У новому тривалому гайді розробник і автор каналу Tech With Tim показує не «демку з презентації», а свій реальний щоденний стек для AI‑кодингу. Він будує веб‑додаток із нуля, опираючись на Cursor, моделі Claude та MCP‑сервери, і по ходу детально демонструє, як правильно готувати середовище, щоб модель не просто дописувала функції, а працювала як повноцінний агент, що читає документацію, керує сторонніми сервісами й GitHub‑репозиторієм.
Ця частина розбору зосереджена саме на середовищі: чому обрано Cursor, як налаштовуються моделі, агентні режими, MCP та правила, і як це все разом породжує відчуття справжнього «AI‑співрозробника» всередині IDE.
Чому саме Cursor: моделі ті самі, а досвід інший
Базовий вибір автора — писати код у Cursor із моделлю Claude як основним «мотором» для проєкту. Для цього конкретного кейса він відкриває «агентне» вікно Cursor, обирає одну з актуальних фронтирних моделей Claude і вмикає розширений контекст, «щоб вона могла вмістити все, що нам потрібно для проєкту». Параметри на кшталт «fast mode», великого контекстного вікна та середнього рівня «thinking mode» він називає своїм робочим «sweet spot» для складних задач.
Ключовий мотив вибору Cursor формулюється максимально прямо: він використовує ті самі моделі, що й інші сервіси, але поводиться інакше.
Розробник пояснює, що випробував різні інтерфейси на основі Claude, включно з окремими середовищами на зразок Claude Code, а також інші кодувальні інструменти, але повернувся саме до Cursor. Причина — в «coding harness», який зробила команда Cursor. За його словами, хоч усі ці інструменти звертаються до однакових LLM, внутрішня обв’язка й те, як IDE керує запитами й контекстом, дає Cursor відчутну перевагу в стабільності та якості результатів.
Окремий шар — стратегія вибору моделей. Для побудови застосунку «з нуля» він прагне використати «будь-яку актуальну фронтирну модель Claude» і стверджує, що саме вона зазвичай «трохи краще» справляється зі складними зеленими полями: проектуванням, архітектурою, великими шматками коду. Для масових рефакторингів, виправлення повторюваних помилок або чисто UI‑правок він переключається на інші, швидші або дешевші моделі, але ядром системи залишається Claude в Cursor.
Інтерфейс, а не чатик: чому важливо «бачити код»
Хоч Cursor останнім часом активно просуває «агентні» вікна й окремі UI для спілкування з моделлю, автор свідомо обходить їх стороною. Він відкриває стандартну панель із файлами й розміщує чат агента праворуч, фактично перетворюючи його на ще одну IDE‑панель.
Його позиція доволі прагматична: йому «легше, коли він бачить код, який модель пише», а не просто спілкується у відриві від структури проєкту. Тому він залишає один агентний чат, працює саме в цьому вікні, дивиться на файлове дерево й диф‑зміни, а не «у новому агентному вікні, де ти просто чатуєш із моделлю».
Ця організація простору виявляється важливою і в наступних кроках — коли підключаються MCP‑сервери, agent skills і правила. Усі дії агента — від створення файлів до зміни конфігурації — видно у звичному IDE‑контексті, що полегшує перевірку та своєчасне втручання, якщо LLM «йде не туди».
Старт із плану: голосовий контекст як базовий артефакт
Першою реальною дією в новому репозиторії стає не написання коду, а формування плану всередині Cursor. Замість того, щоб вручну набирати довгі промпти, автор використовує окремий інструмент для диктування, який інтегрується з IDE: говорить у мікрофон, а текст автоматично з’являється у вікні агента.
У цьому початковому промпті він:
- описує ідею застосунку максимально детально (AI‑сервіс, що з довгого відео створює декілька шортів);
- перелічує всі ключові технологічні рішення, уже прийняті раніше (фреймворк, тип застосунку, вибір зовнішніх сервісів для транскрипції, LLM‑аналізу, відео‑та зображень);
- формулює вимоги до кінцевого результату (рефреймінг обличчя, перетворення формату, титри, стрімінг, завантаження/вивантаження тощо);
- прямо просить модель «створити високорівневий план і архітектурний документ» та «поставити всі необхідні запитання, перш ніж рухатися далі».
Він пояснює, що мета такого довгого голосового промпту — згенерувати стабільний контекст усередині проєкту. Модель створює markdown‑файли з описом архітектури та вимог, і ці документи стають джерелом правди для подальших агентних чатів. Коли розробник пізніше відкриватиме нові агентні вікна чи паралельні задачі, модель зможе повертатися до цього контексту і не «забувати» попередні рішення.
Отже, ще до того, як з’являється перший рядок бізнес‑логіки, середовище вже містить формалізований опис цілей і техстеку — щось на кшталт внутрішньої специфікації, написаної самою моделлю з голосових нотаток розробника.
MCP як місток до зовнішніх сервісів
Коли базовий контекст готовий, настає ключовий етап — підключення MCP‑серверів до Cursor. Автор описує це як «те, що він завжди робить, виходячи з того, які інструменти обрано для проєкту».
Йдеться не лише про ImageKit, із яким він працює в цьому кейсі, а загалом про сучасні фреймворки й сервіси, які пропонують агентні інтеграції. Він згадує, що «багато нових тулів — від фреймворків до різних сервісів — уже мають agent skills або MCP‑сервери», покликані пояснити моделі, як правильно ними користуватися. Це фактично стандартизовані «гучні інструкції» та інструменти, які дають агента API‑доступ до сервісу.
На прикладі ImageKit ця стратегія видно особливо чітко. На сторінці «Build with AI» сервіс надає одразу три типи ресурсів:
- agent skills;
- MCP‑сервери;
- звичайну текстову документацію.
Замість того, щоб самому вичитувати всі мануали й вручну передавати шматки доки в промпти, автор завантажує готові skills, які додають у Cursor набір «умінь» для агента. Після встановлення «Cursor отримує агентні скіли прямо від ImageKit», і модель починає розуміти, як викликати потрібні операції.
Наступний крок — власне MCP‑сервер. У документації наведений фрагмент конфігурації для cursor.mcp.json, який можна додати вручну. Замість копіювати файли, розробник просто дає інструкцію самій моделі в Cursor: «додай ці MCP‑сервери». Агенти в IDE редагують конфіг, після чого середовище просить перезапуску.
Далі задіяна стандартна команда командного палетера (Command/Control + Shift + P) із пошуком «MCP settings». Відкривши вікно налаштувань MCP, він бачить:
- доданий MCP‑сервер для ImageKit;
- уже раніше підключений GitHub MCP.
Для ImageKit він натискає «Connect», вставляє приватний API‑ключ і отримує підключений MCP‑сервер із переліком доступних tools. Тепер агенти Cursor можуть:
- керувати обліковим записом ImageKit;
- виконувати операції з медіаконтентом;
- звертатися до документації через публічний MCP‑інтерфейс.
У результаті IDE перетворюється на диспетчер, де LLM‑агент може не тільки писати код, а й взаємодіяти з віддаленим сервісом як із власним «бекендом», не вимагаючи від розробника ручного копіювання URL‑прикладів чи фрагментів API‑доків.
GitHub як агентна звичка: правила, що завжди в контексті
Ще один важливий елемент середовища — GitHub MCP‑сервер і система правил у Cursor. Після підключення ImageKit‑агентів автор просить модель:
- створити новий репозиторій;
- налаштувати проект так, щоб «завжди робити коміт після будь-яких суттєвих змін»;
- оформити це не як одноразову інструкцію, а як стале правило для всього проєкту.
Cursor у відповідь створює окрему папку rules і файл із описом цієї поведінки. З погляду моделі це не просто рядок із попереднього чату — правила автоматично інжектуються в кожен наступний промпт як частина системного контексту. Тобто агенти щоразу «пам’ятають», що:
- потрібно використовувати Git;
- важливі зміни мають закінчуватися комітами;
- цю політику не слід ігнорувати без явної вказівки.
Розробник підкреслює, що саме так він «додає ще один шар функціональності» до Cursor: перетворює разові інструкції на постійні звички агента. У підсумку навіть великі автоматичні зміни, ініційовані багатозадачним режимом агента, мають відобразитися в історії репозиторію.
Коли IDE стає хабом: ефект правильно підготовленого середовища
Після підключення MCP‑серверів, agent skills і правил Cursor уже знає:
- яку архітектуру реалізує проєкт і які технологічні рішення прийнято на старті;
- як користуватися конкретними зовнішніми сервісами (через MCP‑інструменти);
- як поводитися з Git і репозиторієм;
- що робити з помилками й новими вимогами (на це впливають і правила, і початковий контекст).
Це дає відчутний ефект у подальшій роботі. Коли виникають помилки — наприклад, некоректна спроба відправити повний відеофайл у сервіс транскрипції, — розробник просто копіює текст помилки та дописує коротке пояснення: що саме вже працює (завантаження відео), а що ні (транскрипція). Агенти, маючи повний набір інструментів ImageKit і розуміння архітектури, перебудовують пайплайн: наприклад, замість сирого відео відправляють тільки аудіо, яке ImageKit виділяє на льоту через свої трансформації.
Те саме стосується наступних етапів: генерації шортів, рефреймінгу обличчя, перетворення формату, додавання титрів. Завдяки MCP‑серверу агент може сам шукати в документації потрібні параметри трансформацій і застосовувати їх, а розробнику залишається перевіряти результат і вносити коригування вищого рівня (на кшталт «давай робити кліпи паралельно» чи «титри занизько, підніми їх у кадрі»).
У фінальній рефлексії він прямо порівнює два сценарії. У нинішньому варіанті, коли:
- спочатку було зроблено планування й вибір інструментів;
- контекст і вимоги зафіксовані в проєкті;
- підключені MCP‑сервери для потрібних сервісів;
- додані правила й GitHub‑агент;
усі фічі застосунку вдалося отримати за невелику кількість промптів, хоча й із типовими для AI‑кодингу ітераціями й дрібними багами. Без цього підготовчого етапу — без сервісних агентів, правил і зафіксованого контексту — процес, на його думку, зайняв би значно більше часу й міг узагалі не завершитися робочим продуктом.
Висновок: AI‑агент — це не чарівна кнопка, а правильно налаштоване середовище
Показаний у цьому кейсі workflow демонструє важливий зсув: ефективність AI‑кодингу визначається не лише якістю моделі, а тим, як інженер вибудовує середовище навколо неї. Cursor у ролі IDE виступає:
- планувальним центром, де голосові промпти перетворюються на архітектурні документи;
- агентним хабом, через який LLM керує MCP‑сервісами на зразок ImageKit і GitHub;
- органайзером правил, що задають сталі «звички» моделі — від комітів до стилю роботи з інструментами.
У цій конфігурації модель перестає бути просто «розумним автодоповненням» і наближається до ролі співрозробника, який може одночасно читати код, документацію й стан зовнішніх сервісів, а також підтримувати дисципліну в репозиторії. І хоча помилки нікуди не зникають, кожна наступна ітерація обходиться дешевше — не лише в токенах, а й у людській увазі.