Copilot написав це, але кому це належить? Проблема управління, яку інженерні команди можуть проґавити

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

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

ШІ та кодування стає неминучим

Інструменти кодування на базі ШІ швидко набирають популярність і проникають у масове розроблення. За даними опитування розробників Stack Overflow 2025 року, 84 % респондентів вже використовували або планували використовувати інструменти ШІ у своєму процесі розробки.

Хоча впровадження ШІ у робочі процеси веб‑розробників стає більш поширеним, все ще існує сумнів щодо його надійності. Той же опитування виявив, що 46 % не мали повної впевненості у точності результатів ШІ, а приблизно 66 % зазначали, що рішення ШІ «майже правильні, але не зовсім», що викликає розчарування.

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

ШІ руйнує зв’язок між годинами та результатом

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

Контрольний експеримент за участю 95 розробників виявив, що учасники, які мали доступ до GitHub Copilot, виконали конкретне завдання створення JavaScript HTTP сервера на 55,8 % швидше, ніж ті, хто не мав доступу.

Це підкреслює, що ШІ може прискорити розробку, можливо, без втрати якості. Однак ці показники успішні лише тому, що експеримент базувався на дуже специфічному програмному завданні. Хоча завдання було виконано швидше, це не означає, що Copilot робить всю інженерну організацію на 55,8 % продуктивнішою.

Інше дослідження ілюструє цю ідею. випробування за участю 96 штатних інженерів-програмістів Google виявило, що розробники, які використовували ШІ, виконали завдання корпоративного рівня приблизно за 96 хвилин, у порівнянні з 114 хвилин у тих, хто його не використовував. Скоригована оцінка дослідників вказувала на приблизне скорочення часу виконання на 21 %. Однак дослідження не вивчало якість коду, створеного ШІ, і не розглядало питання справедливості щодо залежності від технології.

Існує також доказ того, що ШІ уповільнює час кодування. рандомізоване дослідження METR залучало 16 досвідчених розробників з відкритим кодом, які працювали над 246 реальними проблемами у репозиторіях, які добре знали. Використовуючи інструменти, доступні на початку 2025 року, включаючи Claude Sonnet 3.5 і 3.7, а також Cursor Pro, вони витратили приблизно на 19 % більше часу на виконання завдань, хоча багато хто очікував, що ці інструменти заощадять час.

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

Проблема ціноутворення, про яку ніхто не говорить

Модель «Час та матеріали» (T&M) є поширеною у веб‑розробці для придбання програмного забезпечення, оскільки вона вирішує постійну галузеву проблему: проєкт, що постійно розвивається.

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

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

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

У міру того, як ШІ змінює продуктивність інженерії, питання може змінитися з:

«Скільки коштує година розробника?» → «Що трапляється з вартістю, коли потрібно менше годин розробника?»

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

Проблема управління має чотирьох власників

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

1. Кому належить код?

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

2. Кому належить ризик?

Швидший код має цінність лише тоді, коли він не створює проблем в інших місцях. емпіричне дослідження коду, створеного ШІ виявило уразливості безпеки у 29,5 % розглянутих фрагментів Python та 24,2 % фрагментів JavaScript. Дослідження також виявило уразливості, що охоплюють 43 категорії зі списку Common Weakness Enumeration.

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

SP 800-218A від NIST відображає цей принцип, розширюючи свою Безпечну рамку розробки програмного забезпечення кращими практиками, що охоплюють генеративний ШІ та моделі подвійного використання.

3. Кому належить приріст продуктивності?

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

4. Кому належить пріоритизація?

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

Управління ШІ стає фінансовим питанням

Ці питання роблять управління ШІ все більш актуальним. Уявіть два партнерські розробки, які стягують подібні погодинні тарифи.

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

Покупцям доведеться оцінювати:

• Загальна очікувана інвестиція
• Відповідальність за перевитрати
• Контроль якості роботи, створеної ШІ
• Як розподіляються вигоди від підвищеної ефективності

Модель T&M може залишатися корисною для обох сторін, якщо вони свідомо приймають невизначеність у послугах. Фіксовані цінові договори також можуть працювати, коли вимоги та результати стабільні.

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

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

Той самий діалог про ШІ

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

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

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

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

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