ШІ-агенти для кодування стрімко прискорюють розробку даних, генеруючи трансформації, конвеєри, робочі процеси оркестрації, тести валідації та конфігурації інфраструктури на основі запитів.
Однак корпоративні платформи даних протягом тривалого часу функціонували на базі фрагментованих систем, що належать різним командам та побудовані на різних технологіях. Оскільки ці системи розвиваються незалежно, організації все частіше стикаються з неузгодженою бізнес-логікою, дубльованими реалізаціями, складним аналізом впливу на подальші системи та прихованими залежностями в межах платформи.
Зростання “vibe coding” (кодування на основі інтуїції та контексту розмови) може додатково посилити ці проблеми, оскільки більше операційного контексту, архітектурних рішень та бізнес-знань розсіюються між запитами, розмовами, згенерованим кодом та непов’язаними робочими процесами, замість того, щоб стати частиною самої системи.
Розробка, керована специфікаціями (Spec-driven development, SDD), з’являється як один із підходів до вирішення цієї проблеми. У SDD запити, бізнес-правила, логіка валідації, поведінка оркестрації та робочі процеси реалізації перетворюються на виконувані специфікації з контролем версій, які стають частиною самої системи. Ці специфікації діють як постійна операційна пам’ять як для людей, так і для ШІ-агентів, дозволяючи системам послідовніше розвиватися між релізами, командами та робочими процесами, керованими ШІ.
Оскільки розробка корпоративних даних вже значною мірою покладається на повторно використовувані шаблони, конвеєри, керовані метаданими, та стандартизовані операційні робочі процеси, вона особливо добре підходить для SDD. Комбінуючи генерацію за допомогою ШІ з детермінованими та повторно використовуваними системними контрактами, SDD може надати новий операційний рівень для зменшення фрагментації та покращення довгострокової координації в межах платформ даних, що все більше генеруються за допомогою ШІ.
Саме по собі “vibe coding” не має сталої системної пам’яті
“Vibe coding” надзвичайно добре працює для швидкої генерації ізольованих реалізацій. Але запити за своєю суттю є тимчасовими. Вони фіксують припущення інженера, бізнес-контекст, логіку реалізації та системні знання лише для конкретної розмови та моменту часу.
На практиці, забезпечення функціонування систем, згенерованих ШІ, часто вимагає значно більше, ніж простий запит. Інженери постійно надають фонову інформацію, архітектурні рішення, бізнес-правила, припущення щодо схеми даних, залежності подальших систем, операційні обмеження, історію налагодження та вказівки щодо реалізації протягом усього процесу розробки.
Ці контексти стають справжніми операційними знаннями, що стоять за розробкою за допомогою ШІ.
Однак, у більшості робочих процесів “vibe coding” ця інформація залишається розсіяною між запитами, розмовами, задачами Jira, документацією, історією чатів, згенерованим кодом та непов’язаними робочими процесами, замість того, щоб стати частиною самої системи.
Це створює серйозну проблему для корпоративної розробки даних, оскільки сучасні платформи даних природно фрагментовані між багатьма взаємопов’язаними системами, включаючи конвеєри прийому даних, сховища даних, фреймворки оркестрації, семантичні рівні, API, інформаційні панелі та системи машинного навчання (ML). Оскільки все більше логіки та контексту вбудовується в запити та згенеровані реалізації, організації поступово втрачають видимість щодо:
-
архітектурного задуму
-
залежностей подальших систем
-
припущень щодо валідації
-
операційної поведінки
-
бізнес-контексту, що стоїть за реалізаціями
З часом сама система більше не містить повного обґрунтування того, як вона була побудована. Критичний бізнес-контекст, архітектурні припущення та операційні знання все ще переважно існують у людських судженнях та розрізнених розмовах, а не в самій платформі.
“Vibe coding” робить реалізацію значно швидшою, але з точки зору системи, загальна ефективність розробки не покращується пропорційно, оскільки значна частина життєвого циклу розробки все ще залежить від людської валідації, доменних знань, координації та прийняття рішень.
Що ще важливіше, запити не є природно ітерованими артефактами розробки. Корпоративні системи постійно розвиваються через релізи, зміни схем даних, оновлення бізнес-логіки та залежності подальших систем. Команди неодноразово повертаються до систем і вдосконалюють їх з часом, але запити оптимізовані для швидкої локальної генерації, а не для довгострокового еволюційного розвитку системи.
Їх важко:
-
послідовно контролювати версії
-
систематично валідувати
-
повторно використовувати між командами
-
координувати через робочі процеси CI/CD
-
поступово розвивати з часом
Навіть один і той самий запит може не гарантувати надійну генерацію однієї й тієї ж реалізації з різним контекстом у майбутньому.
Саме тут SDD починає займати центральне місце в розробці даних за допомогою ШІ. Замість того, щоб залишати операційні знання розсіяними між запитами та розмовами, SDD інтегрує бізнес-контекст, логіку валідації, поведінку трансформації, вимоги оркестрації та робочі процеси реалізації безпосередньо у виконувані специфікації, які стають частиною самої системи.
Система тепер має постійну пам’ять про те, як вона була розроблена, чому були зроблені певні рішення та як різні компоненти пов’язані між собою на платформі. Це дозволяє командам та ШІ-агентам надійніше ітерувати системи з часом, зменшуючи фрагментацію в середовищах, що все більше генеруються за допомогою ШІ.
VB Transform · 14–15 липня · Менло-Парк · Агентна оркестрація
Intuit переробила свою мультиагентну систему за 60 днів. Що вони змінили — і чому?
На Transform лідери інженерії з Intuit, Target та Instacart розбирають, як вони перепроектували свої архітектури оркестрації для надійності, масштабу та реальних клієнтів.
Дивіться повний порядок денний →
Розробка, керована специфікаціями, перетворює запити на системну пам’ять
У SDD системи будуються навколо виконуваних специфікацій, а не лише на основі нечітко скоординованих запитів та реалізацій. Замість того, щоб розглядати специфікації як пасивну документацію, написану після розробки, SDD розглядає їх як операційні контракти, які безпосередньо керують робочими процесами генерації коду, валідації, тестування, оркестрації та розгортання.
Багато в чому SDD поширює ідеї з “Інфраструктури як коду” (Infrastructure-as-Code) та GitOps на розробку за допомогою ШІ. Специфікації поєднують декларативні системні визначення з виконуваними робочими процесами реалізації. Декларативний шар надає системний контекст, схеми, залежності, обмеження та операційні вимоги, тоді як інструкції, орієнтовані на робочі процеси, керують ШІ-агентами щодо послідовної реалізації та еволюції системи.
Після того, як ці контексти, правила та шаблони реалізації будуть перетворені на постійні контракти з контролем версій, що зберігаються в репозиторіях та інтегровані в робочі процеси CI/CD, система стане значно більш ітеративною та керованою з часом. Ці специфікації фактично стають довгостроковою системною пам’яттю як для людей, так і для ШІ-агентів, дозволяючи системам послідовно розвиватися між релізами, командами та робочими процесами, де все більше допомагає ШІ.
На практиці структура специфікацій значною мірою залежить від типу систем та робочих процесів, що реалізуються. Однак, системи, керовані специфікаціями, часто починаються з фундаментальної “конституції”, яка визначає загальнопроєктні принципи та обмеження, що мають залишатися послідовними на всій платформі, такі як стандарти технологій, конвенції найменування, архітектурні правила, політики управління та основні системні вимоги. Поверх цієї основи, численні рівні специфікацій служать різним операційним цілям протягом життєвого циклу розробки:
-
специфікації схем визначають структурну сумісність
-
специфікації трансформацій визначають бізнес-логіку
-
специфікації валідації визначають правила якості
-
специфікації оркестрації визначають поведінку виконання
-
семантичні специфікації визначають спільні бізнес-визначення
-
специфікації робочих процесів ШІ визначають повторно використовувані інструкції з реалізації для кодуючих агентів
Спрощена специфікація може виглядати так:
pipeline_spec:
source:
system: mysql
table: order
transformation:
logic:
– load_strategy: scd2
target:
platform: snowflake
table: dim_order
validation:
primary_key: order_id
Додаткові файли робочих процесів потім можуть надавати повторно використовувані інструкції для кодуючих агентів:
-
Згенерувати Python-код для прийому даних клієнтів Salesforce.
-
Згенерувати DBT-моделі, що реалізують логіку Type 2 SCD.
-
Згенерувати робочі процеси Airflow для погодинного виконання.
-
Згенерувати тести валідації для сумісності з подальшими системами.
Ці специфікаційні документи часто зберігаються як операційні артефакти на основі markdown, що генеруються та вдосконалюються через робочі процеси за допомогою ШІ. Інженери можуть ітеративно оновлювати специфікації, надавати додатковий бізнес-контекст та співпрацювати з кодуючими агентами для покращення логіки реалізації, робочих процесів та інструкцій запитів з часом. Порівняно з традиційними процесами документації, генерація специфікацій за допомогою ШІ значно швидша та адаптивніша.
Важлива зміна полягає не просто в кращій документації. Специфікації стають повторно використовуваним операційним контекстом, який дозволяє системам послідовно розвиватися між релізами, командами та робочими процесами, керованими ШІ. Архітектурний задум, бізнес-припущення та логіка реалізації більше не зникають у тимчасових запитах та непов’язаних реалізаціях, а натомість стають постійними системними знаннями, інтегрованими безпосередньо в життєвий цикл розробки.
Чому розробка, керована специфікаціями, особливо підходить для розробки даних
Теоретично, SDD може застосовуватися в багатьох галузях програмної інженерії, але розробка даних особливо добре підходить для цієї моделі через природу сучасних платформ даних.
Корпоративні системи даних природно охоплюють багато взаємопов’язаних технологій та рівнів, включаючи транзакційні системи, фреймворки прийому даних, потокові платформи, сховища даних, системи оркестрації, семантичні рівні, API, інформаційні панелі та ML-конвеєри. Інженери даних регулярно працюють з довгими технологічними стеками та розподіленими системами, де одна вихідна зміна може вплинути на багатьох споживачів подальших систем.
Корпоративні платформи даних також підтримують багато різних команд та додатків у фрагментованих середовищах. Оскільки системи розвиваються незалежно, розуміння повного впливу зміни схеми даних або бізнес-логіки на подальші системи стає все складнішим. Здавалося б, незначна модифікація може непомітно зламати конвеєри даних, інформаційні панелі, API, семантичні моделі або робочі процеси машинного навчання на всій платформі.
SDD може вирішити цю фрагментацію шляхом введення спільних операційних контрактів з контролем версій для різних систем. Оскільки схеми даних, залежності, правила валідації, логіка трансформації та поведінка оркестрації явно визначені в специфікаціях, команди та ШІ-агенти отримують значно кращу видимість щодо того, як системи пов’язані між собою та як зміни поширюються платформою.
Крім того, мета розробки даних – це не просто швидка доставка конвеєрів. Команди також повинні оптимізувати стабільність системи, масштабованість, узгодженість, ремонтопридатність, операційну надійність та вартість інфраструктури.
Це вимагає значної роботи з проєктування системи та рішень від інженерів. Команди повинні ретельно визначати технологічний стек, створювати схеми даних, шаблони трансформації, поведінку оркестрації, правила валідації, стратегії зберігання та вимоги до сумісності з подальшими системами на всій платформі.
Однак, після встановлення цих архітектурних та операційних шаблонів, значна частина роботи з реалізації стає високо повторюваною та стандартизованою.
Наприклад, після визначення повторно використовуваного шаблону прийому та трансформації даних клієнтів Salesforce, додавання нової таблиці може вимагати лише додавання визначення таблиці до специфікації, тоді як решта реалізації може бути згенерована автоматично через існуючі специфікації та робочі процеси, що дотримуються того ж операційного шаблону:
source:
system: salesforce
tables:
– customer
– order
– product
Лише з цієї специфікації кодуючі агенти могли б генерувати нові конвеєри даних, дотримуючись того ж керованого шаблону реалізації на всій платформі. Це поєднання людського проєктування архітектури та високо повторюваних робочих процесів реалізації робить розробку даних особливо придатною для SDD.
Багато в чому розробка даних завжди рухалася до вищих рівнів автоматизації, від ETL-фреймворків та конвеєрів, керованих метаданими, до IaC та декларативних систем оркестрації. SDD представляє собою ще один крок у цій еволюції, поєднуючи генерацію на основі запитів за допомогою ШІ з детермінованими контрактами з контролем версій.
Замість повної залежності від тимчасових розмовних запитів або жорстких шаблонних систем, SDD запроваджує проміжний рівень, де повторно використовувані специфікації надають структуру, координацію, валідацію та постійну системну пам’ять для розробки за допомогою ШІ.
Як SDD змінює розробку даних за допомогою ШІ
SDD запроваджує значно вищий рівень автоматизації в корпоративну розробку даних, одночасно допомагаючи зменшити проблеми фрагментації, з якими все частіше стикаються сучасні платформи даних.
Оскільки схеми даних, бізнес-правила, поведінка трансформації, вимоги оркестрації, логіка валідації та залежності подальших систем явно визначені в повторно використовуваних специфікаціях, кодуючі агенти можуть послідовно генерувати та еволюціонувати великі частини реалізації на всій платформі. Замість того, щоб неодноразово перебудовувати конвеєри та робочі процеси з тимчасових запитів та непов’язаного контексту, команди можуть ітерувати системи через спільні операційні контракти та повторно використовувані шаблони реалізації.
Це значно покращує послідовність, відстежуваність та координацію в розподілених середовищах. Еволюція схеми даних стає легшою в управлінні, вплив на подальші системи стає більш видимим, а системи можуть еволюціонувати поступово, а не через непов’язані генерації реалізацій.
Водночас, людські інженери залишаються незамінними в життєвому циклі розробки. Хоча ШІ-агенти можуть автоматизувати значну частину роботи з реалізації, людські судження залишаються критично важливими для визначення бізнес-логіки, проєктування архітектур, управління компромісами, валідації коректності та координації еволюції системи в межах організацій.
Зі збільшенням обсягу роботи з реалізації, яка генерується ШІ, роль розробки даних також починає змінюватися. Інженери витрачають менше часу на написання повторюваних конвеєрів та логіки оркестрації, і більше часу на визначення специфікацій, проєктування повторно використовуваних операційних шаблонів, управління правилами валідації та координацію бізнес-контексту між системами.
Це також може поступово зменшити деякі традиційні межі між різними командами розробки даних. Оскільки реалізація стає все більш стандартизованою та керованою ШІ через спільні специфікації, організації можуть менше покладатися на високосилосні команди з реалізації, специфічні для конкретних платформ, і більше на спільні операційні контракти та повторно використовувані системні шаблони.
Зрештою, SDD переводить розробку даних у бік більш орієнтованої на специфікації та систему моделі, де люди зосереджуються на намірах, архітектурі та бізнес-координації, тоді як ШІ-агенти все більше займаються реалізацією, тестуванням та операційною генерацією у масштабі.
Шухуа Сюй — провідний інженер даних.
Ласкаво просимо до спільноти VentureBeat!
Наша програма гостьових публікацій — це місце, де технічні експерти діляться своїми знаннями та надають нейтральні, неупереджені глибокі аналізи щодо ШІ, інфраструктури даних, кібербезпеки та інших передових технологій, що формують майбутнє підприємств.
Читайте більше з нашої програми гостьових публікацій — і ознайомтеся з нашими рекомендаціями, якщо ви зацікавлені у внесенні свого внеску!
Як захиститися (Порада CryptoDom): Не покладайтеся виключно на запити (prompts) для критично важливих систем. Завжди перетворюйте результати роботи ШІ-агентів на формалізовані специфікації та контракти з контролем версій, які стають частиною вашої системи. Регулярно переглядайте та оновлюйте ці специфікації, щоб вони відображали поточні бізнес-вимоги та архітектурні рішення.
За матеріалами: venturebeat.com