«Перевірку скоротили з 40 до 7 годин». Якими метриками ІТ-компанії міряють ефективність ШІ і де ще є проблеми
Українські IT-компанії розповіли DOU, як вимірюють ефективність своїх ШІ-інструментів, скільки часу заощадужують і де виникають труднощі з прийняттям ШІ. Індустрія поки що не має єдиного стандарту: компанії комбінують класичні інженерні метрики з новими ШI-показниками і лише поступово закривають «вимірювальний» розрив. Детальніше — в матеріалі.
Замість тижнів адаптації — кілька днів. ШІ для економії часу та ресурсів
Найбільш очевидним показником є зекономлений час. Компанії порівнюють тривалість виконання завдань вручну та за допомогою алгоритмів. Найбільш показові цифри демонструють не так програмісти, як операційні департаменти, де штучний інтелект бере на себе рутинну перевірку даних та адміністративну роботу.
Наприклад, у компанії Genesis автоматизували роботу відділу Compliance. Раніше менеджери головного офісу вручну переглядали сторінки з органічним контентом і рекламні креативи, щоб переконатися, чи відповідають вони правилам платформ. Нині цю роботу виконує система, яка аналізує матеріали та формує список «підозрілого» контенту, який має перевірити людина. За словами AI Engineer компанії Марка Мотлюка, система значно скорочує час перевірки дописів.
«Менеджери працюють тільки з тими кейсами, які модель позначила як підозрілі. Тільки на ШІ-інструменті для перевірки сторінок з органічним контентом ми досягли точності близько 90%. А ручний час перевірки скоротили з 40 до 7 годин на місяць на одного менеджера», — каже він.
У роботі з рекламними креативами економія часу ще більша — понад 60 годин на місяць на одного спеціаліста.
Схожу метрику використовують у N-iX для оцінки ефективності HR-процесів. Компанія автоматизувала створення профілів кандидатів, які раніше рекрутери готували вручну на основі резюме. Зараз документ генерується автоматично, а фахівець лише валідує результат. Head of AI & Engineering Excellence у N-iX Ярослав Мота каже, що це допомогло заощаджувати близько 150 годин щомісяця HR-команді.
Він додав, що компанія також відмовилася від найму додаткового співробітника, який мав відповідати за підготовку профайлів.
В EPAM вимірюють швидкість адаптації персоналу. Компанія впровадила інтелектуальну автоматизацію на базі платформи AI/Run, яка супроводжує нових співробітників та працює з базами знань. Завдяки цьому час адаптації нових розробників скоротився з кількох тижнів до лічених днів, заявляє AI Director в EPAM Вадим Власенко.
В Intellias фокусуються на використанні Agentic AI для прискорення прототипування та R&D. Головна мета — скоротити час від ідеї до створення MVP та швидше перевіряти гіпотези. Ефективність оцінюють через бізнес-метрики — Time-to-Market та ROI. Для оцінки саме агентних рішень компанія розробила власну систему метрик згідно з методологією Intellias IDEAbook В компанії кажуть, що результати пілотів показують, що в окремих кейсах виведення продуктів на ринок пришвидшується до 3 разів, а продуктивність зростає вдвічі.
У SoftServe успішність внутрішньої корпоративної асистентки SOFI оцінюють через пряме опитування користувачів. Головним досягненням вважають не загальну кількість запитів, яких станом на вересень 2025 року було майже 100 тисяч, а те, що 67% співробітників підтвердили реальну економію часу завдяки асистенту. Також важливим показником є динаміка аудиторії: за перше півріччя 2025 року інструментом скористалися 4230 співробітників компанії, а на кінець вересня — 5391.
Однак цей кейс підсвітив і проблему. Для коректної роботи алгоритмів контент мав бути структурованим, чого не вистачало в наявних базах. Команді довелося уніфікувати внутрішні матеріали та розробити спеціальний посібник з оптимізації контенту в SharePoint.
У MacPaw використовують нестандартну метрику, яку називають «фідбек на фідбек». Команда розробки внутрішніх інструментів запитує у замовників, наприклад сапорт-менеджерів, наскільки зручніше їм стало працювати з даними після впровадження ШI-системи.
Юлія Чорненко, AI Engineer у MacPaw, вважає рівень добровільного використання головним індикатором успіху:
«Іноді найкраща метрика — це коли люди справді починають активно користуватись ШI-інструментами у своїй щоденній роботі».
5 тисяч тестів на годину і 50 техінтерв’ю на день. ШІ для точності та зменшення дефектів
Швидкість генерування контенту чи коду не має сенсу, якщо вона призводить до помилок, які потім доводиться виправляти вручну. Тому другою важливою групою метрик є показники якості. Компанії використовують їх, щоб переконатися, що ШI не створює технічний борг і не пропускає критичні ризики.
У Sigma Software зробили ставку на автоматизацію QA. Інженери розробили інструмент Unit Test Generator, який інтегрується безпосередньо в CI/CD-пайплайни. Його продуктивність виміряли конкретними числами. За словами компанії, інструмент здатен генерувати до 5 тисяч тестів на годину з точністю близько 90%. Однак головною метрикою тут є не кількість тестів, а реальний вплив на стабільність продукту. Компанія використовує Impact Analysis Tool, який автоматично перевіряє, як новий код впливає на систему. І запевняє, що він дозволив скоротити кількість пропущених дефектів на 25% і зменшити час тестування на 20%.
В EPAM вимірювання якості виявило цікаву особливість, яку Власенко назвав «парадоксом якості». Внутрішні дані показали пряму залежність між наявністю контролю та кінцевим результатом. Там, де команди побудували жорсткі процеси перевірки коду, згенерованого штучним інтелектом, загальна якість продукту зросла. Там, де контроль був відсутній, компанія отримала технічний борг у «новій обгортці».
«ШІ підсилює систему: сильну команду робить сильнішою, слабку може зробити слабшою», — каже АІ-директор EPAM.
Також в EPAM вимірюють точність роботи ШI у внутрішніх HR-процесах. Система онбордингу нових співробітників на платформі AI/Run демонструє точність 95%. У компанії зазначають, що для багатьох конкурентних рішень на ринку цей показник становить близько 62%.
У Genesis підхід до якості базується на технічних метриках. Інженери використовують спеціальні датасети (evals), що складаються з реальних кейсів та очікуваних результатів. На них регулярно тестують моделі, щоб виміряти точність і частку помилкових спрацювань (хибнопозитивних і хибнонегативних результатів).
У N-iX якість вимірюють через повноту і точність підготовлених матеріалів. Наприклад, під час технічних інтерв’ю ШІ допомагає створювати звіти, що прискорює пошук співробітників. Максим Паламаренко, Head of Software Development Office, зазначає, що кількість технічних інтерв’ю може доходити до 50 на день. Через це створення звіту людьми могло займати години. Нині ШІ аналізує відповідність скілів кандидата вимогам вакансії, а людина лише перевіряє. Тут компанія застосовує принцип human-in-the-loop — жоден звіт не йде в роботу без перегляду людиною.
Код пишеться на 17% швидше. ШІ для інженерної продуктивності
Найскладніше питання в індустрії — як виміряти продуктивність розробника в епоху ШІ. Традиційні метрики обсягу, такі як Lines of Code (LoC), втрачають сенс, оскільки Copilot може згенерувати тисячу рядків за хвилину, але це не означає, що фіча готова. Тому українські компанії перейшли на комплексні показники DevOps (DORA) і аналіз взаємодії людини з інструментом.
В EPAM кажуть, що не вимірюють ШІ заради ШІ. Замість цього тут фокусуються на бізнес-результатах, використовуючи DORA-метрики — Lead Time (час від запиту до доставки), Cycle Time (час безпосереднього виконання завдання) і частоту деплоїв. АІ-директор EPAM Вадим Власенко зазначає, що у проєктах із високим рівнем впровадження ШІ продуктивність команд зросла в середньому до 30%. Він наголошує, що це число — не просто прискорення написання тексту програми, а комплексний показник, який враховує скорочення часу на рутинні операції, зменшення кількості переробок (% rework) і зниження витоку дефектів. При цьому вузькопрофільні фахівці поступово стають T-shaped.
«ШI взяв на себе рутину — шаблонний код, unit-тести, виправлення простих багів, код-рев’ю. Тож спеціалісти еволюціонують у T-shaped фахівців, зберігаючи глибину в основній експертизі, розширюють компетенції горизонтально: розуміють суміжні домени, можуть виконувати кросфункціональні завдання, фокусуються на архітектурних рішеннях і складній бізнес-логіці», — каже Власенко.
Як приклад наводить, що на деяких проєктах бізнес-аналітики без знання С++ тепер самостійно розбирають легасі-код. Це дозволяє не залучати додатково дорогих спеціалістів.
У Sigma Software аналізують, як саме інженери використовують асистентів. Компанія вимірює Acceptance Rate — відсоток коду, запропонованого штучним інтелектом, який розробник приймає без змін. Зараз, за їхніми даними, цей показник становить майже 30%. Це конвертується в конкретну економію: розробники витрачають на написання коду приблизно на 17% менше часу. Внутрішні пілоти
У GlobalLogic фіксують зростання ефективності у власному рішенні VelocityAI від 25% до 40% в останньому релізі. Проте головним результатом тут вважають культурний зсув. Орхан Гасімов, молодший віцепрезидент з технологій, стверджує, що індустрія спостерігає зародження нової культури розробки.
«Інженер переходить від ручного кодування до ролі архітектора та критичного верифікатора ШІ-згенерованих рішень», — каже Гасімов.
У N-iX зазначають, що ШІ бере на себе саме ту роботу, яку розробники зазвичай не люблять. Максим Паламаренко, Head of Software Development Office, каже, що такі завдання, як написання документації до коду та проєкту, починають зникати з радарів — вони вже значною мірою автоматизуються. Найбільший приріст швидкості компанія фіксує в написанні юніт-тестів чи процедурах код-рев’ю. Це звільняє час для архітектурних рішень, де людський інтелект все ще незамінний.
Короткі забіги + культурний опір. Де ШІ працює погано
Також ми запитали у компаній, які завдання поки що занадто ризиковано доручати штучному інтелекту або де ефективніше його не застосовувати.
У N-iX дійшли висновку, що штучний інтелект чудово створює прототипи (PoC), але не здатен підтримувати код на довгій дистанції.
«Верифікувати і виправляти „кілометри“ коду, який неконтрольовано згенереував ШІ, наразі дорожче, ніж переписати самому. Тому зараз найбільш ефективними є короткі ШІ-„забіги“ під контролем програміста», — Максим Паламаренко.
Схожий досвід мають Genesis, Intellias, Sigma Software, EPAM. Там ШІ добре працює на рутинних завданнях: згенерувати чернетку коду чи тестів, допомогти з документацією, підказати варіанти рефакторингу. Але щойно йдеться про архітектуру, нетривіальну бізнес-логіку, нечіткі вимоги чи ухвалення компромісних рішень, моделі дають нестабільний результат і потребують жорсткого контролю розробників. Компанії кажуть, що на цьому рівні ШІ — інструмент, а не автономний виконавець.
Останній, але не менш важливий фактор — людський. Ярослав Мота з N-iX виділяє упередження та страх втрати роботи як серйозні перешкоди. Співробітники часто сприймають автоматизацію як загрозу своїй кар’єрі, що сповільнює впровадження.
«Факт: жодної людини ми не звільнили через ШІ. Навпаки, люди витрачають менше часу на одноманітні задачі й більше — на складніші», — каже Мота.
В EPAM погоджуються, що культурний опір подекуди виявляється складнішим за технічну реалізацію, а управління змінами — важливішим за вибір платформи. АІ-директор компанії Вадим Власенко описав типову «пастку провалу», коли організація починає з гонитви за універсальною платформою, закладає бюджет ще до появи перших стабільних результатів у продакшені. Сильні, мотивовані команди показують «дивовижні кейси», але ці успіхи не масштабуються на решту організації.
Тому в компанії діють за принципом «спочатку production». Нові ШI-рішення запускають одразу в реальних умовах — з живим беклогом, бюджетом і конкретними термінами. Інфраструктуру розбудовують під середні команди, адже саме вони, за словами Власенка саме вони формують реальний рівень продуктивності.
У GlobalLogic звертають увагу, що навіть коли команди активно користуються ШІ-інструментами, приріст продуктивності може бути мінімальним. Як пояснює Орхан Гасімов, це пов’язано з тим, що для досягнення реального результату недостатньо просто почати використовувати технології та навчити людей.
Проблема часто криється в застарілих підходах, оскільки класичні процеси проєктного менеджменту та SDLC часто не розраховані на нові інструменти, тому потребують адаптації з боку менеджменту. Крім того, викликом стають самі технічні рішення, адже архітектуру часто доводиться змінювати, щоб ШI-агентам було простіше генерувати якісний код і тести.
