Агентне кодування: Другий шанс для DevOps та управління ШІ

Незавершена трансформація DevOps та агентне кодування

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

Повернення Морица Плассніга та нове бачення

Мориц Плассніг, новопризначений CEO CloudBees, повернувся до компанії після п'яти років роботи в Immuta. Спостерігаючи, як великі мовні моделі змінюють спосіб роботи клієнтів з даними, він знову зацікавився проблемою доставки програмного забезпечення. Він стверджує, що агентне кодування є «другим шансом» для DevOps насправді виконати свою початкову обіцянку. Проблема вже не в тому, що команди не погоджуються з реальністю DevOps, а в тому, що більшість компаній ніколи не пройшли весь шлях, і їхні скорочення тепер є стелею для швидкості роботи агентів.

Рецепт управління для агентного кодування

Рецепт Плассніга є прямим: взяти правила, за якими організація вже живе — наприклад, перевірка будь-якої зміни коду двома людьми, незалежно від конкретних політик — і закодувати їх як версіоновану політику. Центральний механізм управління може забезпечувати дотримання цих політик у CloudBees, Jenkins, GitHub, GitLab або будь-якому іншому інструменті кодування, який обирає команда. Він наводить вражаючі дані від дуже великого банку: горизонти технологічного планування скоротилися з п'яти-десяти років до двох-трьох, що означає, що стандартизація поступається місцем керованому меню затверджених інструментів, які об'єднує рівень управління.

Зміна парадигми та ризики

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

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

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

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

Багато підприємств не завершили трансформацію DevOps, розпочату десятиліття тому.
Агентне кодування виявляє ці незавершені області, такі як повільні збірки, нестабільні тестові набори та ручні кроки випуску.
Мориц Плассніг, новий CEO CloudBees, вважає, що агентне кодування є "другим шансом" для DevOps виконати свою початкову обіцянку.
Він пропонує кодувати існуючі організаційні правила (наприклад, перевірка коду двома людьми) як версіоновану політику.
Центральний механізм управління має забезпечувати дотримання цих політик у різних інструментах (CloudBees, Jenkins, GitHub, GitLab).