Інженерія циклів (loop engineering) зараз на піку популярності. Прогляньте будь-який технічний форум, і ви знайдете дискусії про те, що нам слід припинити ставитися до ШІ-агентів як до чат-ботів, яких потрібно навчати за допомогою хитромудрих промптів. Натомість пропонують проєктувати цикли: автономні процеси, які дозволяють агенту планувати, виконувати, перевіряти власну роботу та ітерувати, поки ми спимо. Ця ідея звучить спокусливо. Якщо цикл побудований правильно, агент не збивається з курсу без постійного нагляду людини, перетворюючи сирий намір на готовий результат за одну ніч.
Ця обіцянка чудово працює в теорії. На практиці більшість агентів уже працюють циклами. Вони генерують код, перевіряють помилки компілятора або невдалі тести, виправляють код і запускають набір тестів знову. Такий базовий цикл зворотного зв'язку не є чимось новим. Те, чого зараз вимагають прихильники цього підходу, — це щось більш амбітне: зовнішній цикл (outer loop), який керує всім завданням, а не лише синтаксичними помилками. Будівництво такого зовнішнього циклу — це саме те місце, де все стає складним, адже розробка програмного забезпечення рідко є замкненою системою з фіксованими правилами.
Проблема проектування циклів
Продуктові цілі бувають розмитими. Рідко коли вдається почати з ідеального визначення готовності (definition of done). Частіше ви виявляєте справжню мету вже під час активної розробки. Вимога, яка здавалася простою на дошці, виявляється такою, що має граничні випадки (edge cases), які повністю змінюють архітектуру рішення. Коли ви загортаєте агента в жорсткий цикл, ця жорсткість стає недоліком. Цикл продовжує бити в ціль, яка може бути хибною. Ще гірше те, що гнучкий цикл іноді вирішує проблему глухого кута, тихо змінюючи мету так, щоб вона відповідала будь-якому отриманому результату. Жоден із цих результатів не є корисним. Один марнує обчислювальні ресурси, інший — впевнено випускає сміття.
Глибша проблема полягає у вартості специфікації. Якщо ви хочете, щоб цикл працював без нагляду, ви повинні написати специфікацію, яка передбачає майже все. Що саме має змінити агент? Яка існуюча поведінка є священною і має бути збережена? За яких саме умов агент має припинити ітерації? Які ризики є прийнятними, а які побічні ефекти мають викликати негайну зупинку? Написання такого документа може зайняти більше часу, ніж просто сидіти поруч із агентом і керувати ним під час виконання завдання в режимі реального часу. Ви сплачуєте великий авансовий податок в обмін на автоматизацію, яка окупається лише тоді, коли верифікація є значно дешевшою за саме виконання.
Де цикли справді виправдовують себе
Це не означає, що інженерія циклів марна. Це означає, що це спеціалізований інструмент, а не універсальна стратегія. Цикли демонструють найкращі результати, коли витрати на верифікацію зростають, а критерії успіху є однозначними. Є три сфери, де це зазвичай справедливо.
Рутинна механічна робота. Згадайте завдання, через які досвідчені інженери хочуть піти на пенсію: запуск застосунків у певній послідовності, клікання в інтерфейсі розгортання для підтвердження кожного етапу, пошук (grep) відомих рядків помилок у логах після релізу або перевірка того, чи був записаний конфігураційний файл на всі потрібні вузли. Ці кроки нудні для людей, але тривіальні для перевірки. Цикл може «приглядати» за процесом, перевіряючи ендпоінти стану (health endpoints) після кожного перезапуску та здійснюючи відкат при першій ознаці проблем. Людина все одно визначає план розгортання. Цикл просто виконує його з терпінням машини о другій годині ночі.
Вимірювані цілі оптимізації. Коли успіх вимірюється числом, цикли стають надзвичайно ефективними. Знизити p99 затримку нижче 150 мілісекунд. Зменшити споживання пам'яті на двадцять відсотків. Мігрувати критичний шлях (hot path) з Python на Rust і переконатися, що всі існуючі юніт-тести проходять. Цикл може згенерувати зміну, провести бенчмарк, залишити варіант, який дав результат, і відкинути решту. Оскільки верифікація автоматизована, а простір пошуку великий, зростаюча вартість ручної перевірки зробила б таку роботу непрактичною без циклу. Ціль фіксована. Шлях невідомий. Це ідеальна ситуація.
Операційні інструкції (playbooks). Реагування на інциденти та тікети підтримки часто відбуваються за шаблонами, які люди вже давно розгадали. Специфічний клас помилок у продакшені завжди потребує ротації облікових даних і очищення кешу. Категорію запитів підтримки можна вирішити поверненням коштів, якщо виконано три конкретні умови. Цикл може відстежувати ці тригери та виконувати інструкцію, ескалюючи проблему лише тоді, коли шаблон порушується. Він не вирішує, чи правильна інструкція; він просто забезпечує послідовність у масштабах і зі швидкістю, з якими чергові інженери не можуть змагатися.
Регулятори, а не ті, хто встановлює орієнтири
У багатьох нинішніх дискусіях бракує одного вирішального розрізнення. Цикли — це регулятори. Вони утримують систему у відповідності до заданої цілі, подібно до того, як термостат підтримує температуру в кімнаті на рівні сімдесяти двох градусів. Але термостат не обирає сімдесят два градуси. Хтось спочатку мав вирішити, що це правильна температура.
У застосуванні до програмного забезпечення це означає, що агент у циклі може цілий день виправляти помилки, рефакторити функції або налаштовувати параметри. Однак він не може вирішити, яка функція насправді допомагає клієнту або чи варто виправляти помилку перед наступним релізом. Ці рішення потребують оцінки бізнес-контексту, болю користувачів та стратегічних пріоритетів. Агенти виконують. Люди вирішують. Коли ці поняття плутають, команди отримують чудово оптимізовані системи, які вирішують не ту проблему.
Інженерія циклів є корисною, але вузькоспрямованою. Вона допомагає запускати машину дисципліновано та швидко. Вона не вирішує, яку машину будувати, для кого вона і як виглядає успіх у людських поняттях. Судження про те, яка функція є важливою, який ризик є прийнятним і коли сама мета потребує змін, — це те, що залишається за вами. Створюйте цикли для тієї роботи, яку ви вже достатньо добре розумієте, щоб перевіряти її автоматично. Все інше залишайте під власним контролем.
Ця стаття ґрунтується на ідеях, вперше обговорених Айзеком Хагоелем у статті “Loop Engineering Minus The Hype.” Щоб долучитися до подальших інженерних дискусій, приєднуйтесь до нашої навчальної спільноти в Telegram.