<рисунок><img src="https://techorange.com/app/uploads/2026/06/41bd3bdb91b900f5-720x405.jpg "alt="Атмосферное кодирование ускоряет первоначальную разработку, но оперативные знания разрозненны, и SDD становится новым решением для разработки данных с использованием искусственного интеллекта"/></рисунок>
<p class="wp-block-paragraph">Для инженеров по обработке данных инструмент AI code proxy обеспечивает настоящую революцию в эффективности. Достаточно ввести несколько подсказок в диалоговом окне — и AI proxy может автоматически генерировать сложную логику преобразования данных, конвейеры обработки данных, организацию рабочего процесса, проверочные тесты и даже файлы конфигурации базовой инфраструктуры.</p>
<p class="wp-block-paragraph">Эта модель разработки, которая в значительной степени опирается на взаимодействие интуиции и подсказок, очень популярна в технологическом сообществе — её называют атмосферным кодированием (Vibe Coding). Однако, когда инженеры и компании наслаждаются эффективностью разработки, за этим скрываются многочисленные проблемы.</p>
<p class="wp-block-paragraph">Например, платформы обработки данных корпоративного уровня никогда не были единым и простым приложением. Обычно они объединяются в бесчисленные децентрализованные системы. Эти системы часто управляются разными командами и построены на совершенно разных технологических решениях.</p>
<p class="wp-block-paragraph">Поскольку многие системы на предприятии развиваются независимо, компании начинают сталкиваться со сложными проблемами: несогласованностью бизнес‑логики, многократным внедрением аналогичных функций в разных местах, чрезвычайно сложным анализом влияния нижестоящих систем. При этом вся платформа обработки данных находится под угрозой из‑за скрытых зависимостей.</p>
<p class="wp-block-paragraph">Однако развитие атмосферного кодирования не только не решило вышеупомянутые проблемы, но и может бесконечно их усугублять.</p>
<p class="wp-block-paragraph">В конце концов, когда всё больше операционного контекста, архитектурных решений и бизнес‑знаний больше не вписываются в системную архитектуру, а рассеиваются в подсказках искусственного интеллекта, диалоговых записях и генерируемом по частям коде, система становится обречённой выйти из‑под контроля.</p>
<h2 class="wp-block-heading">Слово‑подсказка, по сути, является «одноразовым продуктом»</h2>
<p class="wp-block-paragraph">Нельзя отрицать, что атмосферное кодирование чрезвычайно эффективно при быстром создании отдельных и независимых функций. Но компании и разработчики также должны понимать, что подсказки — это, по сути, очень недолговечные «одноразовые продукты». Даже идеальная подсказка может отразить лишь различные предположения инженера, бизнес‑опыт, логику реализации и системные знания «на тот момент».</p>
<p class="wp-block-paragraph">В реальных сценариях разработки, чтобы агенты ИИ могли действительно вносить эффективный вклад и внедряться в официальную среду для содействия работе предприятия, инженеры должны постоянно дополнять ИИ различной справочной информацией. Сюда входят причины принятия решений, связанных с архитектурой системы, особенностями бизнеса, правилами, предположениями о структуре (схеме) данных, ограничениями на зависимость от последующей системы, специальными эксплуатационными спецификациями, прошлой историей отладки и различными рекомендациями по внедрению. Эти контексты, скрытые глубоко в диалоге, на самом деле являются наиболее важными и ценными оперативными знаниями, лежащими в основе разработки с использованием искусственного интеллекта.</p>
Но катастрофа произошла и из-за этого. В большинстве рабочих процессов, связанных с программированием ИИ, эта важная информация в конечном итоге будет разбросана повсюду. Она может присутствовать в историческом диалоге между инженером и ChatGPT, или случайно записана в заявке на выполнение задачи, или в общем документе, который никто не будет обновлять, или даже скрыта в этом коде: абзацы, созданные с помощью искусственного интеллекта, но без аннотаций, не стали частью самой системы.
Такая ситуация представляет собой огромную скрытую опасность для разработки корпоративных данных. Современные платформы обработки данных по своей сути представляют собой очень взаимосвязанную и сложную экосистему. Поток данных будет проходить через конвейер импорта данных, хранилище данных, структуру организации рабочего процесса, семантический уровень, приложения, программный интерфейс (API), визуальную панель мониторинга и, наконец, весь путь до системы машинного обучения.
Когда всё больше и больше основной логики и базовых знаний будет заключено в словах‑подсказках и коде реализации, созданном с помощью искусственного интеллекта, компании будут постепенно терять представление о системе — как варёные лягушки о тёплой воде.
Со временем корпоративная команда забудет, какова была цель создания программы или функции в первую очередь. Неясно, какие поля будут изменены, какие последующие зависимости будут затронуты и почему это было необходимо для настройки. Это определённая гипотеза проверки. Невозможно предсказать поведение системы при определённых обстоятельствах, не говоря уже о сложном бизнес‑контексте, скрытом за реализацией.
Поскольку сама система больше не будет содержать полный процесс рассуждения о том, почему она была спроектирована именно так, эти ключевые бизнес‑знания, архитектурные допущения и операционные знания по‑прежнему могут существовать только в памяти инженеров‑людей или в разрозненных разговорах, которые долгое время было невозможно найти, а не прочно существовать на платформе данных.
Вышеупомянутое состояние приводит к крайне противоречивому явлению: атмосферное кодирование действительно ускоряет начальную скорость внедрения, но с макроуровневой точки зрения всей системы общая эффективность проектирования пропорционально не повышается. В долгосрочной перспективе программное обеспечение не будет работать должным образом в течение всего жизненного цикла, и команде разработчиков по‑прежнему придётся тратить много сил на проверку, повторное использование знаний в предметной области, межведомственную координацию и повторное принятие решений.
Более серьёзным техническим препятствием является то, что подсказки по своей сути не являются инженерным продуктом, пригодным для непрерывной итерации. В конце концов, корпоративные системы — это «живые существа», и им необходимо развиваться с обновлением версий, изменением структуры данных, корректировкой бизнес‑логики и изменениями в нижестоящих зависимостях.
Команда инженеров предприятия должна постоянно модифицировать и совершенствовать систему в течение длительного периода времени, но первоначальная цель оперативного руководства — обеспечить быстрое создание компонентов, а не долгосрочную эволюцию системы.
Судя по текущей ситуации, предприятиям сложно согласованно контролировать версии слов‑подсказок искусственного интеллекта и систематически проверять код; слова‑подсказки трудно повторно использовать без проблем между различными командами, а интегрировать их в рабочий процесс автоматизации непрерывной интеграции и непрерывного развёртывания (CI/CD), необходимый для современной разработки программного обеспечения, ещё сложнее.
Даже если в будущем вы введёте в приглашении то же самое слово, но контекст или версия модели ИИ немного отличаются, предприятие и команда разработчиков не могут гарантировать, что ИИ обеспечит точно такие же результаты внедрения, как в прошлом.
Перед лицом этих дилемм начала проявляться концепция разработки на основе спецификаций (SDD), которая постепенно стала основным решением для разработки данных с использованием искусственного интеллекта.
Интегрируйте всё в исполняемый файл спецификации
Философия SDD предельно ясна. Вместо того чтобы разбрасывать ценные операционные знания в виде подсказок и записей диалогов, лучше проявить инициативу по интеграции бизнес‑контекста, логики проверки, поведения при преобразовании, требований к оркестровке и рабочего процесса внедрения непосредственно в «исполняемый файл спецификации» — так эти спецификации станут неотъемлемой частью системы.
Таким образом, система наконец обладает долговременной памятью: она будет чётко помнить, как была спроектирована в первую очередь, почему пришлось пойти на некоторые сложные компромиссы и как различные компоненты платформы связаны друг с другом.
Наличие спецификаций дало командам людей и агентам искусственного интеллекта прочную основу — теперь они могут более надёжно выполнять итерации системы в будущем, одновременно значительно снижая всё более серьёзную проблему фрагментации в децентрализованной среде обработки данных.
В концепции SDD построение системы будет основываться на «исполняемых спецификациях», а не просто на разрозненных согласованных подсказках или коде, сгенерированном искусственным интеллектом.
Традиционная разработка программного обеспечения часто рассматривает спецификацию как пассивный документ — то есть запись о передаче, которая едва формируется после написания программы. Но SDD полностью перевернула эту концепцию: она рассматривает документ спецификации как обязательный «операционный контракт». Эти контракты будут напрямую управлять ИИ при генерации кода, проверке логики, тестировании системы, координации процессов и окончательном развёртывании.
Во многих отношениях SDD действительно идеально расширяет популярные концепции «Инфраструктура как код» (IaC) и «GitOps» в облачной архитектуре — в области проектирования с использованием искусственного интеллекта.
Заимствовано из устава и превратилось в непреходящее знание
На практике типичная система, основанная на спецификации, обычно начинается с разработки «устава», который устанавливает принципы на уровне проекта и жёсткие ограничения — включая технические стандарты, соглашения об именах, архитектурные правила, политики управления информационной безопасностью и основные системные требования.
Поверх устава будут наложены документы с несколькими уровнями спецификаций, каждый из которых отвечает за разные операционные функции: общие спецификации определяют совместимость структур данных, спецификации преобразования — бизнес‑логику, спецификации проверки и итоговые данные, упорядочение порядка выполнения определений спецификаций, семантические спецификации для обеспечения межведомственного обмена бизнес‑определениями, спецификации рабочего процесса ИИ — это многократно используемые инструкции по внедрению, специально написанные для ознакомления агентов ИИ.
Эти технические документы обычно написаны на упрощённых языках тегов, таких как Markdown, которые можно быстро сгенерировать и постоянно обновлять с помощью искусственного интеллекта. Настоящая цель состоит не только в том, чтобы написать более качественные документы, но и в том, чтобы архитектурный замысел, бизнес‑предположения и логика реализации больше не исчезали в кратких словах, которые теряются по мере их использования, а превратились в прочные системные знания, встроенные во весь жизненный цикл разработки.
Используйте достаточную прозрачность, чтобы избежать эффекта бабочки.
Хотя SDD может быть применён к любой области разработки программного обеспечения, разработка данных стала наиболее подходящим сценарием для импорта из‑за своей уникальной природы.
Системы обработки данных корпоративного класса, естественно, охватывают бесчисленное множество взаимосвязанных технических уровней. Инженерам по обработке данных приходится одновременно работать с транзакционными системами, платформами потоковой передачи, хранилищами данных, системами оркестрации, API, информационными панелями и конвейерами машинного обучения. Любое изменение в восходящем потоке может вызвать эффект бабочки без предупреждения — простое изменение имени поля может привести к отключению нижестоящих конвейеров, панелей мониторинга, внешних API и даже основных рабочих процессов прогнозирования.
SDD решает эту проблему путём импорта и совместного использования операционных контрактов между системами с контролем версий. Когда все схемы данных, зависимости, правила проверки и логика преобразования чётко определены в файле спецификации, как команда специалистов, так и агент искусственного интеллекта могут чётко видеть, как связаны узлы системы и как изменения будут распространяться по конвейеру.
Побуждать инженеров заняться архитектурным проектированием.
Суть разработки данных заключается не только в быстром построении конвейеров. Команда инженеров должна найти баланс между стабильностью системы, возможностью расширения, сопровождения и затратами на инфраструктуру, что требует значительных усилий по архитектурному проектированию. Суть в том, что как только структура и операционная модель созданы, большая часть последующей реализации на самом деле представляет собой очень повторяющуюся и кропотливую работу.
SDD как раз подходит для этой функции. На примере последовательных данных CRM: когда режим импорта и преобразования разработан, а в будущем будет добавлена новая спецификация, инженеру нужно только добавить новое определение в файл спецификации, и агент искусственного интеллекта автоматически сгенерирует код импорта на Python, модель преобразования и рабочий процесс планирования, а также последующие проверочные испытания в соответствии с существующими техническими требованиями. Люди руководят архитектурой, а искусственный интеллект отвечает за реализацию. Такое разделение труда делает разработку данных наиболее подходящей областью для внедрения SDD.
Даже если агенты искусственного интеллекта могут автоматизировать большую часть реализации, суждения инженеров-людей по‑прежнему незаменимы — они необходимы для определения сложной бизнес‑логики, проектирования архитектуры системы, принятия решений между техническими компромиссами, проверки корректности системы и координации межведомственной эволюции. По‑прежнему это основная обязанность людей.
Поскольку искусственный интеллект генерирует всё больше и больше деталей реализации, роль инженеров будет смещаться с написания повторяющихся конвейеров на определение спецификаций, разработку повторяемых бизнес‑моделей и координацию бизнес‑контекстов. Будущее, на которое указывает SDD, заключается в том, что люди сосредоточатся на замысле и архитектуре, а искусственный интеллект будет отвечать за всю реализацию, тестирование и разработку операций в масштабе.
[Рекомендуемое чтение]
◆ Финансовая индустрия делает ставку на искусственный интеллект: от реструктуризации платёжных процессов до кредитования — какие проблемы управления стоят за этой революцией в эффективности? Ссылка
◆ Когда ИИ коммерциализирует профессиональные знания, каковы отличительные преимущества предприятий? Наделла сказала, что ответ находится в «цикле обучения». Ссылка
◆ [От времени продажи к результатам продаж] Благодаря корректировке структуры заработной платы McKinsey искусственный интеллект способствует переосмыслению бизнес‑модели индустрии услуг, основанной на знаниях. Ссылка
＊Эта статья открыта для перепечатки партнёрами, ссылка: VentureBeat, [VentureBeat](<url>/), Информационный мир, источник первой картинки: [Информационный мир](<url>/), источник первой картинки: Здесь.
(Ответственный редактор: Цзоу Цзяянь)
Подписаться в Макс
