Восени 2025 року в MODUS X запустили внутрішню програму впровадження GitHub Copilot. Мета була проста: дати нашим розробникам інструмент, який прискорить рутинні операції, не жертвуючи якістю коду. Через 86 днів вимірювань у нас з'явилися конкретні цифри і не менш конкретні висновки про те, де AI-асистент справді працює, а де поки що залишається помічником зі своїми обмеженнями.
У чому виклик
Розробка програмного забезпечення для енергетики, державних сервісів і великих корпоративних клієнтів - це індустрія, де ціна помилки висока, а швидкість виходу нових функцій критична. Наша інженерна команда давно стежить за AI-інструментами для девелоперів, але переходити від інтересу до системного впровадження ми хотіли тільки після того, як зможемо чесно виміряти ROI.
Перед нами стояли три питання, на які треба було відповісти цифрами, а не маркетинговими обіцянками:
Наскільки реально пришвидшується розробка з AI-асистентом?
Чи зберігається якість коду при більшій швидкості?
Як виглядає окупність на масштабі команди?
Яке рішення
Ми побудували впровадження у вигляді поетапного проєкту разом із нашим партнером Microsoft. Архітектурно інтеграція охопила дві платформи, на яких живе наш код: Azure DevOps і GitHub Cloud.
Етап 1. Онбординг. Підключення команди до GitHub Enterprise, базові воркшопи GitHub Copilot Fundamentals, налаштування політик безпеки і доступу.
Етап 2. Вимірювання та ROI. Це для нас був ключовий етап. Разом із партнером ми побудували фреймворк збору метрик на базі GitHub API: кількість активних та залучених користувачів, обсяг прийнятих пропозицій, частка часу, заощадженого на типових задачах, оцінка фінансового впливу. Замість того щоб довіряти суб'єктивним відчуттям розробників, ми отримали дашборд, де видно реальну поведінку команди день за днем.
Етапи 3 і 4 ми продовжуємо вже власною командою: масштабування адопції, інтеграція в стандартні воркфлоу, кастомізація під специфіку проєктів.
Ключові KPI, які ми відслідковуємо на цих етапах: Developer satisfaction (задоволення розробників), Code acceptance rate (частка прийнятих AI-пропозицій), Time to completion (час до завершення задачі) та Code quality (якість коду). Цільові орієнтири на четвертому етапі: вийти на 80% активного використання серед ліцензованих розробників, 70% позитивного зворотного зв'язку від команди та 25% покращення ефективності code review.
Що говорять цифри
Ми стартували з 44 розробницьких ліцензій, що охопили 9 проєктів. За 86 днів вимірювань дашборд зафіксував усе — від кількості пропозицій до годин, перенаправлених у написання коду.
Базові показники:
64 752 пропозиції від Copilot за період вимірювання
753 пропозиції на користувача в середньому
80-90% показник залученості активних користувачів
16% середнього часу, заощадженого на типових задачах кодування
36,5% адопція серед розробників із ліцензіями
6,4% приріст загальної продуктивності
85 097 доларів прогнозованої річної економії на масштабі поточної команди
Останню цифру варто розшифрувати: це не "збережені гроші, які лежать на рахунку", а еквівалент часу, який команда отримала назад для нових задач замість того щоб витратити його на рутинні операції.
Де АІ зайшов найкраще
Найбільший і найочевидніший ефект ми побачили на юніт-тестах.
Один із наших бекенд-розробників пройшов із Copilot повний цикл написання тестів для внутрішнього мікросервісу електронного підпису. Його оцінка: процес прискорився на 40-50%, головне за рахунок початкових заготовок і стандартних сценаріїв. Copilot бере на себе генерацію структури тестів, базову логіку, ловить дрібні опечатки - людина залишається відповідальною за коректність, специфічні кейси і фінальну якість.
«Ми вже використовуємо AI в розробці не точково, а практично на всіх етапах SDLC: від валідації вимог і декомпозиції задач до реалізації функціональності, генерації тестів, code review, документації та аналізу якості. Для нас це відбувся перехід від простого пришвидшення рутинних операцій до AI-first engineering-підходу, де AI став не зовнішнім помічником, а частиною повсякденного інженерного процесу.
Але важливо підкреслити: цінність з'являється не від самого інструмента, а від зрілості команди й уміння правильно з ним працювати. AI суттєво посилює інженерів, які розуміють сильні та слабкі сторони сучасних AI engineering-інструментів, уміють покращувати skills агентів під специфіку проєкту, свідомо працювати з промптами й бачити, як навіть незначна зміна контексту може покращити або погіршити результат. При цьому критична перевірка коду, архітектурних рішень, безпеки та якості залишається відповідальністю людини.
Щоб розвивати цей підхід системно, у нас виділено AI Engineering SWAT-команду, яка аналізує, які інструменти, практики, prompts та agent skills справді працюють у різних delivery-сценаріях, а які потребують доопрацювання. Це дозволяє нам не просто впроваджувати AI «ширше», а проводити цілеспрямовані покращення, закріплювати успішні практики в інженерних стандартах і масштабувати їх там, де вони дають вимірюваний ефект.
Тому ми не розглядаємо GitHub Copilot та інші AI-інструменти як заміну розробникам. Для нас це спосіб повернути інженерам час для більш цінної роботи — архітектури, складної бізнес-логіки, якості продукту та результату для клієнта. Наступний етап — масштабувати AI engineering-практики в delivery-процесі там, де вони дають максимальний ефект»,.
— Artem Andrusenko, Head of Software Development, MODUS X
Де поки що результат не надто високий
Інший наш бекенд-розробник, який тестував Copilot на мобільному бекенді, помітив зворотну закономірність: великі загальні запити дають нестабільний результат. Якщо просити Copilot згенерувати тести "оптом" для великого класу, отриманий код часто потребує більше доробки, ніж якби його писали з нуля. Натомість дрібні точкові запити - "напиши тест на цей конкретний сценарій із такими вхідними даними" - дають стабільно хороший результат.
Той самий розробник зафіксував ще одну закономірність, яку варто розрізняти на рівні цілей проєкту. Якщо задача звучить як "швидко підняти відсоток покриття коду тестами", Copilot справляється з нею ефективно і за лічені години. Якщо ж мета - саме якісні тести, які реально страхують від регресій, то AI-асистент допомагає їх писати, але вже не настільки швидко: тут потрібні точкові запити, ручний рефакторинг і інженерне судження. Це означає, що метрика "coverage %" і метрика "test quality" - не одне й те саме, і Copilot прискорює їх з різною силою.
Це збігається з нашими спостереженнями на рівні всієї команди: AI-асистент не машина, що замінює інженерне мислення. Він посилює того, хто вміє декомпозувати задачу і формулювати конкретні запити.
Ще один напрям, який ми хочемо дослідити далі, - поведінка Copilot у Test-Driven Development. Гіпотеза: якщо тести пишуться першими і малими ітераціями, AI-асистент має давати ще кращий результат, ніж при ретроспективному покритті готового коду. Окремо цікаво, як він поведеться на інтеграційних тестах, де специфіка нашої архітектури має значно більшу вагу.
Що це все означає для бізнесу
Якщо узагальнити те, що ми побачили за ці 86 днів:
Економіка сходиться навіть при помірній адопції. 36,5% активних користувачів із ліцензіями вже дають 85 тисяч доларів річної економії. Чим більше команда розширює використання, тим швидше зростає крива ROI.
Якість не падає. Залученість на рівні 80-90% означає, що активні користувачі справді інтегрують Copilot у щоденну роботу, а не пробують один раз і забувають.
Найбільший виграш - там, де задачі рутинні та повторювані. Юніт-тести, бойлерплейт, стандартні сценарії, документація.
AI не замінює інженерів - він перерозподіляє їхній час. Ми бачимо, як зменшується частка некодувальних годин і зростає частка часу, інвестованого у власне розробку.
Що далі
Наступний етап для нас - вийти за межі поточних 36,5% адопції. План працює у три кроки:
Розширення. Активна робота з тими, хто має ліцензію, але поки не вийшов на повну адопцію: менторські сесії, обмін практиками всередині команд, кейси успіху від найактивніших користувачів.
Інтеграція в стандарти. Внесення AI-практик у наші код-рев'ю гайдлайни, онбординг нових розробників, документацію і шаблони промптів під специфіку проєктів.
Поглиблення метрик. Зв'язування метрик Copilot із бізнес-показниками: швидкість релізів, частота дефектів, час від коміту до продакшну.
Ми бачимо в AI-асистентах для розробки не разовий експеримент, а тривалу зміну в інженерному робочому процесі. І в цій точці нам важливіша не швидкість впровадження, а якість того, як ми вписуємо новий інструмент у вже зрілі процеси розробки.
«AI у розробці перестає бути експериментом і стає частиною інженерної операційної моделі. Питання вже не в тому, чи використовувати такі інструменти, а в тому, наскільки системно компанія може інтегрувати їх у процеси та перетворити приріст продуктивності на реальну бізнес-цінність. Разом із цим змінюється і структура інженерних команд: зростає цінність фахівців, які поєднують глибоку технічну експертизу зі здатністю ефективно використовувати AI, а team composition поступово зміщується в бік більш компактних і високопродуктивних команд».
— Олексій Вигодський, Practice Director, Enterprise Applications and Technologies, MODUS X
