Спецификационно-ориентированная разработка в области инженерии данных ИИ

ИИ-агенты для написания кода стремительно ускоряют инженерию данных, генерируя из промптов трансформации, конвейеры, рабочие процессы оркестрации, тесты валидации и конфигурации инфраструктуры.

Тем не менее, корпоративные платформы данных долгое время функционируют в условиях фрагментированных систем, принадлежащих разным командам и построенным на различных технологиях. По мере того как эти системы развиваются независимо друг от друга, организации всё чаще сталкиваются с несогласованной бизнес-логикой, дублированием реализаций, сложным анализом влияния изменений на нисходящие компоненты и скрытыми зависимостями внутри платформы.

Рост «вайб-кодинга» (vibe coding) может ещё больше усугубить эти проблемы, поскольку всё бо́льшая часть операционного контекста, архитектурных решений и бизнес-знаний оказывается разбросана по промптам, беседам, сгенерированному коду и несвязанным рабочим процессам, вместо того чтобы становиться частью самой системы.

Разработка на основе спецификаций (Spec-driven development, SDD) становится одним из подходов к решению этой задачи. При SDD промпты, бизнес-правила, логика валидации, поведение оркестрации и рабочие процессы реализации преобразуются в исполняемые и версионируемые спецификации, которые становятся частью самой системы. Эти спецификации выступают в роли постоянной операционной памяти как для людей, так и для ИИ-агентов, позволяя системам развиваться более согласованно в рамках разных релизов, команд и рабочих процессов с поддержкой искусственного интеллекта.

Поскольку инженерия корпоративных данных уже во многом опирается на повторно используемые паттерны, конвейеры на основе метаданных и стандартизированные рабочие процессы, она особенно хорошо подходит для SDD. Объединяя генерацию с помощью ИИ с детерминированными и многократно используемыми системными контрактами, SDD может предоставить новый операционный уровень для снижения фрагментации и улучшения долгосрочной координации на всё более ориентированных на ИИ платформах данных.

Вайб-кодинг сам по себе лишён постоянной системной памяти

Вайб-кодинг работает удивительно хорошо для быстрой генерации изолированных реализаций. Но промпты по своей природе временны. Они фиксируют предположения инженера, бизнес-контекст, логику реализации и системные знания только для конкретной беседы и данного момента времени.

На практике обеспечение работоспособности систем, созданных с помощью ИИ, часто требует гораздо большего, чем просто один промпт. Инженеры на протяжении всего процесса разработки непрерывно предоставляют фоновую информацию, архитектурные решения, бизнес-правила, предположения о схемах, нисходящие зависимости, операционные ограничения, историю отладки и руководства по реализации.

Именно этот контекст формирует реальные операционные знания, лежащие в основе разработки с поддержкой ИИ.

Однако в большинстве рабочих процессов вайб-кодинга эта информация остается разрозненной — она распределена по промптам, беседам, тикетам в Jira, документации, истории чатов, сгенерированному коду и несвязанным процессам, вместо того чтобы стать частью самой системы.

Это создает серьезную проблему для инженерии корпоративных данных, поскольку современные платформы данных естественным образом фрагментированы между множеством взаимосвязанных систем, включая конвейеры загрузки, хранилища данных, фреймворки оркестрации, семантические слои, API, дашборды и системы машинного обучения (МО). По мере того как всё бо́льшая часть логики и контекста внедряется внутрь промптов и сгенерированных реализаций, организации постепенно теряют понимание:

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

Вайб-кодинг делает реализацию значительно быстрее, но с системной точки зрения общая эффективность инженерной работы не возрастает пропорционально, поскольку бо́льшая часть жизненного цикла разработки по-прежнему зависит от ручной валидации, предметных знаний, координации и принятия решений.

Что еще важнее, промпты не являются естественными итеративными инженерными артефактами. Корпоративные системы непрерывно развиваются от релиза к релизу, претерпевают изменения схем, обновление бизнес-логики и затрагивают нисходящие зависимости. Команды многократно возвращаются к системам и дорабатывают их с течением времени, однако промпты оптимизированы для быстрой локальной генерации, а не для долгосрочной эволюции систем.

Их сложно:

Даже один и тот же промпт в будущем может не гарантировать создание идентичной реализации при другом контексте.

Именно здесь подход SDD начинает занимать центральное место в инженерии данных с поддержкой ИИ. Вместо того чтобы оставлять операционные знания разбросанными по промптам и беседам, SDD интегрирует бизнес-контекст, логику валидации, поведение трансформаций, требования к оркестрации и рабочие процессы реализации непосредственно в исполняемые спецификации, которые становятся частью самой системы.

Теперь система обладает постоянной памятью о том, как она была спроектирована, почему были приняты те или иные решения и как различные компоненты связаны между собой на уровне платформы. Это позволяет командам и ИИ-агентам более надежно и итеративно развивать системы с течением времени, одновременно снижая фрагментацию в разрозненных средах данных.

Разработка на основе спецификаций превращает промпты в системную память

В рамках 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

Дополнительные файлы рабочих процессов могут затем предоставлять повторно используемые инструкции по реализации для кодирующих агентов:

1. Сгенерировать код на Python для загрузки клиентских данных из Salesforce.

2. Сгенерировать модели DBT, реализующие логику SCD Типа 2.

3. Сгенерировать рабочие процессы Airflow для ежечасного выполнения.

4. Сгенерировать тесты валидации для проверки нисходящей совместимости.

Эти документы со спецификациями часто поддерживаются в виде операционных артефактов на базе Markdown, которые генерируются и дорабатываются в ходе рабочих процессов с участием ИИ. Инженеры могут итеративно обновлять спецификации, добавлять бизнес-контекст и сотрудничать с кодирующими агентами для совершенствования логики реализации, рабочих процессов и инструкций для промптов с течением времени. По сравнению с традиционными процессами документирования, генерация спецификаций с помощью ИИ происходит значительно быстрее и обладает большей адаптивностью.

Главный сдвиг заключается не просто в улучшении документации. Спецификации становятся повторно используемым операционным контекстом, который позволяет системам согласованно развиваться в рамках релизов, команд и рабочих процессов с поддержкой ИИ. Архитектурный замысел, бизнес-предположения и логика реализации больше не растворяются во временных промптах и разорозненных решениях, а превращаются в постоянные системные знания, интегрированные непосредственно в жизненный цикл разработки.

Почему разработка на основе спецификаций идеально подходит именно для инженерии данных

Теоретически SDD может применяться во многих областях разработки программного обеспечения, но инженерия данных особенно хорошо подходит для этой модели из-за специфики современных платформ данных.

Корпоративные системы данных естественным образом охватывают множество взаимосвязанных технологий и слоев, включая транзакционные системы, инфраструктуру загрузки, потоковые платформы, хранилища данных, системы оркестрации, семантические слои, API, дашборды и конвейеры машинного обучения. Инженеры данных регулярно работают со сложными технологическими стеками и распределенными системами, где одно изменение на верхнем уровне (upstream) может повлиять на множество потребителей на нижнем уровне (downstream).

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

SDD может решить эту проблему фрагментации путем внедрения общих и версионируемых операционных контрактов между системами. Поскольку схемы, зависимости, правила валидации, логика трансформаций и поведение оркестрации явно описаны в спецификациях, команды и ИИ-агенты получают гораздо лучшую прозрачность в отношении того, как связаны системы и как изменения распространяются по платформе.

Кроме того, целью инженерии данных является не просто быстрое создание конвейеров. Команды также должны заботиться о стабильности систем, масштабируемости, согласованности, простоте поддержки, операционной надежности и стоимости инфраструктуры.

Это требует от инженеров серьезной работы по проектированию систем и решений. Команды должны тщательно определять стек технологий, создавать схемы, паттерны трансформаций, поведение оркестрации, правила валидации, стратегии хранения и требования к нисходящей совместимости на всей платформе.

Однако после того, как эти архитектурные и операционные паттерны установлены, бо́льшая часть работы по реализации становится высоко повторяемой и стандартизированной.

Например, после определения многократно используемого шаблона загрузки и трансформации для клиентских данных Salesforce, подключение новой таблицы может потребовать лишь добавления еще одного определения таблицы в спецификацию, в то время как оставшаяся реализация может быть сгенерирована автоматически с помощью существующих спецификаций и рабочих процессов, следующих тому же операционному паттерну:

source:

  system: salesforce

  tables:

    — customer

    — order

    — product

Только на основе этой спецификации кодирующие агенты могут генерировать новые конвейеры данных, следующие единому регламентированному шаблону реализации на всей платформе. Такое сочетание архитектурного проектирования человеком и высокоповторяемых рабочих процессов реализации делает инженерию данных особенно подходящей для SDD.

Во многом инженерия данных всегда двигалась в сторону более высокого уровня автоматизации: от ETL-фреймворков и конвейеров на основе метаданных до IaC и декларативных систем оркестрации. SDD представляет собой очередной шаг в этой эволюции, объединяя генерацию с помощью ИИ на основе промптов с детерминированными и версионируемыми операционными контрактами.

Вместо того чтобы полагаться исключительно на временные диалоговые промпты или жесткие шаблоны, SDD внедряет промежуточный слой, где повторно используемые спецификации обеспечивают структуру, координацию, валидацию и постоянную системную память для разработки с поддержкой ИИ.

Как SDD меняет инженерию данных с поддержкой ИИ

SDD привносит гораздо более высокий уровень автоматизации в инженерию корпоративных данных, одновременно помогая снизить проблемы фрагментации, с которыми всё чаще сталкиваются современные платформы данных.

Поскольку схемы, бизнес-правила, логика трансформаций, требования оркестрации, правила валидации и нисходящие зависимости явно прописаны в повторно используемых спецификациях, кодирующие агенты могут генерировать и развивать значительную часть реализации согласованно в рамках всей платформы. Вместо того чтобы заново выстраивать конвейеры и рабочие процессы из временных промптов и несвязанного контекста, команды могут итеративно улучшать системы через общие операционные контракты и повторно используемые шаблоны реализации.

Это существенно повышает согласованность, прослеживаемость и координацию в распределенных средах. Управлять эволюцией схем становится проще, влияние изменений на нисходящие компоненты — нагляднее, а сами системы могут развиваться поступательно, а не через смену изолированных поколений реализаций.

При этом человеческие инженеры по-прежнему остаются неотъемлемой частью жизненного цикла разработки. Хотя ИИ-агенты могут автоматизировать значительную часть работы по реализации, человеческое суждение критически важно для определения бизнес-логики, проектирования архитектур, поиска компромиссов, проверки корректности и координации эволюции систем в масштабах организации.

По мере того как всё бо́льшая часть работы по реализации начинает генерироваться ИИ, роль инженерии данных также претерпевает изменения. Инженеры тратят меньше времени на написание повторяющихся конвейеров и логики оркестрации, и больше — на определение спецификаций, проектирование повторно используемых операционных паттернов, управление правилами валидации и координацию бизнес-контекста между системами.

Это также может постепенно стереть некоторые из традиционных границ между различными командами инженеров по данным. Поскольку реализация становится всё более стандартизированной и поддерживаемой ИИ через общие спецификации, организации могут меньше зависеть от изолированных команд реализации под конкретные платформы и в большей степени опираться на общие операционные контракты и многократно используемые системные паттерны.

В конечном счете SDD смещает инженерию данных в сторону более ориентированной на спецификации и систему модели, где люди сосредотачиваются на намерениях, архитектуре и бизнес-координации, в то время как ИИ-агенты всё больше берут на себя реализацию, тестирование и операционную генерацию в масштабе.

Шухуа Сюй — ведущий инженер по данным.

Добро пожаловать в сообщество VentureBeat!

Наша программа гостевых публикаций предназначена для технических экспертов, которые делятся своими идеями и представляют нейтральные, непредвзятые экспертные материалы об искусственном интеллекте, инфраструктуре данных, кибербезопасности и других передовых технологиях, формирующих будущее бизнеса.

Читайте далее в рамках нашей программы гостевых постов и ознакомьтесь с нашими рекомендациями если вы хотите опубликовать собственную статью!