Штучний інтелект пише код, але чи може ваша інфраструктура впоратися?

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

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

Проблема вже тут

Дослідження 2025 року GitClear виявило, що майже 7% комітів тепер містять код, згенерований штучним інтелектом. Їхнє попереднє дослідження 153 мільйонів рядків зміненого коду показало вартість: “code churn” – код, переписаний або видалений протягом двох тижнів, подвоївся до 2024 року порівняно з базовими показниками до штучного інтелекту.

Безпекові наслідки однаково яскраві. Недавній аналіз 80 відібраних завдань програмування по більш ніж 100 великим мовним моделям показав, що код, згенерований штучним інтелектом, вводить уразливості безпеки в 45% випадків. Реальний вплив? Один із п’яти CISO зараз повідомляють про серйозні інциденти, безпосередньо спричинені кодом, згенерованим штучним інтелектом.

Швидкість виграшів реальна, але так само реальні і витрати на стабільність.

Ефект посилення

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

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

Парадокс детермінізму

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

Мій відповідь? Збережіть якнайбільше стеку детерміністичного рівня. Якщо ви можете підтримувати 80% вашої інфраструктури на детерміністичному рівні, ваші агенти штучного інтелекту мають менше змінних для управління. Вони не витрачають контекстні вікна на “Чому ця залежність не встановилася?” або “Дайте мені спробувати цю збірку знову”. Вони зосереджені на справжній роботі, яку ви просите їх зробити.

Подумайте про це: коли агент намагається скомпілювати щось і рідні зв’язки не проходять через відсутність ImageMagick, це токено-дорога відхилення. Якщо ваше середовище вже містить все необхідне (компілятори, бібліотеки, повне дерево залежностей аж до libc), агент просто працює. Ні відладка, ні спроба і помилка, просто прогрес.

Специфікація та валідация є ключем

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

Я помітив щось цікаве: люди з фоном управління продуктом або інженерії продукту часто більш успішні з агентами штучного інтелекту зараз. Вони вже навчилися думати у термінах вимог, критеріїв успіху та компромісів. Вони комфортно запитують “Чому ви зробили цей вибір?” і регулюють на основі обґрунтування.

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

Довіряйте, але перевіряйте (і контролюйте)

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

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

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

Що далі

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

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

Ось моя найбільша порада для команд, які намагаються успішно працювати у віці штучного інтелекту:

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

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

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

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