Я дозволив ШІ-агенту керувати моїм CI/CD-конвеєром протягом місяця. Наприкінці випробувального терміну він уже виправляв невдалі збірки, відкривав pull requests і перезапускав завдання, залишаючи лише один крок для підтвердження людиною. Експеримент показує, що «агентний» DevOps може перенести рутинне сортування помилок із бек-офісу в автоматизований мозок, але він також виявляє необхідність у запобіжниках, які не дають автономній системі стати новим джерелом ризику.

Чому цей експеримент мав значення

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

Основна ідея: агентний конвеєр

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

  1. Сприйняття – отримання логів, результатів тестів і метрик.
  2. Міркування – аналіз помилки, планування найбезпечнішого способу виправлення.
  3. Дія – запуск інструмента з обмеженим доступом для застосування патча, оновлення залежності або перезапуску завдання.
  4. Навчання – запис результату, щоб наступне рішення було більш обґрунтованим.

Архітектура, яка забезпечувала безпеку експерименту, виглядала так:

  • CI/CD-платформа – планує та запускає завдання.
  • Оркестратор – «мозок», який отримує дані, запускає цикл керування та вирішує, що робити.
  • Інструменти – «руки», що виконують конкретні дії (наприклад, відкриття PR, оновлення версії).
  • Сховище контексту – легка пам'ять про нещодавні помилки та виправлення.
  • Запобіжники – жорсткі обмеження, які не дозволяють агенту безпосередньо втручатися в продакшн або вносити зміни без явного підтвердження людиною.

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

Місяць із життя агента

Тиждень 1 – спостереження в режимі «тільки читання»

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

Тиждень 2 – пропонування виправлень

Протягом наступних семи днів оркестратор відкривав pull requests для низькоризикових проблем, таких як помилки лінтингу або застарілі залежності. Інженери перевіряли PR перед злиттям.

Тиждень 3 – контрольована дія

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

Тиждень 4 – вимірювання впливу

Останній тиждень був зосереджений на вимірюванні результатів та відстеженні того, скільки помилок виправив агент.

Переваги: усунення нудної роботи

Експеримент показав, що ШІ-агент може взяти на себе повторювані частини CI/CD: читання логів, виявлення відомих патернів, оновлення версій і перезапуск завдань. Інженерам залишалося лише схвалювати остаточні зміни та досліджувати ті небагато випадків, які агент не зміг розв'язати. На практиці це означало менше нічних викликів, менше перемикання контексту та швидший цикл зворотного зв'язку для розробників.

Пастки та способи їх пом'якшення

  • Впевнені, але помилкові виправлення – Агент іноді застосовував патч на рівні симптомів, який маскував глибший баг. Запобіжники, що вимагають схвалення людиною будь-якої зміни, яка стосується продакшн-коду, стримували цей ризик.
  • Перевантаження шумом – Нефільтровані сповіщення можуть заглушити справжні алертів.
  • Розширення меж (Scope creep) – Надання моделі необмеженого доступу швидко призводить до небажаних побічних ефектів. Суворе розділення в архітектурі між LLM (міркування) та інструментами (дія) запобігло тому, щоб агент не вносив довільні зміни.

Покроковий план впровадження для інших команд

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

  1. Налаштуйте оркестратор — легковажний сервіс, який може викликати LLM, зберігати контекст і викликати CI/CD API.
  2. Визначте обмеження (guardrails) — створіть білий список CI/CD завдань, які може запускати агент, вимагайте схвалення PR і блокуйте будь-які прямі записи у production.
  3. Тиждень 1: Режим спостереження — передавайте логи оркестратору, щоб він публікував діагностичні звіти в чат-канал.
  4. Тиждень 2: Режим пропозицій — дозвольте агенту відкривати PR для некритичних виправлень; обов'язково залиште перевірку людиною.
  5. Тиждень 3: Контрольована дія — надайте дозвіл на повторний запуск завдань у середовищах staging або test після злиття PR.
  6. Тиждень 4: Метрики та налаштування — відстежуйте відсортовані помилки, хибнопозитивні результати та зекономлений час; відповідно коригуйте пороги сповіщень і обмеження.
  7. Ітеруйте — розширюйте набір інструментів (наприклад, автоматичні відкати, сканування безпеки) лише після того, як кожна нова можливість пройде ті самі перевірки безпеки.

Контраргумент

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

Висновок

ШІ-агент, який керує циклом управління CI/CD, може перетворити реактивний процес ручного сортування помилок на майже самовідновлювальний конвеєр, за умови, що ви ізолюєте модель, запровадите суворі кроки схвалення та почнете з підходу «спочатку спостереження» з низьким рівнем ризику. Справжня цінність полягає не в заміні інженерів, а в передачі нудних, повторюваних завдань, які підтримують стабільність конвеєрів і дозволяють розробникам зосередитися на розробці.