ШІ змінює цінність розробки: що це означає для українського ІТ-сектору

Колонка Юрія Сивицького про вплив ШІ на ІТ-сферу: розробку, інтеграцію, супровід систем і цінність українських продуктів та послуг.

Штучний інтелект змінює те, як ІТ-команди створюють, впроваджують і підтримують цифрові рішення. Для українських компаній це можливість розвивати власні продукти, підвищувати якість послуг і швидше розв’язувати завдання клієнтів. Реалізувати її допоможе здатність поєднати інженерію, розуміння клієнта та відповідальність за результат.

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

Для українського ІТ-сектору це питання стратегії компаній, розвитку спеціалістів і того, за що клієнти будуть готові платити в наступні роки.

Коли певне завдання можна виконати швидше, його попередня трудомісткість перестає бути достатнім обґрунтуванням ціни. Замовник закономірно очікує скорочення строків, доступнішого рішення або більшого обсягу корисної роботи за той самий бюджет. Компанії доводиться точніше пояснювати свій внесок: яку проблему вона розв’язує, які ризики бере на себе і який результат забезпечує.

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

Швидкість роботи ІТ-команди має економічний сенс тоді, коли скорочує шлях до корисного результату.

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

Саме тут поєднуються продуктова й інженерна компетенції. Людина, яка розуміє лише бажаний інтерфейс, може не помітити критичного обмеження. Людина, яка бачить лише технічне завдання, ризикує якісно реалізувати невдалий процес. Команда має вміти перевіряти обидві сторони.

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

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

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

Висновок звіту DORA: розробка з підтримкою ШІ (2025) добре пояснює цей ефект: ШІ підсилює наявні сильні та слабкі сторони організації. Якщо компанія вміє визначати пріоритети, перевіряти якість і працювати зі зворотним зв’язком, нові інструменти допомагають їй. Якщо ці процеси слабкі, швидше виробництво здатне збільшувати обсяг переробок.

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

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

Дослідження вже фіксують відчутне прискорення окремих видів роботи. У дослідженні Microsoft Research: ШІ та продуктивність розробників (2025) об’єднано три польові експерименти за участю 4867 розробників. Доступ до ШІ-асистента дав у сукупності приблизно 26% приросту кількості завершених завдань. Ця оцінка стосується досліджених команд розробників; ефект для інших завдань і ролей потрібно вимірювати окремо. Проте ця метрика ще не відповідає на питання про довгострокову якість продукту, його використання чи прибутковість.

Для керівника це означає необхідність дивитися на весь цикл роботи. Скільки часу минуло від виявлення потреби до її задоволення? Скільки змін довелося переробити? Чи зменшилася кількість помилок у клієнта? Чи почали користувачі виконувати свою роботу швидше? Кількість згенерованого коду не замінює відповідей на ці питання.

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

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

Це також дає підстави переглядати комерційну пропозицію. Компанія може поєднувати розробку з аналізом процесів, інтеграцією, супроводом і вимірюванням ефекту. Оплата за результат потребує чітких домовленостей та розподілу відповідальності, але навіть у погодинній моделі корисно показувати клієнтові зв’язок між виконаною роботою і змінами в його бізнесі.

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

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

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

Діяльність Асоціації у цьому напрямі: Комісія з AI Software Ukraine.

Джерела та матеріали

Матеріали та джерела, використані у статті.

  1. DORA: розробка з підтримкою ШІ (2025) — dora.dev
  2. Microsoft Research: ШІ та продуктивність розробників (2025) — microsoft.com