FAVBET Tech: ШІ в розробці

85% розробників уже використовують ШІ в роботі. Це показують і світове опитування The Pragmatic Engineer 2025 року, і українське дослідження DOU 2024-го. Цифра вражає, але вона дуже загальна: хтось за допомогою ШІ кодить, а хтось лише відповідає на імейли. Ба більше, за даними DOU, лише 27% респондентів справді довіряють штучному інтелекту.

«Не довіряй і завжди перевіряй» – мабуть, найкращий девіз для роботи з ШІ. У цій колонці хочемо поділитися практиками, які допомагають інженерам використовувати ШІ так, щоб він дійсно оптимізував роботу, а не створював нові проблеми. Саме ці підходи ми досліджуємо разом з FAVBET Tech.

Що саме сьогодні робить ШІ для інженера

Перед написанням цієї колонки ми продивилися кілька свіжих досліджень про використання ШІ в software development (серед них і недавній огляд на arXiv). Перераховані нижче завдання – ті, що зустрічалися найчастіше.

Пише код

ШІ «провисає» там, де починаються складна бізнес-логіка або архітектурні рішення. Водночас з рутиною він справляється на ура, особливо якщо потрібні приклади роботи з новими бібліотеками:

На фронтенді за допомогою ШІ можна робити верстку сторінок, компоненти за макетами, адаптивну верстку чи інтеграцію UI-елементів.
На бекенді – генерувати CRUD-операції, API-ендпоїнти й SQL-запити.

Серед програмних продуктів донедавна лідирував ChatGPT, але зараз все популярнішим стає Microsoft Copilot. Єдине що, згенерований код все одно краще вичитувати: ШІ може не тільки губити контекст чи створювати неробочу нісенітницю, але й пропускати критичні вразливості. Це нещодавно виявило дослідження Veracode.

Рефакторить й оптимізує

Рефакторинг коду можуть робити як ChatGPT та Copilot, так й окремі інструменти чисто під це завдання. Наприклад, добре справляється плагін EM-Assist для IntelliJ – понад 90% інженерів дали на нього позивний відгук. Найбільше його рекомендували для таких завдань, як видалення дублікатів коду та методів, створення auto-format.

А от складні оптимізації все ще краще лишати людині. Codeflash нещодавно проводив експеримент і забракував дев’ять з десяти пропозицій по оптимізації від LLM. ШІ не бачить всю кодову базу та не знає контекст, тож часто змінює код так, що він виглядає «чистіше», а в результаті падає продуктивність або ламається бізнес-логіка.

Пояснює чужий код

Цей функціонал особливо зручний для онбордингу нових розробників. У Copilot Chat чи ChatGPT можна вставити фрагмент та отримати пояснення, що робить функція. JetBrains AI Assistant йде далі: він може розібрати SQL-запит чи регулярний вираз, пояснити помилку збірки чи скласти короткий summary для всього файлу.

Шукає та виправляє баги

Такі продукти, як DebuGPT, Diffblue та Codo, генерують тест-кейси, аналізують логи і знаходять прості баги. Наприклад, неправильні повідомлення валідації штучний інтелект відловить без проблем. А ось у кросбраузерному тестуванні чи тестах на реальних пристроях ШІ дасть лише часткову допомогу. Аналіз вимог, розробка сценаріїв і пошук складних помилок теж лишаються за інженерами.

Пише документацію

Найбільше це корисно там, де треба швидко закрити рутину: описати методи, оновити inline-коментарі або зробити коротке summary для онбордингу новачка. У JetBrains AI Assistant достатньо виділити метод, натиснути Write documentation – і система згенерує опис чи коментар. GitHub Copilot Chat уміє робити те саме для класів, API чи pull-requests. Є й вузькі сервіси на кшталт Diffblue чи DocuWriter, які генерують пояснення до тестів або API-ендпоінтів.

Допомагає з тасками і плануванням

У GitHub Copilot Workspace можна почати з issue, і система запропонує план змін: які файли редагувати, що протестувати. Розробник може відкоригувати цей план і запустити його виконання безпосередньо зі свого середовища.

Ще далі пішов Copilot Coding Agent: йому можна призначити задачу, і він сам згенерує зміни, запустить тести, відкриє pull request і покличе інженера на рев’ю.

Втім, тут теж є «але»: агент не завжди правильно інтерпретує вимоги чи контекст, а перевірка його пропозицій іноді займає більше часу, ніж якби розробник виконав завдання вручну. Власне, в нещодавньому дослідженні виявили, що ШІ може збільшити час виконання завдання аж на 19%.

Слідкує за продакшеном

Microsoft Azure AI-Ops вміє автоматично виявляти аномалії в телеметрії та логах, створювати алерти й навіть пропонувати варіанти фіксів. Dynatrace Davis AI аналізує мільйони подій у реальному часі й агрегує їх так, щоб зменшити кількість false positives. А Datadog Watchdog підсвічує підозрілі патерни у метриках і логах, автоматично попереджаючи про проблеми ще до того, як вони стають критичними.

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

Які результати бачать компанії та інженери

Подивімось на конкретні результати, які дає інтеграція ШІ в інженерні процеси.

В експерименті з розробниками, які мали написати HTTP-сервер на JavaScript, група з GitHub Copilot завершила завдання на 55% швидше, ніж контрольна група без асистента. Умови були лабораторними, але різниця вражає.

У бізнесі цифри теж починають вимальовуватися. SoftServe зафіксував, що з ШІ-інструментами продуктивність команд зросла на 45%, а час розробки проєктів скоротився майже на третину. А великий британський банк порахував економіку онбордингу: новий інженер виходив «у плюс» лише за 52 дні. Якщо скоротити цей час на 30% завдяки ШІ-асистентам, річна економія сягала б 7 млн фунтів. Цифри швидко переконали менеджмент у доцільності впровадження.

Є й інші показники. За даними Microsoft, 67% користувачів Copilot визнають, що інструмент допомагає їм фокусуватися на справді важливій роботі, а 71% – що він знімає рутинні й нецікаві задачі. Це напряму впливає на рівень вигорання: у дослідженні Harness 52% розробників назвали саме вигорання головною причиною звільнень колег, а ШІ допомагає знизити цей ризик, прибираючи монотонну роботу.

Але не варто вимірювати ефективність лише рядками коду чи кількістю закритих тікетів. Консультанти радять дивитися на DORA-метрики (частота релізів, час змін, рівень відмов і швидкість відновлення) або фреймворки на кшталт SPACE чи DevEx. Саме там найкраще видно, як ШІ змінює роботу команд – чи прискорює онбординг, знижує навантаження на рев’юерів і допомагає підтримувати стабільність коду.

Чи може ШІ замінити розробника

Заголовок навмисно маніпулятивний: ми всі знаємо, що відповідь – ні. Нижче розкажемо про причини.

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

По-друге, юридичні ризики. Навколо GitHub Copilot уже кілька років триває справа про порушення авторських прав: розробники звинувачували інструмент у тому, що він відтворює фрагменти open source-коду без атрибуції. Частину позовних вимог суд відхилив, але сама дискусія показує, що питання «хто несе відповідальність за ШІ-код» залишається відкритим. Microsoft навіть запровадив спеціальну програму Copilot Copyright Commitment, щоб зняти частину ризиків із клієнтів.

По-третє, відповідальність і культура. ШІ-асистенти не знають внутрішніх правил команди: стандартів безпеки, архітектурних принципів чи того, як саме тут проходить код-рев’ю. Вони можуть допомогти зі швидкими чернетками, але замінити культуру колективної роботи – ні.

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

Отже, ШІ може бути асистентом, але точно не інженером. Це хороший інструмент для пришвидшення рутинних завдань, однак відповідальність за продукт і рішення залишається за людьми.