Хто такий АІ-коуч і чи потрібен він вашому проєкту

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Припускаю, що ця роль вже є у вашій команді, але називається інакше. Водночас можливо, що ви ще не до кінця усвідомили її потенціал.

Мене звати Олег Васильєв, я працюю в ЕРАМ Україна у ролі delivery менеджера і спеціалізуюсь на фінансових рішеннях. Маю понад 7 років технічного досвіду як інженер і техлід. У 2024 році у нас з’явилася нова роль — AI-коуч, і я вирішив спробувати себе в ній та розповісти про свій досвід.

Задачі та обов’язки

У різних компаніях ця роль може називатися по-різному: AI champion, AI ambassador, LLM enablement lead або prompt engineer — залежно від контексту і фокусу. Але суть залишається незмінною: це фахівець з технічним бекграундом, який просуває використання штучного інтелекту в команді, допомагає колегам ефективно працювати з AI-інструментами та слідкує за тим, щоб ці інструменти дійсно додавали цінність, а не просто створювали ілюзію автоматизації.

AI-коуч виступає наставником, інтегратором і провідником змін — він розуміє як технічну сторону (LLM, пайплайни, API), так і бізнес-процеси, з якими працює команда. Він закриває прогалини в навичках, пропонує практичні сценарії використання AI, допомагає адаптувати команду до нових підходів і водночас не дозволяє «зловживати» автоматизацією без розуміння задачі та результату.

Як AI-коуч я регулярно беру участь у щоденних мітингах кількох стрімів в межах проєкту — Java, C++ та .NET. Моя мета — вчасно помітити моменти, де інженери, тестувальники або аналітики витрачають забагато часу на рутинні задачі, які можна частково або повністю делегувати штучному інтелекту. Це можуть бути генерація шаблонного коду, створення технічної документації, аналіз логів, генерація тестів — ось лише декілька потенційних застосувань.

У моїй практиці були й глибші кейси застосування AI. Наприклад, ми створили універсальний промпт для генерації або оновлення FIX-словників, базуючись на специфікаціях конкретної трейдинг-платформи. Також у нас є власний фреймворк для тест-автоматизації з кастомним DSL, і ми реалізували кілька RAG (retrieval-augmented generation) промптів, щоб наші QA або навіть інженери могли автоматично генерувати тест-сценарії ще на етапі розробницького тестування.

Окремо AI допомагає з документацією — ми автоматизували форматування та наповнення ADR (Architecture Decision Record) на базі чернеток з наших технічних мітингів, а також створили промпти для генерації коду кількома мовами програмування на основі одного оригіналу. Це особливо актуально, коли функціональність спочатку пишеться однією мовою, а потім переноситься в інші. Скажімо, у вас є бібліотека на С++, але ринок також потребує її на .NET та Java.

Крім того, маємо серію RAG-промптів, які використовуються в підтримці продуктів — із вбудованими правилами перевірки, аналізу та структурованого виводу. Звісно, всі запити досить специфічні для кожного проєкту, тому мені здається, що немає сенсу наводити тут цих велетнів розміром в А4. Проте саме в цьому й полягає цінність ролі AI-коуча: не шукати щось банальне й універсальне, про що знає кожен, а знаходити справді корисні, точкові рішення, які приносять реальну користь команді та проєкту.

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

Як ви вже, мабуть, зрозуміли — я також веду базу промптів та метрик. Що саме я намагаюсь трекати:

Економія часу

Що це: фактичне скорочення часу на виконання задачі після впровадження AI. Це про реальну продуктивність: скільки годин або днів вдалося заощадити.
Як рахувати: порівняння старого часу виконання задачі (наприклад, 5 годин на аналіз логів) з новим (наприклад, 2 години з GPT).
Реальний кейс: спайки раніше займали стабільно від 3 днів — зараз 1 день.

Зменшення запланованого часу на типові задачі

Що це: зміни в оцінках тривалості задач — як команда почала інакше планувати час на типові задачі, коли з’явився AI. Це вже не про фактичне виконання, а про очікування.
Як рахувати: аналіз історії естімейтів у Jira для повторюваних задач (наприклад, «спайк», «документація» тощо).
Реальний кейс: середня оцінка необхідного часу на ADR-документ була 1 день, зараз — 2-3 години на базі чернетки з брейншторм-мітингу.

Частка документів, згенерованих за допомогою AI

Що це: який % документації створено (повністю або частково) зі штучним інтелектом.
Як рахувати: через тегування (наприклад, у Jira tasks: #genAI, #byChatGPT).
Реальний кейс: 75% реліз-нот, 80% юзер гайдів згенеровано з допомогою AI.

Рівень залученості команди

Що це: скільки учасників команди реально використовують AI у задачах.
Як рахувати: через опитування (банальний зворотний зв’язок під час ретро).
Реальний кейс: 8 із 10 розробників хоча б раз на тиждень звертаються до штучного інтелекту або використовують промпт-базу.

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

При цьому варто уточнити: всі ці метрики я веду для себе. Я не звітую по них перед клієнтом, не використовую для performance-оцінювання, не перетворюю AI на KPI. Це моя внутрішня аналітика, щоб бачити прогрес, розуміти, що працює, і краще масштабувати AI-підходи в команді. Це про усвідомленість і зростання — а не про контроль.

AI-коуч — це ще й про відповідальне використання інструментів

Окремий, але надзвичайно важливий аспект моєї ролі — це контроль за тим, щоб AI не став заміною розуміння, а був його підсиленням. Часом я бачу ситуації, коли розробник просто копіює згенероване LLM-рішення, навіть не намагаючись зрозуміти логіку. І саме тут AI-коуч повинен вмикати «червоне світло». Якщо в мене виникає підозра, що відбувається бездумне копіювання, я дію так:

• завжди запитую: «Чому саме так, а не інакше?» — провокую на пояснення результату;

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

• пояснюю ризики такого підходу, особливо в ентерпрайз-середовищі, де будь-який «лінивий» копіпаст може вилізти боком. І наголошую, що AI має допомагати думати, а не думати замість тебе;

• обожнюю наводити приклад, як один архітектор з боку клієнта в документації описав не Docker-контейнери, а морські — і абсолютно серйозно відправив цей текст на рев’ю (AI не перевіряє адекватність, він просто генерує).

AI — це не магія, і точно не «рішення для лінивих». Це інструмент, який розкриває потенціал команди, але лише тоді, коли використовується розумно.

І саме в цьому я бачу свою відповідальність як AI-коуча — не просто навчити натискати на кнопки, а виховати культуру, де AI — це не ярлик «замість», а партнер «поруч».

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

Які навички потрібні AI-коучу

На перший погляд може здатися, що для ролі AI-коуча достатньо «вміти користуватись ChatGPT». Але насправді ця роль набагато глибша — вона вимагає поєднання технічного мислення, аналітики, комунікаційних навичок і постійного оновлення знань.

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

• Знання сучасних AI-інструментів. Це не тільки ChatGPT. Це GitHub Copilot, ELITEA, Claude, Perplexity, Power Automate з AI-блоками, промпт-інженерія та багато іншого. Так, це вимагає часу — слідкувати за новинками, тестувати нові фічі, будувати власні сценарії. Але хороший AI-коуч не сприймає це як тягар — це його робоче середовище, яке він розвиває для себе і команди. Крім того, час від часу я проводжу воркшопи — ділюсь практичними кейсами з проєкту, показую нові ШІ-інструменти.

• Аналітичність і мислення через use cases. AI-коуч має приходити не з ідеєю «давайте щось заавтоматизуємо», а з чітким меседжем: «ось тут ми щотижня витрачаємо по 6 годин — ось як це скоротити до 30 хвилин». Бо в бізнесі кожна година — це гроші. І в ідеалі AI-коуч повинен мислити не лише як оптимізатор процесу, а як економіст часу=грошей.

• Комунікація та довіра. AI-коуч — це не роль «над командою», а навпаки — поруч із нею. Потрібно вміти пояснювати, показувати, навчати. Іноді доводиться працювати з опором. У мене були ситуації, коли хтось категорично не приймав ідею роботи з AI — і це нормально. Тут головне — не тиснути, не примушувати. Часто такі люди просто ще не бачили прикладів, де AI справді може зекономити час. Як тільки з’являється персональний кейс, де AI вирішив конкретну болючу задачу — ставлення змінюється. Треба просто почекати на такі кейси.

• Збір і фіксація знань. Я веду базу промптів + метрики: що спрацювало, що не спрацювало, які підходи були повторно використані. Це дозволяє не «винаходити велосипед» щоразу, а масштабувати вже успішні рішення.

Допомога бізнесу

З часом я зрозумів, що потенціал ролі AI-коуча значно ширший, ніж просто бути «асистентом» для делівері команд. Один із найяскравіших прикладів на моєму проєкті — автоматизація L1-сапорту.

Раніше перший рівень підтримки був переданий на аутсорс: зовнішня команда створювала тікети, проводила базову класифікацію інцидентів і за потреби передавала їх далі. Якщо йшлося про критичну проблему від важливого клієнта, L1 також передавали інформацію на L2-рівень. Вочевидь це коштувало грошей і точно не гарантувало ідеальної якості. Повсякчас траплялися помилки в класифікації, неправильне або неповне оформлення запитів (наприклад, у тікеті не вистачало ключової інформації, яку клієнт надав), а також звичайні затримки, які напряму впливали на якість сервісу.

Ми вирішили автоматизувати цей процес за допомогою Power Automate, Twilio та LLM:

• Налаштували обробку вхідних запитів через Power Automate flows. Уся система — повністю no-code: правила та логіку можна швидко змінювати.

• Додали інтеграцію з LLM, яка виконувала класифікацію запитів, витягувала ключові дані та формувала тікет. Ми також експериментували з тим, щоб LLM одразу пропонувала можливе рішення у коментарі до тікета, але пізніше прибрали цю функцію. Причина проста: користувачі дуже часто не надавали повної інформації, а реалізувати якісний gap-аналіз без повного контексту не вдалося.

• Всі тікети мали pass-логіку: після автоматичного створення тікет передавався на конкретного саппорт-інженера. Якщо інцидент був критичним і надходив від важливого клієнта — система запускала автоматичний дзвінок через Twilio на мобільний чергового інженера.

Результат:

• Повністю відмовилися від аутсорсингової L1-підтримки та скоротили витрати.

• Час обробки запитів значно скоротився, а бізнес отримав швидшу реакцію та більший контроль над якістю обслуговування. За нашою статистикою — LLM теж іноді помилялася, але суттєво рідше, ніж попередній L1-аутсорс. Якщо раніше ми мали до десятка інцидентів на рік, пов’язаних із помилками на першій лінії, то з LLM їх було всього два-три на рік. При цьому більшість помилок були викликані незвичним формулюванням або внутрішнім сленгом, який клієнти використовували у зверненнях.

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

Цей кейс навчив мене головному: AI-коуч — це не про «нову модну роль», а про реальний вплив. Це про те, щоб знаходити точки, де бізнес втрачає час і гроші, і закривати їх швидкими, розумними рішеннями. І таких спеціалістів недарма стає все більше: великі компанії вже вкладаються в AI-евангелістів та будують внутрішні спільноти. Світ зрозумів: AI працює не тоді, коли просто існує, а коли його правильно вбудовують у роботу через зміни процесів. Саме цим і займається AI-коуч.

Висновок: отже, AI-коуч — це must-have для сучасної ІТ-компанії?

Якщо коротко — так, але з однією умовою: ви справді хочете отримати цінність від штучного інтелекту, а не просто «спробувати модну штуку».

AI-коуч — це не «ще один фахівець у команді», а людина, яка здатна переосмислити процеси, поставити незручні запитання і знайти несподівано ефективні відповіді. Це той, хто не просто інтегрує GPT у ваш флоу, а змінює підхід до роботи: від рутин — до усвідомленого делегування, від шаблонів — до системного мислення.

І ні — не обов’язково робити це окремою посадою. Найчастіше AI-коуч — це роль з частковим завантаженням, яку бере на себе людина з команди: тімлід, менеджер тощо. Головне для такого фахівця — мати розуміння задач, довіру стейкхолдерів і команди та простір для дії.

Команда без AI-коуча може використовувати AI. Але команда з AI-коучем — навчається використовувати його правильно, відповідально і вигідно.

І поки інші лише експериментують — ви вже можете рахувати економію, прискорення і зростання якості.

Тож чи потрібен вам AI-коуч? Якщо ви хочете не просто йти в ногу з часом, а вигравати в цьому темпі — відповідь очевидна.