ШІ в розробці: що працює, що ні та як отримати від нього користь

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

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

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

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

1. Пише код

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендації щодо інтеграції ШІ

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

1. Починайте із простого й видимого ефекту. Найкраще ШІ показує себе в онбордингу, автотестах і документації. Новачки швидше розуміють код, рутинні таски закриваються автоматично, а команда бачить результат уже з перших тижнів.
2. Вирівняйте ШІ з вашими стандартами. Якщо інструмент знає правила оформлення коду й архітектурні принципи, вичитка займає значно менше часу. Тут добре працюють внутрішні політики та інтеграція ШІ в pipeline.
3. Перевіряйте те, що справді важливо. Не кількість рядків коду чи тікетів, а метрики на кшталт DORA або SPACE. Саме вони показують, чи реально прискорилися релізи, чи зменшилася кількість багів, чи легше стало відновлювати сервіси після збоїв.
4. Будьте прозорими з командою. Люди швидко вловлюють, коли ШІ нав’язують зверху. Поясніть, що це інструмент для зменшення рутини, а не загроза їхнім робочим місцям. І починайте з пілотних команд: там простіше протестувати політики, зібрати фідбек і масштабувати далі.
5. Подбайте про безпеку. Використання відкритих моделей у фінансових чи державних компаніях може створити більше ризиків, ніж користі. У таких випадках варто дивитися на корпоративні версії Copilot, ChatGPT чи Anthropic, які вже враховують вимоги до захисту даних.

ШІ точно не забере роботу в розробників, але роботу змінить – і дуже швидко. Уже зараз Deloitte прогнозує скорочення витрат на інженерію на 20–40% найближчими роками. Розробник майбутнього – це не просто людина, що пише код, а радше диригент, який керує ШІ-системами, задає їм напрямок і перевіряє результат. Тож ті команди, які вже сьогодні навчаться працювати з ШІ як з партнером, матимуть відчутну перевагу завтра.

Більше про FAVBET Tech