Канадський розробник і автор каналу Tech With Tim показує не черговий «демо‑чудо» ШІ, а свій реальний робочий процес: як змусити велику мовну модель у Cursor поводитися не як чат‑бот, а як керований інженер‑агент. У центрі — не стільки сам застосунок для AI‑шортів, скільки спосіб роботи: довгі голосові промпти, початковий архітектурний контекст, правила для git‑комітів і відладка через знімки екрана.
Диктувати, а не друкувати: чому голосовий промпт важливий
Перший крок у його workflow — не код, а детальний опис задачі. І робиться це не руками на клавіатурі, а голосом.
Розробник відкриває Cursor, створює нову папку й одразу запускає довгий початковий промпт. Але набирати кілька абзаців технічного опису незручно, тому він використовує інструмент Whisper Flow, який працює на комп’ютері й інтегрується з Cursor. Він просто говорить у мікрофон, а все сказане миттєво перетворюється на текст.
За його словами, це «очевидно робить увесь процес значно швидшим» і це саме те, що він «рекомендував би використовувати». Whisper Flow вміє навіть «тегати» файли всередині Cursor, тож голосова диктовка стає повноцінною заміною ручного набору.
Уже в першому голосовому промпті він не обмежується загальною ідеєю на кшталт «зроби сервіс для шортів». Звучить повністю сформульована постановка задачі: який формат відео на вході, що з ним треба зробити, на якому фреймворку будувати веб‑застосунок, які саме зовнішні сервіси використовувати для транскрипції, аналізу тексту й відеообробки, де мають відбуватися рефреймінг, субтитри й стрімінг.
У результаті перший промпт виходить довгим, але саме цього він і добивається: одномоментно «вивантажити» з голови архітектурні рішення й очікуваний флоу, не розмазуючи їх на десятки дрібних чат‑запитів.
Початковий контекст як архітектурний документ
Після запуску цього промпту Cursor починає генерувати план і ставити уточнювальні запитання. Це не випадковість, а свідомо закладене правило: в базовому промпті він завжди просить модель спочатку розпитати його.
Він формулює це чітко: у початковому промпті «завжди рекомендуєте моделі: “постав мені кілька запитань”». Cursor тепер дозволяє відповідати на ці питання безпосередньо в інтерфейсі агента, що перетворює першу сесію на невелике інтерв’ю, де уточнюються нюанси флоу, обмеження й бажані рішення.
Але ключова мета цієї фази — не просто «поговорити з ШІ», а створити артефакт, який житиме разом із проектом. Він прямо пояснює, що намагається дати моделі «початковий контекст», з якого можна «почати генерувати» й мати «markdown‑файли в нашому застосунку… які ми можемо використовувати фактично завжди й у різних чатах». Коли він відкриватиме нові сесії агента або паралельні чати, модель «завжди зможе повернутися до цього початкового контексту й зрозуміти, що це за застосунок і які рішення ми вже ухвалили».
Таким чином, перший великий промпт перетворюється на локальну документацію: архітектурний опис, карта інструментів, домовленості щодо стеку й цілей. Модель не щоразу «вгадує», чим ви займаєтеся, а опирається на єдиний джерело правди всередині репозиторію.
Змушуємо агента запитувати й створювати структуру
Після того як базовий контекст сформовано, починається налаштування агентного середовища. Він вибирає модель, увімкнувши великий контекстний вікно, і пояснює, що вважає Cursor кращим за інші інтерфейси до тих самих моделей завдяки власному «coding harness».
Але принциповий момент тут — як він від самого початку формує поведінку моделі. Окрім прохання ставити питання в стартовому промпті, далі він одразу просить агента створити високорівневий план і «архітектурний документ» для застосунку. Ці файли зберігаються в проекті й постійно використовуються в наступних промптах.
Такий підхід змінює характер взаємодії: модель не просто «дописує функції», а починає з проектування, структурує роботу й повертається до початкового плану в разі сумнівів. Це ближче до поведінки інженера, який спочатку малює схему, а вже потім пише код.
Git як правило, а не рекомендація
Окрема лінія в його workflow — примусове використання Git через MCP‑сервери. Після того як з’явився початковий контекст і план, він переходить до налаштування інфраструктури й прямо каже, що «настійно рекомендує додати Git MCP‑сервер, GitHub MCP‑сервер, щоб він міг створювати репозиторії для вас».
Далі він дає агенту конкретну задачу: «створити для мене новий репозиторій і почати налаштовувати проєкт так, щоб ми завжди робили коміти, коли вносимо суттєві зміни, щоб можна було відкотитися в майбутньому». І додає: «додайте це як специфічне правило для цього проєкту».
Цей момент важливий: вимога комітити після кожних великих змін оформлюється не як разова інструкція, а як правило, яке має діяти завжди. Він використовує можливість Cursor створювати окремі «rules» — спеціальні файли, які щоразу потрапляють у промпт моделі.
Cursor генерує папку з правилами і файл, де зафіксовано, що після великих змін потрібно автоматично робити Git‑коміт. Далі, працюючи над кодом, розробник уже не мусить нагадувати агенту про це: модель «завжди знає», що так треба чинити. У підсумку весь код опиняється в репозиторії GitHub саме завдяки тому, що ці правила були закладені на старті.
Це ще один крок до моделі як інженера: Git‑дисципліна вбудована в її поведінку, а не залежить від настрою користувача.
Правила Cursor як постійний «системний контракт»
Git — не єдине, що потрапляє в набір правил. Паралельно з налаштуванням MCP‑серверів і агентних скілів він створює ще один тип правил у Cursor — ті, що завжди додаються до промпту.
Він пояснює, що «Cursor має можливість генерувати правила… Правила — це те, що завжди буде додаватися до промпту». Після його інструкції Cursor створює окрему папку й rule‑файл, який задає сталі вимоги до поведінки моделі в цьому проекті.
Фактично це локальний аналог системного промпту, але прив’язаний не до облікового запису користувача, а до конкретного репозиторію. Саме сюди можна виносити будь‑які постійні очікування: як працювати з Git, які MCP‑сервери використовувати, які кроки вважати «великими змінами», які стилістичні або архітектурні домовленості слід дотримуватися.
У підсумку модель щоразу отримує не тільки поточний запит, а й цей «контракт» проекту, який змушує її мислити в рамках заданого процесу, а не щоразу вигадувати свій.
Людина в циклі: читати, втручатися, направляти
Навіть із добре налаштованими правилами й MCP‑серверами розробник не сприймає агента як повністю автономного. Він уважно стежить за тим, що модель робить у реальному часі, і регулярно втручається.
У момент, коли система переходить до транскрипції відео, він помічає, що агент імовірно намагається відправити на сервіс весь відеофайл, замість витягти з нього лише аудіо. Логіка моделі йому не подобається, і він прямо каже, що «те, що вона намагається робити, схоже, не має сенсу». Далі він одразу додає уточнення: треба спочатку конвертувати відео в чисте аудіо й уже його відправляти на транскрипцію.
Він підкреслює, що під час роботи «є помилки, є проблеми» й що він «насправді читає, що модель каже, щоб зрозуміти, що вона робить, і дивиться на різні виклики інструментів». Часто так вдається «дуже швидко вловити, якщо вона збирається піти не в тому напрямку, і негайно втрутитися».
Це критична деталь його workflow: агент сам по собі не «магічний». Людський контроль за логікою, яку модель застосовує, і оперативна корекція — обов’язкова частина процесу. І саме вони роблять використання багатих агентних можливостей безпечним і продуктивним.
Відладка через скріншоти: коли моделі потрібно «побачити»
Коли перша версія застосунку вже працює, але результати далекі від бажаних, у хід іде ще одна цікава техніка — надання моделі знімків екрана.
На певному етапі інтерфейс починає показувати не трансформовані шорти, а просто той самий вихідний ролик, продубльований кілька разів. Розробник вирішує не тільки описати проблему словами, а й буквально «сфотографувати» екран: робить скріншот і додає його до промпту.
Він каже, що «вважає це надзвичайно корисним», бо моделі «можуть фактично бачити, що на UI». Навіть якщо агент теоретично й так має доступ до стану інтерфейсу, він усе одно надає зображення та підкреслює потрібні місця, щоб виділити суть проблеми.
Далі йде детальний опис: транскрипція працює, але «ми не згенерували жодного трансформованого кліпу… Зараз ми просто маємо оригінальне відео, яке показується п’ять разів». Він формулює бажану поведінку — потрібні п’ять різних кліпів, згенерованих паралельно, із доданими субтитрами, рефреймінгом обличчя та переходом до вертикального співвідношення сторін. Це «знову ж таки трохи деталей, щоб модель розуміла, що нам потрібно зробити».
У результаті після кількох ітерацій кліпи починають генеруватися правильно: рефреймінг працює, можна завантажувати й перегенерувати ролики, з’являються прев’ю, а потім — і вшиті субтитри. Те, що могло б перетворитись на довге пояснення верстки, вирішується кількома промптами з прикріпленим скріншотом.
Підсумок: як перетворити LLM на системного учасника команди
До кінця роботи над застосунком процес виглядає не як «чарівний автогенератор коду», а як досить буденна, але системна співпраця з агентом.
Спочатку проводиться глибоке планування й вибір стеку. Потім у Cursor створюється контекст: опис цілей, функціональних блоків, зовнішніх сервісів і очікуваних флоу. Далі налаштовуються MCP‑сервери й агентні скіли для роботи з інструментами, вводяться правила — у тому числі обов’язкові git‑коміти, — які завжди підтягуються до промпту.
Після цього починається ітеративна робота: запуск мультиагентного режиму, моніторинг викликів інструментів, своєчасні втручання, корекція помилок, а на етапі UI‑відладки — додавання скріншотів і точних вербальних вимог до того, як саме мають виглядати результативні кліпи.
У підсумку, за його оцінкою, вийшло побудувати повноцінний застосунок з кількома великими промптами й невеликою кількістю додаткових звернень, саме завдяки тому, що інфраструктура для агента — контекст, правила, MCP‑сервери, Git‑дисципліна — була продумана й налаштована заздалегідь.
Це й є головна відмінність між «погратися з LLM» і реально включити її в інженерний процес: модель перестає бути просто інструментом для автодоповнення й починає працювати як керований член команди з чіткими обов’язками, контрактами й зрозумілими межами автономії.