Для инженеров по обработке данных инструмент AI code agent — настоящая революция в эффективности. Достаточно ввести несколько подсказок в диалоговом окне — и AI agent сможет автоматически создавать сложную логику преобразования данных, конвейеры передачи данных, организацию рабочих процессов, проверочные тесты и даже файлы конфигурации базовой инфраструктуры.
Такой подход к разработке, который во многом опирается на взаимодействие между интуицией и подсказками, — очень популярный в технологическом сообществе метод атмосферного кодирования (Vibe Coding). Однако, когда инженеры и компании увлекаются эффективной разработкой, за этим скрываются многочисленные проблемы.
Например, платформы обработки данных корпоративного уровня никогда не были единым и простым приложением — обычно они объединяются в бесчисленные децентрализованные системы. Эти системы часто управляются разными командами и построены на совершенно разных технологических решениях.
Поскольку многие системы на предприятии развиваются независимо, компании начинают сталкиваться со сложными проблемами: несогласованностью бизнес‑логики, многократным внедрением схожих функций в разных местах, чрезвычайно сложным анализом влияния нижестоящих систем. При этом вся платформа обработки данных полна скрытых зависимостей.
Однако появление атмосферного кодирования не только не решило вышеупомянутые проблемы, но и может бесконечно их усугубить.
В конце концов, когда всё больше операционного контекста, архитектурных решений и бизнес‑знаний перестают вписываться в системную архитектуру и рассеиваются в подсказках искусственного интеллекта, диалоговых записях и генерируемом по частям коде, система неизбежно выйдет из‑под контроля.
Слово‑подсказка — по сути «одноразовый продукт».
Нельзя отрицать, что атмосферное кодирование чрезвычайно эффективно для быстрого создания отдельных и независимых функций. Но компании и разработчики должны понимать: подсказки — это по сути очень недолговечные «одноразовые продукты». Даже идеальная подсказка может отразить лишь различные предположения инженера, его бизнес‑опыт, логику внедрения и системные знания на тот момент.
В реальных сценариях разработки, чтобы агенты ИИ могли по‑настоящему эффективно работать и внедряться в формальную среду для содействия работе предприятия, инженеры должны постоянно дополнять ИИ различной справочной информацией. В неё входят причины принятия решений, связанных с архитектурой системы, специальными бизнес‑правилами, предположениями о структуре данных (схеме) и последующими ограничениями на системную зависимость, специальные эксплуатационные спецификации, прошлая история отладки и различные рекомендации по внедрению. Эти контексты, скрытые в глубине диалога, — на самом деле наиболее важные и ценные оперативные знания, лежащие в основе разработки с использованием искусственного интеллекта.
Но из‑за этого и произошла катастрофа. В большинстве рабочих процессов, связанных с программированием ИИ, эта важная информация в конечном итоге оказывается разбросана повсюду. Она может присутствовать в историческом диалоге между инженером и ChatGPT, или случайно записана в заявке на выполнение задачи, или зафиксирована в общем документе, который никто не будет обновлять, или даже скрыта в абзацах кода, созданных с помощью искусственного интеллекта, но без аннотаций, — и не стала частью самой системы.
Такая ситуация таит в себе огромную скрытую угрозу для разработки корпоративных данных. Современные платформы обработки данных представляют собой крайне взаимосвязанную и сложную экосистему. Поток данных пройдёт через конвейеры импорта, хранилища данных, структуры управления рабочими процессами, семантические уровни, интерфейсы прикладного программирования (API), визуальные панели мониторинга и, наконец, все необходимые инструменты на пути в систему машинного обучения.
Исчезающая видимость системы
Когда основная логика и базовые знания всё больше будут заключены в словах‑подсказках и коде, созданном с помощью искусственного интеллекта, компании постепенно утратят представление о системе — словно лягушки, сваренные в тёплой воде.
Со временем корпоративная команда забудет, с какой целью изначально структурировали ту или иную программу или функцию. Будет непонятно, какие поля нужно изменить, какие последующие зависимости окажутся затронуты и почему вообще потребовалось установить определённые допущения для проверки. Невозможно будет предсказать, как система поведёт себя в тех или иных обстоятельствах, не говоря уже о сложном бизнес‑контексте, скрытом за внедрением.
Поскольку система больше не будет содержать полного процесса рассуждения о том, почему она была спроектирована именно так, ключевые бизнес‑знания, архитектурные допущения и операционные знания могут сохраняться лишь в памяти инженеров или в разрозненных беседах, которые долгое время было невозможно отыскать, а не быть надёжно закреплёнными на платформе данных.
Вышеописанное состояние порождает крайне противоречивое явление: хотя кодирование действительно ускоряет начальное внедрение, с макроуровневой точки зрения общая эффективность проектирования не растёт пропорционально. В течение длительного жизненного цикла программного обеспечения команде разработчиков по‑прежнему придётся тратить много времени на проверку, восстановление знаний в предметной области, межведомственную координацию и повторное принятие решений.
Не может быть версионным и не может быть проверено одновременно
Более серьёзное техническое препятствие состоит в том, что командные строки по своей сути не являются инженерным продуктом, пригодным для непрерывной итерации. В конце концов, корпоративные системы — это «живые существа»: им нужно развиваться при обновлении версий, изменении структуры данных, корректировке бизнес‑логики и изменениях в последующих зависимостях.
Инженерная команда предприятия должна постоянно модифицировать и совершенствовать систему в течение длительного времени, но изначальная цель prompt word — обеспечить быстрое создание компонентов, а не долгосрочную эволюцию системы.
Судя по текущей ситуации, предприятиям сложно согласованно контролировать версии подсказок ИИ и систематически проверять их код. Подсказки нелегко повторно использовать разным командам, ещё сложнее интегрировать их в непрерывную интеграцию и непрерывное развёртывание (CI/CD) — автоматизацию рабочего процесса, необходимую для современной разработки программного обеспечения.
Даже если в будущем будут введены те же самые слова в подсказках, при малейших отличиях в контексте или версии модели искусственного интеллекта предприятие и команда разработчиков не смогут гарантировать, что ИИ обеспечит точно такие же результаты внедрения, как и раньше.
Столкнувшись с вышеуказанными дилеммами, концепция разработки на основе спецификаций (SDD) начала проявляться и постепенно стала основным решением для разработки данных с использованием искусственного интеллекта.
Интегрируйте всё в исполняемые файлы спецификаций
Концепция SDD предельно ясна. Вместо того чтобы распределять ценные операционные знания по подсказкам и диалоговым записям, лучше проявить инициативу и интегрировать бизнес‑контекст, логику проверки, поведение при преобразовании, требования к оркестровке и рабочий процесс внедрения непосредственно в «исполняемый файл спецификации», создав эти спецификации — незаменимую часть системы.
Таким образом, система наконец обладает долговременной памятью. Она будет чётко помнить, как она была спроектирована в первую очередь, почему были приняты некоторые сложные компромиссные решения и как различные компоненты платформы последовательно соединены друг с другом.
Наличие спецификаций дало командам людей и агентам искусственного интеллекта прочную основу, которая позволит им более надёжно выполнять итерации системы в будущем, одновременно значительно снижая всё более серьёзную проблему фрагментации в децентрализованной среде обработки данных.
В концепции SDD построение системы будет основываться на «исполняемых спецификациях», а не просто полагаться на разрозненные согласованные подсказки или код, сгенерированный искусственным интеллектом.
Традиционная разработка программного обеспечения часто рассматривает спецификацию как пассивный документ — то есть запись о передаче, которая едва формируется после написания программы. Но SDD полностью перевернула эту концепцию. Она рассматривает документ о спецификации как обязательный «операционный контракт». Эти контракты будут напрямую стимулировать ИИ к генерации кода, логической проверке, системному тестированию, согласованию процессов и окончательному развёртыванию.
Во многих отношениях SDD фактически идеально дополняет популярные концепции «Инфраструктура как код» (IaC) и «GitOps» в облачной архитектуре в области проектирования с использованием искусственного интеллекта.
Дополните устав и превратите его в непреходящее знание.
На практике типичная система, основанная на спецификации, обычно начинается с разработки «устава», который устанавливает принципы на уровне проекта и жёсткие ограничения, включая технические стандарты, соглашения об именовании, архитектурные правила, политику управления информационной безопасностью и основные системные требования.
Поверх устава будут размещены документы‑спецификации нескольких уровней, каждый из которых отвечает за различные операционные функции: общие спецификации определяют совместимость структур данных, спецификации преобразования — бизнес‑логику, спецификации проверки — качество данных, порядок выполнения определений спецификаций, семантические спецификации — для обеспечения межведомственного обмена бизнес‑определениями, спецификации рабочих процессов ИИ представляют собой многократно используемые инструкции по внедрению, специально написанные для ознакомления агентов ИИ.
Эти технические документы обычно написаны на упрощённых языках тегов, таких как Markdown, и могут быть быстро сгенерированы и постоянно обновляться с помощью искусственного интеллекта. Настоящая цель состоит не только в том, чтобы написать более качественные документы, но и в том, чтобы архитектурный замысел, бизнес‑предположения и логика реализации больше не исчезали в кратких словах, которые теряются при использовании, а превратились в прочные системные знания, встроенные во весь жизненный цикл разработки.
Используйте достаточную прозрачность, чтобы избежать эффекта бабочки.
Хотя SDD может быть применён в любой области разработки программного обеспечения, разработка данных стала наиболее подходящим сценарием для внедрения из‑за своей уникальной природы.
Системы обработки данных корпоративного уровня охватывают множество взаимосвязанных технических уровней. Инженерам по обработке данных приходится одновременно работать с транзакционными системами, платформами потоковой передачи, хранилищами данных, системами оркестрации, API, информационными панелями и конвейерами машинного обучения. Любое изменение в вышестоящих системах может вызвать эффект бабочки без предупреждения — всего одно изменение имени поля может незаметно привести к сбою в нижестоящих системах: конвейерах, информационных панелях, внешних API и даже в основных рабочих процессах прогнозирования.
SDD решает эту проблему путём импорта и совместного использования операционных контрактов между системами с контролем версий. Когда все схемы данных, зависимости, правила проверки и логика преобразования чётко определены в файле спецификации, и команда специалистов, и агент искусственного интеллекта могут ясно видеть, как связаны узлы системы и как изменения будут распространяться по конвейеру.
Поощряйте инженеров обращаться к архитектурному проектированию.
Инженерная команда разработчиков должна найти баланс между стабильностью системы, возможностью расширения, сопровождения и затратами на инфраструктуру — это требует значительных усилий по архитектурному проектированию. Суть в том, что после создания структуры и операционной модели большая часть последующей реализации представляет собой весьма повторяющуюся и кропотливую работу.
SDD как раз подходит для этой задачи. Например, в случае с последовательными данными CRM: когда режим импорта и преобразования разработан, а в будущем будет добавлена новая спецификация, инженеру нужно лишь добавить новое определение в файл спецификации — и агент искусственного интеллекта автоматически сгенерирует код импорта на Python, модель преобразования и рабочий процесс планирования, а также проведёт последующие проверочные испытания в соответствии с существующими техническими требованиями. Люди руководят архитектурой, а искусственный интеллект отвечает за реализацию. Такое разделение труда делает разработку данных наиболее подходящей областью для внедрения SDD.
Ориентированный на технические характеристики для устранения эффекта амбара.
Даже если агенты искусственного интеллекта могут автоматизировать большую часть процесса внедрения, суждения инженеров-людей по‑прежнему незаменимы: определение сложной бизнес‑логики, проектирование архитектуры системы, принятие решений о технических компромиссах, проверка корректности системы и координация межведомственного развития по‑прежнему остаются основными обязанностями людей.
По мере того как искусственный интеллект будет генерировать всё больше деталей реализации, роль инженеров будет смещаться с написания повторяющихся конвейеров на определение спецификаций, разработку повторяемых бизнес‑моделей и координацию бизнес‑контекстов. Будущее, на которое указывает SDD, заключается в том, что люди будут сосредотачиваться на замысле и архитектуре, а искусственный интеллект — отвечать за всю реализацию, тестирование и разработку операций в масштабе.
Рекомендуемое чтение
◆ Финансовая индустрия делает ставку на искусственный интеллект: от реструктуризации платёжных процессов до кредитования — какие проблемы управления стоят за этой революцией в области повышения эффективности?
◆ Когда ИИ коммерциализирует профессиональные знания, каковы отличительные преимущества предприятий? Наделла сказала, что ответ кроется в «цикле обучения».
◆ [От времени продажи к результатам продажи] В рамках корректировки структуры заработной платы McKinsey искусственный интеллект способствует пересмотру бизнес‑модели индустрии услуг, основанной на знаниях.
＊Эта статья открыта для перепечатки партнёрами, справочные материалы: VentureBeat, InfoWorld, источник первой картинки: здесь
(Ответственный редактор: Цзоу Цзяянь)
Подписаться в Макс
