Якби штучний інтелект існував з самого початку: дешевий код не зробив рішення про те, що будувати, легшим

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

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

Але це вже не так, і зміна відбулася швидше, ніж більшість лідерів інженерних команд встигли її осмислити.

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

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

“Не можна застосовувати штучний інтелект до розбитого процесу”, – сказав Пабло Гамба, голова технологій Америки в глобальній компанії програмного забезпечення та штучного інтелекту intive. “Це як давати робітникові швидшу лопату. Він буде працювати швидше, але тільки у неправильному напрямку”.

Швидша реалізація, старі обмеження

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

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

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

Бо агент може будувати тільки те, що описано досить точно, щоб агент міг виконувати без здогадок.

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

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

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

Цифри підтверджують його слова. Підприємства Fortune 50, які використовують розробку з підтримкою штучного інтелекту, відправляють коміти 3-4 рази швидше, ніж їхні колеги, згідно з дослідженням Cloud Security Alliance, але вводять нові результати безпеки приблизно в десять разів частіше.

Швидкість без чіткої мети в цьому сенсі не тільки марнує зусилля; вона також збільшує ризик швидше, ніж більшість команд з безпеки можуть впоратися з цим.

Отримання вимог у мову, яку штучний інтелект може реально використати

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

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

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

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

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

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

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

У словах Гамби, штучний інтелект не є дозволом пропустити процес, а вимогою переробити все з нуля. “Багато організацій намагаються застосовувати штучний інтелект до старих процесів. Це не трансформація. Організації, орієнтовані на штучний інтелект, починають з іншого питання: якщо штучний інтелект існував з самого початку, як би ми спроектували цей процес сьогодні?”

Менеджери беклога, куратори наміру

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

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

Ця переробка тихо формує, хто робить визначення, і що таке робота зараз.

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

Іншими словами, те, що зараз має значення, – це не знання того, як написати квиток чи запустити спринт. Це знання того, що таке “відмінно” виглядає, перш ніж робота навіть починається, можливість розрізняти, що інтелектуально цікаво, а що клієнти фактично потребують, і mít нерви, щоб швидко вбити ідею, коли вона явно не проходить цей бар’єр.

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

І також варто пам’ятати: жоден з цих титулів не зникає. Але лінії між ними стають все важче захищати, тоді як люди, які процвітають у цьому розмитті, – це ті, хто діє як куратори наміру.

Швидка реалізація без обмежень не є перемогою

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

Цифри тут навіть не близькі. Весняне тестування Veracode 2026 року серед провідних моделей виявило, що тільки 55% завдань генерації коду дали безпечний результат, коли не було явної вказівки безпеки, цифра, яка майже не змінилася за два роки, навіть якщо функціональна точність значно зросла.

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

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

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

Що таке лідерство

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

Але те, що не стало легшим, а навіть складнішим, – це визначити з реальною точністю, що варто будувати, описати це досить добре, щоб машина могла вірно виконувати, і провести лінії, які вона не повинна перетинати під час цього.

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