Программирование в стиле Vibe может помочь построить ваш конвейер обработки данных. Но оно не сможет объяснить его через полгода.

Шухуа Сюй

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

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

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

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

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

Одного лишь Vibe-кодирования недостаточно для обеспечения постоянной работы системы через память.

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

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

Эти контексты становятся реальными оперативными знаниями, лежащими в основе разработки с использованием ИИ.

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

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

• архитектурный замысел

• нижестоящие зависимости

• предположения проверки

• оперативное поведение

• бизнес-контекст, лежащий в основе внедрения

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

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

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

Им сложно:

• версия согласованно

• систематически проверять

• повторное использование в разных командах

• координация посредством рабочих процессов CI/CD

• эволюционировать постепенно с течением времени

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

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

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

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

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

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

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

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

• Спецификации схемы определяют структурную совместимость.

• Спецификации преобразований определяют бизнес-логику.

• Спецификации валидации определяют правила качества.

• Спецификации оркестровки определяют поведение при выполнении.

• Семантические спецификации определяют общие бизнес-определения.

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

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

pipeline_spec:

источник:

система: mysql

таблица: заказ

трансформация:

логика:

— load_strategy: scd2

цель:

платформа: снежинка

таблица: dim_order

валидация:

primary_key: order_id

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

1. Сгенерируйте код на Python для импорта данных о клиентах Salesforce.

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

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

4. Сгенерируйте проверочные тесты для обеспечения совместимости с последующими версиями.

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

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

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

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

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

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

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

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

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

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

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

система: Salesforce

таблицы:

— клиент

— заказ

— продукт

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

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

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

Как SDD меняет подход к проектированию данных с использованием ИИ

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

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

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

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

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

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

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

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

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

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

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

Подпишитесь, чтобы получать самые свежие новости!

Подробные аналитические данные для руководителей предприятий в области искусственного интеллекта, данных и безопасности.

VB Daily AI Weekly Еженедельник AGI Еженедельник по безопасности Еженедельник по инфраструктуре данных Мероприятия VB Все они

Отправляя свой адрес электронной почты, вы соглашаетесь с нашими Условиями использования и Политикой конфиденциальности.

Получайте обновления ! Вы подписаны! Наши последние новости скоро поступят на вашу электронную почту.

Источник: venturebeat.com