Канадський розробник і автор каналу Tech With Tim у новому відео демонструє не «демо без багів», а свій живий робочий процес: як він будує з нуля AI‑сервіс для автоматичного створення відеошортів з довгих роликів. На прикладі цього проєкту він по кроках показує, як продумує продукт, добирає стек, готує середовище й веде діалог з моделями так, щоб ті реально допомагали будувати застосунок, а не генерували «красивий, але непридатний» код.
Чому планування важливіше за перший рядок коду
Розробник одразу задає рамку: він хоче показати «реалістичний і дуже прагматичний» підхід, щоб було видно, як досвідчений інженер «використовує ці інструменти, щоб швидко й ефективно щось побудувати». І з перших хвилин наголошує на тому, що більшість робить хибний крок — одразу стрибає до кодування з AI.
Перший етап його workflow — докладне формулювання того, що саме має бути побудовано і чому. Це звучить банально, але він вважає це ключовою причиною провалів у «AI‑кодингу». Перед тим як запускати модель, він витрачає помітний час на дослідження: переглядає вже існуючі вирішення, вивчає альтернативи, порівнює підходи й тільки після цього визначається зі стеком технологій та інструментами.
За цим іде робота з концепцією продукту: створюється високорівневий outline — приблизна архітектура, основні модулі, загальний флоу користувача. Лише коли ці речі зафіксовані, у справу вступає AI. Інакше, застерігає розробник, «ви просто стрибаєте й починаєте будувати рандомний продукт з AI», що майже гарантовано веде до розфокусування та хаотичних рішень.
У підготовчій фазі він навіть генерує коротку слайд‑презентацію ідеї, використовуючи окремий AI‑чат: описує задум, просить допомогти з дослідженням, добором інструментів і формуванням адекватного техстеку. Важливий момент — ця робота робиться не в IDE, а в окремому середовищі, де зручно зберігати довгі дослідницькі діалоги й повертатися до них з різних пристроїв.
Продукт як орієнтир: AI‑сервіс для шортів з довгих відео
Конкретна ціль проєкту — сервіс, який автоматично генерує шорти з довгого відео. Користувач завантажує стандартний горизонтальний ролик у форматі 16×9, а система повертає набір коротких вертикальних кліпів із титрами та оформленням, придатних для соцмереж.
Функціональні вимоги розробник формулює досить чітко. Сервіс має:
– розбирати повний ролик на логічні фрагменти, придатні для коротких кліпів;
– конвертувати горизонтальне відео у вертикальний формат, «рефреймити» кадр так, щоб обличчя спікера залишалося в центрі;
– додавати заголовки, підписи й капшени;
– видавати результат у форматі, придатному для стрімінгу, з можливістю завантаження.
Важливе спостереження, до якого він приходить під час попереднього дослідження: «простішою частиною цього застосунку» виявляється саме вибір моментів для кліпів. Тобто, взявши транскрипт, досить зрозуміло, які фрагменти тексту можуть стати окремими шортами. Справжня складність — у перетворенні цих абстрактних відрізків на готові до публікації кліпи.
Проблемним виявляється саме відеостек: як взяти потрібний таймкод, переконвертувати відео, додати субтитри, організувати стрімінг, завантаження й повторне завантаження, працюючи не з локальним скриптом, а в контексті веб‑застосунку. Усе це — «відеообробка і все, що з нею пов’язане», яка суттєво ускладнює задачу.
У результаті він чітко розділяє два домени: інтелектуальну роботу з текстом (вибір кліпів, генерування назв і підписів) та інфраструктурно‑медійний шар (транскрипція, трансформація відео, зберігання та подача контенту). Саме це визначає вибір інструментів.
Як формується стек: від транскрипції до веб‑інтерфейсу
Після аналізу задач розробник фіксує три базові сервіси, без яких проєкт не злетить.
Перше — система транскрипції. Для цього він обирає Whisper у виконанні одного з провайдерів, що дозволяє передати аудіофайл і отримати текст у відповідь. Це фундамент для всіх наступних кроків: саме текст використовується, щоб вирізати «сенсові» моменти з ролика.
Другий компонент — LLM‑модель для інтелектуальної роботи з текстом. Тут він спирається на Claude, яку використовує як «мозок», що обирає кліпи, формує таймкоди, вигадує заголовки й капшени. У його workflow це універсальний AI‑шар, який працює і в IDE через Cursor, і в окремому чаті для досліджень та планування.
Третій ключовий елемент — платформа для роботи з медіа. Він зупиняється на ImageKit, пояснюючи, що саме з її допомогою можна «перетворити будь-який момент на реальне відео». У ході роботи він користується можливостями сервісу з автоматичної оптимізації, ресайзу, кропінгу, трансформації, трекінгу обличчя в кадрі, а також URL‑трансформаціями для швидкого накладання потрібних обробок без додаткового коду.
Стек бекенду й фронтенду він теж фіксує на старті. Розробник «вирішує, що хоче веб‑застосунок» і обирає для цього Next.js. Це рішення він також попередньо обговорює з моделлю Claude, спільно доходячи висновку, що такий стек логічно відповідає вимогам проєкту.
Так формується цілісна архітектура: веб‑інтерфейс на Next.js, транскрипція через Whisper, семантична логіка й відбір кліпів на базі Claude і відео‑/аудіо‑інфраструктура, делегована ImageKit.
Контекст як паливо для моделей: довгі промпти, правила і Git
Коли базові рішення прийнято, розробник переходить до пристосування свого середовища розробки. Він працює в Cursor, під’єднуючи Claude як основну модель для генерації коду, і одразу налаштовує глибокий контекст.
Ключова деталь — він диктує в Cursor довгий голосовий промпт за допомогою інструменту Whisper Flow. У цьому промпті детально описує ідею застосунку, уже прийняті технічні рішення, обрані сервіси, способи їх використання та очікуваний результат. Далі просить модель створити «високорівневий план і архітектурний документ» і прямо вказує, щоб вона спершу поставила уточнювальні питання.
Цей початковий контекст фіксується у вигляді markdown‑файлів у репозиторії. Вони стають базовим орієнтиром для всіх подальших агентів і чатів усередині Cursor: незалежно від того, скільки вікон з моделлю він відкриє, система завжди може повернутися до цього опису й «пам’ятати», що саме будується і які рішення вже прийняті.
Далі починається налаштування інструментарію для агентів. Для сервісів, з якими працює застосунок (як‑от ImageKit), він підключає наявні agent skills і MCP‑сервери. Це дозволяє Cursor і моделям напряму взаємодіяти з API сервісу й читати документацію без ручного копіпасту.
Окремий крок — правила. Він додає GitHub MCP‑сервер і задає моделі правило: кожні суттєві зміни мають супроводжуватися комітом. Cursor створює окрему директорію rules і відповідний файл, який постійно підтягується в системні промпти. З цього моменту модель сама ініціює коміти після значимих правок, а репозиторій автоматично опиняється в GitHub.
Таке структурування дозволяє перетворити AI на передбачуваного співрозробника, який не просто генерує шматки коду, а працює в рамках узгоджених правил і архітектури, з чітко задокументованими залежностями та цільовим бекендом.
Реальність AI‑розробки: баги, неузгодженості й ітерації
З підготовленим середовищем розробник переходить до активної фази побудови застосунку: завантажує API‑ключі для сервісів, дає моделі завдання «почати билдити все на основі плану» і вмикає багатозадачний режим Cursor, який запускає кілька агентів паралельно.
На цьому етапі чітко видно, наскільки далекий реальний процес від ідеї «один промпт — готовий продукт». Частина підзадач виконується успішно: веб‑форма для завантаження відео працює, ролик потрапляє в медіабібліотеку ImageKit, відображається в інтерфейсі. Інші — ламаються. Наприклад, перший захід на транскрипцію призводить до помилки.
Замість того щоб мовчки чекати нового коду, розробник активно втручається в діалог із моделлю: копіює помилку, описує, на якому саме етапі вона виникає («відео завантажилося успішно, але транскрипція не працює»), і дає додаткові обмеження. Зокрема, він уточнює, що не хоче відправляти цілий відеофайл на транскрипцію, а має намір спершу перетворити його на чисте аудіо, щоб скоротити розмір.
Ці уточнення базуються не на абстрактному знанні, а на попередньому прочитанні документації сервісів. Він прямо каже, що впевнений у можливостях ImageKit — отримувати лише аудіодоріжку, робити рефреймінг, змінювати розмір, забезпечувати адаптивний стрімінг. Саме тому може сфокусувати модель: замість широкого «зроби транскрипцію» він описує конкретний очікуваний флоу.
Після декількох циклів «запуск → збій → уточнення → виправлення» застосунок починає працювати стабільніше. Завантажений ролик успішно проходить транскрипцію, модель генерує список потенційних кліпів, ImageKit віддає посилання на оброблені відео.
Однак проблеми не зникають повністю. Наприклад, на одному з етапів інтерфейс показує замість п’яти різних кліпів п’ять копій одного й того ж оригінального відео. Щоб краще пояснити збій, розробник робить скріншот інтерфейсу й додає його в чат із моделлю, супроводжуючи описом: трансформовані кліпи не були створені, потрібні паралельні трансформації з рефреймінгом, конвертацією у вертикальний формат і додаванням титрів.
Такий підхід — ще один важливий елемент його workflow: він активно використовує можливості моделей бачити зображення й відстежувати UI‑стан, а не обмежується текстовими описами помилок.
Зрештою, після серії дрібних виправлень сервіс генерує повноцінні короткі відео: з вертикальним кадром, який «слідкує» за обличчям спікера, із автоматичними мініатюрами, створеними на стороні ImageKit, і з вшитими субтитрами. Певні деталі ще вимагають полірування, наприклад позиція капшенів на екрані, але базовий продукт функціонує.
Наприкінці розробник підсумовує: від моменту ретельного планування й дослідження, через створення контексту та правил у Cursor, налаштування MCP‑серверів і agent skills, до ітеративного дебагу — весь цей процес виявився значно ефективнішим, ніж якби він просто «закинув модель у порожній проєкт» і намагався будувати все промптами по ходу.
Висновки: план, інструменти й контекст важать більше, ніж «магія» AI
Кейс побудови сервісу AI‑шортів оголює реальний характер сучасної AI‑розробки. Моделі не замінюють інженера, але суттєво підсилюють його, якщо дотримуватися кількох принципів.
По‑перше, довга й продумана фаза планування з дослідженням альтернатив, вибором стеку й формуванням архітектурного начерку — не зайвий формалізм, а умова того, що проєкт узагалі зможе завершитися.
По‑друге, моделі працюють якісніше, коли отримують насичений, структурований контекст: опис цілей, уже прийняті технічні рішення, список інструментів і обмежень. Цей контекст варто зберігати в проєкті у вигляді файлів і використовувати в усіх агентних сесіях.
По‑третє, справжня сили AI розкривається, коли він отримує прямий доступ до інструментів — API сервісів, репозиторіїв, документації — через MCP‑сервери й спеціальні «скіли», а не коли розробник виступає проксі, вручну копіюючи й вставляючи фрагменти коду та описів.
І, нарешті, по‑четверте, AI‑розробка — це завжди ітерація: баги, непорозуміння, неправильні припущення моделі. Важлива не їх відсутність, а те, як швидко й грамотно інженер формулює зворотний зв’язок, уточнює вимоги й коригує курс.
У цьому сенсі показаний workflow — це не «чарівна кнопка» для розробки, а реалістичний опис того, як досвідчений інженер інтегрує LLM‑агентів у свою щоденну роботу, щоб «швидко й ефективно» будувати нові продукти.