Штучний інтелект уже є органічною частиною робочих процесів у багатьох компаніях. Проте для нетехнічних спеціалістів залишається питання: як використовувати АІ в процесах поза звичайним чатом з LLM і чи можна створювати цінність для бізнесу без навичок розробки?

Робота, яка взагалі не потребувала участі людини

Я не планував працювати з автоматизаціями. Ще навесні 2025 року я був Senior Motion Designer і робив те, для чого мене наймали: створював креативи.

Але була одна проблема.

Разом зі збільшенням запитів на креативи дедалі більше часу йшло не на творчість, а на супровідні технічні дії. Одного вечора я вкотре закінчував підготовку чергового креативу до запуску. Потрібно було перевірити файли, оновити документацію, зібрати версії та виконати ще кілька дрібних технічних дій. У якийсь момент я спіймав себе на думці, що витрачаю дедалі більше часу на процеси, які майже не потребують мого втручання.

Тоді й постало питання: якщо для цієї роботи не потрібна експертиза чи концентрація, то чи потрібна тут людина взагалі?

Як шукати рішення

Це стосувалося не лише мене. Наш юніт складається з 13 спеціалістів – дизайнери та креативні маркетологи – і кожен регулярно стикався з однаковою рутиною.

Я не ставив за мету створити нову позицію або змінити флоу всієї команди. Спочатку хотілося спростити задачі собі. І зробити я це мав із нульовим досвідом у розробці.

Варто бути чесним: «нульовий досвід» не означає, що я не торкався коду взагалі. Я використовував вайбкодинг: описував проблему LLM-моделі, яка генерувала код для інструментів під мої задачі – плагінів, скриптів і невеликих вебзастосунків. Тобто в класичному розумінні я не кодив, але пояснював інструменту потребу, вчився читати результат і розуміти, де код працює, а де ламається.

Спершу працював у знайомому ще з університету середовищі – Visual Studio Code, де за ШІ-агента правив плагін Cline з безкоштовними моделями. Усе помітно змінилося з виходом Gemini 3 Pro та заточеного під агентний кодинг середовища Google Antigravity. Іноді, щоб декомпозувати задачу й скласти логіку першого промпта, я спершу проганяю її через чат-боти Gemini чи ChatGPT – так мені самому ясніший алгоритм, і перший промпт для агента виходить влучнішим.

Перші спроби були хаотичними – рішення працювали раз через десять. Утім, брак технічного досвіду виявився не критичним. Знаючи процеси команди зсередини, я бачив на практиці, де ми буксуємо. Це знання виявилося важливішим за вміння писати код. Коли впирався в технічні обмеження, звертався по допомогу до колег-розробників.

Так зʼявилися перші оптимізації:

• автоматичне створення субтитрів;
• локалізація відео;
• генерація превʼю креативів;
• очищення проєктів у After Effects однією кнопкою.

Спочатку вони економили по кілька хвилин на окремих задачах. Коли таких автоматизацій стало більше, це помітили й колеги з інших юнітів – вони почали цікавитися, чи можна так само спростити їхні процеси. Тоді я зрозумів, що цінність не в окремих автоматизаціях. Значно важливішим виявився пошук вузьких місць у роботі команди.

Коли я почав витрачати більше часу на аналіз роботи команди й створення рішень, ніж на моушн-дизайн, автоматизації включили до моїх OKR. З ініціативи CEO ця функція виокремилася в нову роль – AI Workflow Engineer.

Тепер я працюю на перетині розробки й операційних процесів, а моє головне завдання – знаходити точки, де команда гальмує, і мінімізувати затримки за допомогою AI-інструментів.

Два кейси, які довели, що це працює

Головний інсайт останніх місяців: автоматизація має сенс лише тоді, коли вирішує довгострокову проблему. Ось два кейси, які це підтвердили.

Плагін для озвучок в After Effects.

Під час роботи над створення і додавання аудіоозвучки мені треба було виконати низку технічних дій: згенерувати файл, перейменувати версію, звірити дублікати, оновити документацію, імпортувати все в проєкт. Жодна не була складною, але кожна вимагала уваги й перемикання між контекстами. 

Я зробив плагін для After Effects, який генерує озвучку, веде документацію, перевіряє дублікати, присвоює назву та імпортує файл у проєкт. Флоу скоротився приблизно у 20 разів – з 5–10 хвилин до 15–30 секунд.

Трекінг work capacity.

Раніше всі члени команди вносили дані про свою роботу в Google Sheets. На це могло йти до 15 хвилин щодня на людину. Тепер дані автоматично збираються в Notion разом зі змінами статусів задач, і ми завжди маємо актуальну картину завантаженості без додаткових дій.

Наприкінці Q2 ми провели аудит перших результатів. Лише дві автоматизації, описані вище, вивільнили близько 21 години командного часу на місяць – це результат двох конкретних рішень, який вдалося точно виміряти. Це дозволило 5 моушн-дизайнерам створювати приблизно на 10% більше креативів на місяць (понад 900 проти приблизно 800).

Коли автоматизація стає марною роботою

Є пастка, у яку легко потрапити, щойно зʼявляється смак до автоматизації: починаєш покращувати все, що бачиш, лише тому, що це можливо.

Одного разу ми взялися за повноцінний workflow для генерації відео з чернетки ідеї. Технічно все працювало. Система автоматизувала й помітно прискорювала продакшену. Та за тиждень, поки тривала розробка, бізнес-пріоритети змінилися – зник запит, який ця система мала закрити. У нас лишився функціональний, але нікому не потрібний інструмент.

Саме тоді я зрозумів: автоматизація сама по собі не має цінності. Якщо вона не привʼязана до актуальної бізнес-потреби, навіть найкрасивіше рішення – просто технічна вправа.

Після цього флоу змінився кардинально. Раніше я сам вигадував, що варто оптимізувати, і брав завдання в роботу по ходу їх появи. Погодити ідею з тімлідом було більш ніж достатньо. Тепер потік запитів постійний, і на перший план виходить пріоритизація й уміння відмовляти в зайвій роботі.

Кожну пропозицію я пропускаю через кілька фільтрів:

• чи доцільно це зараз із точки зору бізнесу;
• чи буде результат у короткій / середній / довгостроковій перспективі;
• чи суттєво зміна вплине на суміжні процеси;
• чи заощадить вона команді час, гроші та ресурси.

Рішення лишається за мною, але тільки після рисерчу й узгодження з усіма залученими командами.

Чого мене навчив цей досвід

Якщо стиснути весь цей досвід до кількох тез, вийде приблизно таке:

• Теза 1. Автоматизувати варто не найскладніші задачі, а ті, які повторюються найчастіше й сумарно забирають найбільше часу.
• Теза 2. Проблема має бути стабільною. Якщо бізнес-пріоритет може змінитися через кілька тижнів, є ризик витратити ресурс на розробку рішення, ніж отримати користі.
• Теза 3. Брак технічного бекграунду – не критичний. Важливіше розуміти, де саме команда втрачає час і фокус.
• Теза 4. Безкоштовні лекції від авторів AI-продуктів, з якими працюєте – база, з якої починається перше рішення.
• Теза 5. Будь-яку автоматизацію потрібно вимірювати. Якщо немає зрозумілої метрики до і після впровадження, складно оцінити її реальну цінність для бізнесу.

Разом ці правила зводяться до однієї простої ідеї: технологія тут вторинна, первинне — розуміння того, де саме команда втрачає час.

Висновок

Я починав цей шлях не з бажання створити нову роль. Мені просто хотілося позбутися задач, де людський компонент був несуттєвий. Згодом стало зрозуміло, що саме в таких щоденних подразниках часто ховаються можливості для змін.

Найбільше цей досвід змінив те, як я бачу власну роботу. Раніше я вимірював свою цінність кількістю креативів, які зробив особисто. Тепер – тим, скільки часу й ресурсу повертаю команді.

І головне: жодне з цих рішень не зʼявилося б в ізольованій innovation-команді. Їх бачать лише ті, хто щодня працює всередині процесу. Іноді достатньо дати такій людині шанс – і спроба заощадити кілька хвилин перетворюється на нову функцію, спеціалізацію або підхід до роботи всієї компанії.