ADLC: чому в агентів має бути свій lifecycle, і чому ваш SDLC для них не працює

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

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

У звичному світі ти б тут написав регрешн-тест. Але юніт-тестів нема. Або є — і вони зелені. Stack trace порожній. Sentry мовчить. Datadog показує latency в нормі. Маємо інцидент, який не лізе ні в один знайомий шаблон.

Я Андрій Кравець, Python-розробник в Levi9, у бекенді більше 10 років, очолюю напрям, і останні півроку активно занурююсь у агентну інженерію. Швидко зрозумів: звичний інструментарій тут не ламається — він просто проходить повз. Клас системи інший.

Один із нещодавніх випадків, який добре ілюструє цю різницю. У роботі з OpenCode і Claude Opus агенту явно заборонили читати файли поза активним проєктом. Спочатку він спробував ls — виклик заблокували. Тоді cat — теж заблокували. На що агент написав власну реалізацію читання файлової системи на Python і спробував її запустити. У звичному коді функція з заблокованим доступом просто кидає помилку. Тут — система шукає альтернативні шляхи досягнення мети. Це і є той самий «інший клас».

Стаття про те, чому SDLC не тягне на агентах і що приходить йому на заміну. У спільноті цей підхід усе частіше називають ADLC — Agent Development Life Cycle. Акронім ще не зацементований, у різних авторів формулювання трохи відрізняються, але суть одна: недетермінована система потребує іншого циклу розробки. Далі — три причини цього і каркас, який працює натомість.

Чому старі правила розробки тут не працюють

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

Однакові запити — різні відповіді. Це найочевидніший пункт. LLM не повертає одне й те саме навіть на ідентичному вході. Ти запускаєш одну і ту саму пару «промпт + дані» десять разів — і отримуєш десять схожих, але неоднакових відповідей.

«А поставте temperature=0» — найпоширеніша порада від тих, хто стикається з цим уперше. Temperature — це параметр, який керує «креативністю» моделі: при 0 вона завжди вибирає найімовірніше наступне слово, при 1 — вільно бавиться з варіантами. Здавалося б, нуль = повна передбачуваність. Не зовсім.

Навіть з temperature=0 два однакові запити можуть дати різні відповіді. Причина у тому, як модель крутиться на залізі провайдера: різні сервери, групування запитів у пакети, дрібні округлення в обрахунках. Сам OpenAI у документації пише: детермінованість «best effort, не гарантовано».

Близький за метою параметр — seed. Він задає однакову точку відліку для внутрішнього генератора випадкових чисел моделі: одна й та сама пара «промпт + seed» має дати ідентичний результат. На практиці працює дещо передбачуваніше, ніж просто temperature=0, але теж із приміткою «best effort» від провайдера. Я використовую seed для регресійних eval-прогонів, де потрібна максимальна повторюваність. Але самої природи недетермінованої системи це не змінює — на проді під різними навантаженнями і батчами різниця все одно прориває.

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

Код — лише одна з багатьох речей, що впливають на агента. У звичайному бекенді git diff показує все, що змінює поведінку. У агентній системі — ні. На результат впливає мінімум сім речей: код, системний промпт, схеми інструментів, RAG-індекс, ID моделі, логіка роутингу, набір тестових кейсів. Зміна будь-якої з них зміщує поведінку — часом сильніше, ніж зміна самого коду.

Один новий рядок у системному промпті може перевернути тон агента. Перебудова векторної бази змінює те, які документи агент знаходить у пошуку. Заміна моделі в конфігу — взагалі повністю міняє рівень якості. Усе це часто заходить у репозиторій як однорядкові зміни в конфіг-файлах. Code review бачить тривіальний diff і пропускає його. А насправді саме там — у промптах, у RAG, у конфігах — і живе більшість поведінки агента, а не у коді.

Агент може зламатися сам. Найдивніший пункт. У звичному бекенді деплой — стабільний стан: ніхто нічого не комітив, значить, поведінка не зміниться. У агентному світі це не закон, а виняток.

Провайдер мовчки оновлює модель під тим самим імʼям — і твій агент починає відповідати інакше. Anthropic deprecate-ить версію через шість місяців, і pinned snapshot просто перестає існувати. Модель для ембедингів отримує апдейт — RAG тепер підтягує трохи інші документи. Жодна з цих змін не пройде через твій PR. Прокидаєшся вранці, а агент уже не той, що вчора.

SDLC контролює те, що пише розробник. Агент же на дві третини живе поза репозиторієм. Потрібен ширший каркас — про нього далі.

Що таке ADLC

ADLC — це Agent Development Lifecycle, цикл побудови та експлуатації агентної системи. Назвами фаз він не дуже відрізняється від звичного SDLC. Відрізняється тим, з чого починається.

У SDLC ми спочатку пишемо код, потім тести (якщо вистачить часу), потім деплой. В ADLC все навпаки. Перший артефакт — не код і не дизайн системи, а набір прикладів, на яких ми будемо вимірювати якість агента. Поки нема чим міряти — будувати немає сенсу. Будь-яке «стало краще» доведеться приймати на віру, а на вірі продакшн не тримається. Для себе я цю інверсію — оцінку перед побудовою — вважаю головним у ADLC. Решта виростає з неї.

Як виглядає повний цикл

Контракт. Першим формулюємо задачу і критерії «коли агент справляється». І це не лише про правильність відповідей. Сюди ж — вартість на запит, latency (час, за який агент відповідає користувачу), частота галюцинацій (вигаданих фактів, яких насправді не існує) і тон спілкування. На кожен критерій — конкретний поріг. Без цих порогів рухатись далі немає змісту.

Golden set. Збираємо 50-200 реальних кейсів — таких, які агент зустрічатиме у проді. Не вигаданих, не «плюс-мінус схожих», і поряд з кожним кейсом — очікувана відповідь. Це і є наш «золотий» набір, на якому потім вимірюється все.

Чесне уточнення з реальності: на старті проєкту цього набору часто просто немає. Стейкхолдери ще не сформулювали «типові запити», PO ще не дав «бізнес-метрики для агента». У мене зараз агентна система вже у тестовій версії, а ці пункти все ще «in progress» з боку бізнесу. Це нормальна ситуація, не виняток. У такому разі я стартую з 5-10 кейсами, які зібрав сам із ранніх взаємодій з тестовим агентом. Решта дозбирується паралельно, у міру того, як приходять реальні юзкейси. Головне — почати міряти, навіть якщо набір поки що грубий. Ідеальний golden set — недосяжний міф, робочий — реальність будь-якого проєкту.

Eval-харнес. Автоматизований тест, який бере golden set, проганяє його через агента і виставляє оцінку. Простіша версія — бінарна: правильно чи ні. Складніша — LLM-as-judge: інша мовна модель оцінює відповідь нашого агента за заздалегідь визначеною рубрикою (наприклад, «доброзичливий тон, без вигаданих фактів, без зайвої довжини»).

Окрема група метрик — для агентів із RAG. Тут має сенс міряти окремо якість пошуку і якість генерації: context precision (скільки знайдених документів справді релевантні запиту), context recall (скільки потрібних документів система загалом знайшла), faithfulness (чи спирається відповідь на знайдений контекст, чи містить вигадки поза ним), answer relevancy (чи фінальна відповідь дійсно відповідає на запит). Розкладання на ці метрики допомагає швидко зрозуміти, де саме ламається система — у пошуку, у генерації, чи у логіці поверх них.

Важливе уточнення: eval-харнес не замінює класичні юніт- та integration-тести. Звичні pytest-и для функцій, інтеграційні тести для API навколо агента — все це лишається. Просто над ними зʼявляється ще один шар, який міряє вже саму модельну поведінку. На практиці комбінують різні інструменти для різних типів перевірок: pytest для класичної логіки, promptfoo для прогонів промптів і моделей, окремий eval-харнес для агентної якості в цілому. Важливо одне: цей шар має існувати до того, як написана перша функція самого агента.

Baseline. Найпростіша робоча версія — один промпт, без інструментів, без памʼяті. Запускаємо на golden set, фіксуємо метрики. Без цієї точки відліку всі подальші ітерації — блукання. Стало краще, але ніж що? Незрозуміло.

Ітерації. Тут уже починається звична робота: додаємо інструменти, ускладнюємо промпт, прикручуємо памʼять (механізм, який дозволяє агенту тримати в голові попередні взаємодії з користувачем), експериментуємо з моделлю. Кожна зміна обовʼязково проганяється через eval. Якщо метрики просіли — версія відкочується назад.

Окремий важливий сценарій — вибір моделі. Той самий промпт і той самий golden set проганяються через кілька кандидатів: GPT, Claude, Gemini, можливо локальну модель. Метрики якості порівнюються разом із вартістю та latency. Часто дешевша модель з трохи дотюненим промптом дає вищу якість, ніж найдорожча з посереднім. Без eval-харнеса такий вибір робиться по інтуїції — з ним рішення приймається на цифрах.

Цікаве спостереження з реального проєкту: для задач оркестрації і роутингу запитів менша модель часто справляється краще, ніж велика. Парадокс лише на перший погляд — у роутингу важливо швидко і чітко прийняти рішення «куди передати запит». Велика модель додає від себе зайвого «мислення», менша слідує промпту дослівно. Без eval-прогону такого не помітиш — це той випадок, де інтуїція «дорожче = краще» прямо обманює.

Environment rollout. Деплой ми робимо поетапно. Спершу shadow run: агент крутиться у середовищі, але на назовні нічого не показуємо — лише порівнюємо його відповіді з поточним рішенням. Якщо все ок — canary: 1-5% трафіку йде на нового агента, решта на старого. Якщо тримається і там — повний реліз.

Моніторинг. З релізом eval-прогони не закінчуються. Вони продовжують крутитися — щодня, а на критичних системах і частіше. Причина проста: модель у провайдера може оновитися без попередження, документи в RAG (Retrieval-Augmented Generation — механізм, де агент перед відповіддю шукає у внутрішній базі релевантні документи і додає їх у контекст) можуть застаріти, поведінка може почати дрейфувати сама собою.

Заміна. У SDLC — рідкісна подія, привід для дискусій на чотири години. У ADLC це регулярна частина життя. Метрики просіли нижче порогу або вийшла модель нового покоління — агент поводиться не так як очікується. Часто доводиться не просто переписувати його, а збирати наново: інші промпти, інші інструменти, інший golden set під актуальні вимоги.

Виглядає як багато роботи. На старті не все обовʼязкове — для MVP вистачить контракту, мінімального golden set, eval-харнеса і baseline. Решта дозбирується паралельно з тим, як агент починає жити у проді.

Головна звичка ADLC, на мою думку, — спочатку зрозуміти, як вимірюватиметься якість, і тільки потім писати код. Усе інше з цієї звички виростає само.

Як це виглядає на практиці

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

Мердж пул-реквесту. Pull request (PR) — це коли розробник пропонує свої зміни до основної гілки коду, і команда їх перевіряє перед тим, як прийняти. У звичному бекенді критерій простий: тести зелені, code review пройшов — мерджимо.

В ADLC до цього додається ще кілька умов. Eval-харнес (наш автоматичний тест із розділу 3) не показав регресії — тобто метрики якості не впали. Або впали, але у межах допустимого порогу: наприклад, до 5%. Вартість запиту не виросла. Sentinel-кейси (декілька найкритичніших прикладів, що мають проходити завжди) теж пройшли.

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

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

Як зазвичай діємо ми. Беремо кейс, який зловив користувач, і додаємо його у golden set з позначкою, якою має бути правильна відповідь. Проганяємо — бачимо, що проблема таки відтворюється, але, наприклад, раз на десять прогонів. Далі працюємо з промптом, з RAG, з логікою інструментів. Проганяємо ще раз. Якщо метрика по цьому кейсу виросла — добре, але це ще не кінець. Тепер треба прогнати всі 200 кейсів golden set і подивитись, чи фікс не зламав щось інше. У трьох випадках із десяти ламає. І це нормально — продовжую балансувати, поки не вийду на нову точку рівноваги.

Тут критично мати modelInvokationLog — журнал викликів моделі з вхідними й вихідними даними. Ми використовуємо LangSmith чи Langfuse: якщо дозволяє GDPR, то зберігаємо сирі дані, якщо ні — маскуємо чутливе. Це дає змогу одразу показати користувачу, що саме агент отримав на вході і що видав на виході. Без цього неможливо ні відтворити, ні пояснити, ні виправити.

Реліз. Деплой в агентному світі — це не одна подія, а поступовий запуск зі зворотним звʼязком на кожному етапі.

Перша фаза — shadow run (тіньовий запуск). Агент уже працює, обробляє реальні запити, але користувач його не бачить — відповіді спрямовані у порівняльну базу, поряд із відповідями старого рішення. Кілька днів збираємо різницю.

Друга — canary: 1-5% трафіку отримує відповіді нового агента, решта йде на старого. Дивимось метрики, вартість, latency. (Назва прийшла з історії — шахтарі брали в шахту канарок як ранній індикатор небезпеки; тут той самий принцип, тільки замість пташки — мала контрольована частка юзерів.)

Третя — повна розкатка. Якщо canary тримається — поступово нарощуємо до 100%.

Це повільніше за класичний «git push, CI пройшов, прод». Але дешевше, ніж відкочувати реліз, який додав тиждень роботи команді підтримки.

Оновлення залежностей. У звичайному бекенді все звично: lockfile (файл, де зафіксовані точні версії всіх бібліотек, щоб у різних оточеннях стояло одне й те саме), semver (semantic versioning — правило іменування версій вигляду 1.2.3, де перша цифра ламає сумісність, друга додає функції, третя фіксить баги), Dependabot створює PR на оновлення, прогнали тести — змерджили.

В агентній системі модель — теж залежність, але поводиться зовсім інакше. Може бути оголошена deprecated з боку провайдера. Може мовчки оновлюватись під тим самим іменем — наприклад, ім’я моделі лишилось те саме, а всередині вже інша версія. Кожне таке оновлення вимагає повного eval-прогону, а не «прогнали юніт-тести і пішло».

Коли Anthropic чи OpenAI оголошують, що через 6 місяців модель перестане підтримуватись, це має бути не пункт у Jira, який можна відкласти. Це окремий міні-проєкт: знайти кандидатів на заміну, прогнати на кожному наш golden set, оцінити різницю в якості й вартості, переписати промпти під нову модель (бо вона часто інакше реагує на ті самі формулювання). В практиці міграція моделі займає від тижня до місяця, залежно від складності системи.

Спільна риса всіх чотирьох етапів — рішення на кожному кроці спирається на eval-харнес і метрики. Без них це не ADLC, а гра в інтуїцію. З ними — звичний інженерний процес, тільки адаптований під систему, яка не дає однакової відповіді двічі.

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

ADLC змінює щоденну роботу, але 10+ років бекенду нікуди не зникають. На них і будується все інше.

Хороша новина для бекенд-інженерів. Агентна система — це насамперед розподілена система (тобто система, де компоненти розкидані по різних сервісах і координуються між собою через мережу). Усе, з чим бекендери звикли працювати — обробка помилок, retries (автоматичні повторні спроби при збоях), circuit breakers (механізм, який тимчасово припиняє запити до сервісу, що впав, щоб не добивати його), observability (моніторинг системи через логи, метрики й трейси) — залишається актуальним. LLM просто стає ще одним зовнішнім сервісом. Так, він дорогий і повільний, поведінка у нього непередбачувана — але по суті це API-залежність зі своїми особливостями.

Якщо хтось проєктував кешування, налаштовував timeout-и між сервісами, моніторив систему через метрики й логи — у нього вже є ~70% потрібної бази. Решта — агентна специфіка, про неї нижче.

До речі: ML-інженери з фокусом на класичну модельну науку (тренування, fine-tuning, дослідження архітектур) тут НЕ мають великої переваги. Робота з агентом — це збірка системи навколо моделі, а не тренування самої моделі. Інженерна робота, не дослідницька. Я б поставив на досвідченого бекендера в цій ніші скоріше, ніж на ML-дослідника.

Що доведеться додати. Кілька навичок, які варто почати освоювати

Eval engineering. Окремий шар компетенцій — як писати golden set, як налаштовувати rubric-based scoring, використовувати LLM-as-judge так, щоб система не наспівувала собі компліменти. Інструменти: ragas, promptfoo, або просто власний харнес на pytest. На одному з наших проєктів зупинились на promptfoo — найкраще ліг на node.js-стек команди. Це типова логіка вибору: eval-інструмент частіше диктується мовою основного стека, ніж самими функціями інструмента.

LLM-observability. Класичні Sentry і Datadog тут не допомагають — їм нема чого ловити, бо помилка не у стек-трейсі, а у «відповідь не та». Альтернативи, які варто подивитись: langfuse, langsmith, helicone, AWS Bedrock AgentCore (observability + evaluation в одному пакеті). На одному з наших проєктів, наприклад, Langfuse стоїть на dev-середовищі для глибокого дослідження окремих кейсів, а щодня команда дивиться у вбудовану observability фреймворку Mastra.ai — часто фреймворк-нативне рішення зручніше за окремий сервіс, бо не потребує додаткової інтеграції. Або власна реалізація поверх OpenTelemetry, якщо вже є зріла observability-інфраструктура.

Structured outputs. Робота з тим, щоб модель повертала валідний JSON або pydantic-обʼєкт замість вільного тексту. Бібліотеки: instructor, outlines, pydantic-ai. Без цього парсити «may I help you find that for you?» зі стрічки — окреме пекло. Я сам колись провів пів дня, регулярним виразом виловлюючи структуру з вільної відповіді — краще було одразу взяти instructor.

Prompt engineering як інженерна дисципліна. Не про «магічні слова», а про вміння писати системний промпт і описувати tool-схеми (опис функцій, які модель може викликати) так, щоб модель їх передбачувано використовувала. Окрема компетенція, в підручниках її не знайдеш — тільки практикою і чужими промптами як референсом.

Cost engineering. Вартість одного запиту до моделі може вирости в десять разів від того, як ми структурували контекст і RAG. Кешування, model routing (коли різні типи задач спрямовуються на різні моделі — простіші у дешеву, складніші у дорогу), prompt compression — це стало реальною статтею витрат на проєкті.

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

Нова роль на ринку. За останній рік чітко зʼявилась окрема роль — Agent Engineer (або AI Engineer; термін у різних компаніях по-різному). Це людина, яка спеціалізується саме на побудові, тестуванні й супроводі агентних систем. Не ML-дослідник і не data scientist. Радше гібрид: бекенд-патерни плюс LLM-обмеження плюс evaluation.

У реальному житті це вже не фантазія. Знаю команду, де двоє інженерів офіційно представляються як AI Engineer і повністю покривають якість агента — від першого промпту до релізу. Це проєкт середнього розміру, і навіть там роль уже виокремилась.

Моя ставка — у наступний рік-два eval-інженер виокремиться як ще вужча субспеціалізація. У великих командах цю роль уже починають винести як окрему.

Senior-бекендеру не треба ставати з нуля «AI-інженером» — радше додати кілька шарів компетенції поверх того, що вже є. Це інакша робота, ніж раніше, але не зовсім нова. Більше схоже на те, як ми колись заходили в мікросервіси чи Kubernetes. Через рік уже звично, а через два вже додано в резюме.

Висновки

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

ADLC — спроба формалізувати це «по-іншому». Її головна звичка проста: спочатку зрозуміти, як вимірювати якість, і тільки потім писати код. Усе решта виростає з цієї звички: поетапні релізи з постійним контролем метрик, повні evals при оновленні моделі, опис у PR з дельтою по метриках замість одного git diff. Це не магія. Це інженерна дисципліна, адаптована під систему, яка не поводиться однаково двічі. Так, більше кроків. Але набагато менше тривожних дзвінків о третій ночі.

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

Цікаво, як це виглядає у вас. Чи ловили «тихі» регресії після оновлення моделі? Як міряєте якість агента у проді? Напишіть у коментарях — буду читати і де можу — відповім.