AWS ADOP: AI-агенти в розробці, детермінований код у продакшені

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

Суть проблеми

Підключення нового регульованого джерела даних досі займає кілька тижнів у більшості компаній на стадії series-B та корпоративному рівні. Хтось пише PySpark. Хтось інший пише перевірки Great Expectations. Третій оновлює семантичний шар. Юридичний відділ перевіряє документацію лінійності через два спринти. До того моменту, коли Gold-таблиця нарешті з'являється, бізнесове питання, що ініціювало запит, вже втратило актуальність.

Очевидне рішення, яке кожен вендор просував протягом 2025 року, полягало в тому, щоб помістити LLM-агента в шлях виконання. Нехай агент інспектує джерело, генерує трансформацію, виконує її, вчиться на помилках, повторює спробу. Така демонстрація виглядає переконливо. Але вона провалюється в регульованому середовищі за трьома критеріями: передбачуваність витрат, відтворюваність аудиту, і незручна реальність — модель, що поводиться у вівторок інакше, ніж у понеділок, це не те, що хоче почути банківський регулятор.

Agentic Data Operations Platform, як повідомляє Amazon Web Services (AWS), є референсною архітектурою на Amazon Bedrock, призначеною для скорочення цих термінів з тижнів до годин. Цікаве тут не сама обіцянка прискорення — кожен агентний пітч містить щось подібне. Цікаве те, де саме живуть агенти. У стандартному патерні ADOP агенти працюють виключно в середовищах розробки. Вони генерують детермінований PySpark, SQL, Airflow DAGs, IAM-політики та правила авторизації Cedar. CI/CD просуває ці артефакти до продакшену. Продакшен виконує їх без жодних звернень до моделі.

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

Доступні варіанти

Керівник дата-платформи, який зараз оцінює агентні інструменти, має приблизно чотири різні патерни на вибір, і вони не взаємозамінні.

Патерн перший: модель у циклі виконання. Агенти спостерігають за продакшен-даними, приймають рішення щодо трансформацій на льоту та виконують їх. Цей патерн продають більшість агентних стартапів. Він максимізує гнучкість і максимізує варіативність витрат. Кожен запуск пайплайну — це рахунок за токени. Кожна зміна версії моделі — це ризик регресії. Для ad-tech-компанії, що швидко рухається з нерегульованими даними, — прийнятно. Для будь-кого, хто працює з PHI або KYC-даними, — кошмар з точки зору відповідності, який чекає свого першого аудиту.

Патерн другий: агенти в розробці, детерміновані артефакти в продакшені. Це стандарт ADOP. Суб-агенти, запущені через функцію Dynamic Workflow Claude Code, обробляють генерацію метаданих, дедукцію онтологій, перевірки якості, ETL та оркестрацію через Airflow або AWS Step Functions. Вихідні дані перевіряються, просуваються та виконуються без звернень до моделі. Рахунок за токени обмежений частотою підключення нових джерел, а не обсягом трафіку. Аудитори отримують статичний код для перевірки, а не трейси моделі.

Патерн третій: керовані платформи агентів у режимі виконання. Amazon Bedrock AgentCore позиціонується як масштабована платформа для запуску агентів, і ADOP може бути переведений на неї за потреби. Це пітч «ми запустимо ваших агентів у масштабі», і він певним чином суперечить патерну два. AWS чесна щодо цього: обидва патерни є правомірними, вони оптимізовані під різні завдання. AgentCore оптимізований під гнучкість. ADOP оптимізований під передбачуваність витрат і готовність до аудиту.

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

Питання «будувати чи купувати» тут незвичне, тому що ADOP — це не продукт, який ви купуєте. Це референсна архітектура, яку ви клонуєте з GitHub та адаптуєте. Реальне зобов'язання перед вендором — це Amazon Bedrock та Claude Code як середовище розробки, плюс обраний вами обчислювальний бекенд (Spark на EMR, Glue, або щось на зразок Databricks, якщо ви вже там). Залежність зміщується від агентного рантайму до провайдера моделі та CLI-інструментарію. Це принципово інша позиція на переговорах через вісімнадцять місяців.

Що реально варто робити дата-командам

Моя думка: якщо ви запускаєте регульовані пайплайни, патерн ADOP є правильним за замовчуванням, навіть якщо ви ніколи не торкатиметеся конкретної реалізації AWS. Запозичте архітектурну ідею. Тримайте агентів у розробці, відправляйте детермінований код, залишайте продакшен нудним. Самої лише економіки токенів достатньо для обґрунтування. Пайплайн, що звертається до моделі при кожному запуску, має витрати, що масштабуються з трафіком. Пайплайн, згенерований один раз і перевірений один раз, має витрати, що масштабуються з обсягом підключень нових джерел, — а це приблизно на два порядки менше для більшості підприємств.

Варто назвати наслідки для складу команди. Цей патерн потребує менше prompt-інженерів і більше платформових інженерів, які розуміють CI/CD, policy-as-code та вміють перевіряти згенерований PySpark на коректність. Ринок найму «AI-інженерів» перегрітий уже вісімнадцять місяців. Ринок найму сильного платформового інженера, який може читати Cedar-політики та писати Airflow DAGs, — напружений, але не шалений. Цей патерн на боці команди, яку ви реально можете найняти.

Фінансовий директор або керівник платформи, який читає цей тижневий звіт для ради директорів, повинен ставити конкретне питання: яка частка нашого прогнозованого витрачання на AI-інфраструктуру у 2026 році припадає на рантайм-інференс у дата-пайплайнах, а яка — на генерацію коду на етапі збірки? Якщо відповідь сильно схиляється до рантайму, комусь потрібно обґрунтувати це на тлі патерну ADOP конкретними аргументами, а не відчуттями. «Модель має бути в циклі» — це не аргумент. «Ми маємо неструктуровані вхідні дані, що змінюють форму щодня, і статичний код не може з ними впоратися» — це аргумент.

Для команд, що вже працюють на Snowflake або Databricks, ADOP не вимагає міграції. Він підтримує будь-який сервіс з CLI або Model Context Protocol-інтерфейсом, що чесно означає: архітектурний контракт є переносним. Спрямовуйте згенеровані артефакти на будь-яке сховище, яке ви вже використовуєте.

Підводні камені та крайні випадки

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

Кожне рішення агента трейситься через щось під назвою AgentTrace, що публікує дані в CloudWatch або OpenTelemetry-приймач. Це добре. Але трейси процесу збірки — це не те саме, що продакшен-моніторинг, і командам не варто їх плутати. Вам все одно потрібен реальний моніторинг пайплайнів для детермінованих артефактів після їх розгортання.

Відповідність вимогам — не абсолютна. ADOP застосовує один регуляторний промпт на фреймворк управління під час підключення, і AWS прямо вказує, що клієнти залишаються відповідальними за визначення власної відповідності. Це формулювання важливе. Згенерована Cedar-політика — це відправна точка для перевірки вашим юридичним відділом, а не її замінник. Якщо ваша функція відповідності не укомплектована для перевірки policy-as-code, додавання агента, що генерує більше таких правил швидше, не допоможе.

Нарешті, залежність від Claude Code є реальною. Kiro, Cursor і Codex підтримуються як середовища розробки, але патерн Dynamic Workflow суб-агентів — це функція Claude Code. Якщо ваша організація стандартизувалася на іншому coding-асистенті, очікуйте додаткової роботи з адаптації.

Ключові висновки

• Основна ідея ADOP — архітектурна: агенти в розробці, детерміновані артефакти в продакшені. Це обмежує витрати на токени обсягом підключення нових джерел, а не обсягом трафіку.
• Патерн сприяє командам, які можуть найняти платформових інженерів, на противагу командам, що роблять ставку на дефіцитних prompt-інженерів.
• Для регульованих навантажень у охороні здоров'я та фінансових послугах статично згенерований код аудитується значно простіше, ніж модель, яка може поводитися по-різному наступного тижня.
• Залежність зміщується від агентного рантайму до провайдера моделі та CLI-інструментарію. Враховуйте це на переговорах, коли підходить час оновлення Bedrock або Claude-зобов'язань.
• Реальна робота — це кодифікація ваших архітектурних стандартів, щоб Decision Engine мав що застосовувати. Команди без письмових стандартів дізнаються про це на власному гіркому досвіді.

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