ШІ в розробці: від "slop" до відповідальності розробника

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

ШІ-створене програмне забезпечення: майбутнє чи експеримент?

ШІ в розробці вже вийшов за межі експериментальної стадії. Наприклад, платформа Rocket, що використовує ШІ для створення додатків, вже постачає виробничі рішення для команд Fortune 100. Очікується, що в майбутньому дуже мало програмного забезпечення буде створюватися без ШІ, а вибір полягатиме лише в ступені його залучення. Якщо ШІ використовується для визначення того, що будувати, то це майбутнє. В іншому випадку це залишається швидким кодуванням або «vibe coding», що здебільшого є експериментом. Кінцевим критерієм є те, чи виконує програмне забезпечення реальні транзакції та бізнес. Майбутнє належить платформам, які поєднують повний цикл: від прийняття рішення про те, що варто будувати, до створення за виробничими стандартами та відстеження ринкових змін після запуску, з сильним людським судженням та інженерією виробничого рівня.

Перехід до складних інструментів

Цей перехід відбувається вже зараз і, як очікується, стане стандартом протягом наступних 12-18 місяців. Технічний бар'єр значною мірою подолано: сучасні агентні системи можуть планувати, міркувати на кількох етапах, інтегруватися з існуючими API та самокоригуватися. Справжній бар'єр є організаційним, а не технічним. Опитування понад 6000 керівників показало, що понад 80% не повідомили про вимірний приріст продуктивності від ШІ, попри значні інвестиції, що вказує на «прогалину у підзвітності». Підприємства реагують, інтегруючи ШІ в керовані платформи з перевіркою безпеки, контролем доступу та аудиторськими слідами. Переможцями цього переходу стануть компанії, які розглядають валідацію, управління та моніторинг після запуску як першокласні частини платформи. Генерація коду ніколи не була найскладнішою частиною корпоративного програмного забезпечення; відповідальне його виконання – так.

Вплив на бізнес-моделі ISV та IT-сервісів

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

Проблеми якості та «ШІ-slop»

Занепокоєння щодо «ШІ-slop», проблем якості та надмірності тестування є законними. Дослідження показують розрив між впровадженням та результатами: близько дев'яти з десяти розробників використовують ШІ-інструменти, але приріст продуктивності скромний, а рецензенти повідомляють про більше дефектів у коді, написаному за допомогою ШІ. Найпоширеніша скарга розробників: результат «майже правильний, але не зовсім». «Slop» походить від робочого процесу, а не від моделі: однопрохідна генерація без специфікації, тестів та підзвітності. Якість зростає, коли платформа вимагає обґрунтованих вимог, будує за виробничими шаблонами та залишає людину відповідальною. Rocket, наприклад, використовує функцію Solve та залучає людей для фінальної валідації та корекції.

Проблеми з pull-запитами в Open Source

Це справжня криза, і Open Source є системою раннього попередження. Генерація стала майже безкоштовною, тоді як рецензування залишається дорогим і людським. Один учасник з агентом може відкривати п'ять pull-запитів на день, і волонтер-супроводжувач не може перевіряти з такою швидкістю. Деякі проекти вже закрилися через обсяг ШІ-генерованого спаму. Це проблема асиметрії, яка торкнеться корпоративних команд, якщо вони не інвестують у валідацію так само серйозно, як у генерацію. Вирішення полягає в розкритті ШІ-допомоги, надсиланні тестів з кожною зміною та покладанні відповідальності за коректність на того, хто надсилає, а не на модель. Швидкість без можливості рецензування – це не продуктивність, а відкладені витрати.

ШІ та робочі місця розробників

Коли щось дешевшає, люди не просто роблять ту саму кількість за менші гроші; вони роблять набагато більше, оскільки речі, які раніше не варто було намагатися, раптом стають можливими. Будівництво програмного забезпечення стало дешевшим, тому його намагаються робити набагато більше людей, багато з яких не мають технічної освіти, і набагато швидше. Це не зменшує потребу у кваліфікованих людях, які контролюють процес; навпаки, збільшує її. Бюро статистики праці США прогнозує зростання зайнятості розробників програмного забезпечення на 15% до 2034 року, називаючи ШІ рушієм попиту, а не загрозою. Це більше найму, але для іншої компетенції: менше «чи можете ви це написати», більше «чи можете ви сказати, чи це правильно». Організації, які припускали, що дешевше будівництво означає менше будівельників, помиляться. Контрольоване дослідження показало, що досвідчені розробники були повільнішими з ШІ на знайомих кодових базах, хоча вважали себе швидшими, оскільки рецензування та виправлення «майже правильного» коду – це невидима робота. Нове вузьке місце – черги на рецензування, а не швидкість набору тексту. Розробників не замінюють; робота переходить від написання кожного рядка до керування, валідації та володіння системами.

Позиції Fedora та Codeberg

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

Що це означає для розробників

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

Ключові факти

ШІ в розробці ПЗ вже пройшов стадію експерименту і стане стандартом протягом 12-18 місяців.
«ШІ-slop» є проблемою робочого процесу, а не моделі, виникаючи через відсутність специфікацій, тестів та підзвітності.
Організаційний бар'єр є ключовим для впровадження ШІ, а не технічний.
Роль розробників змінюється: менше написання коду, більше керування, валідації та відповідальності за системи.
Проблема не в ШІ-генерованому коді, а в непідзвітному ШІ-генерованому коді.