Snowflake CoCo: инференция внутри периметра безопасности

Любой руководитель платформы, у которого в бюджете на 2026 год стоит строка «ИИ-помощник для написания кода для команды данных», в ближайшие 90 дней должен ответить на конкретный вопрос о вендоре: работает ли агент внутри вашего периметра governance или он отправляет схемы и историю запросов на чужой инференционный эндпоинт. Snowflake только что сделала этот вопрос неудобным для игнорирования. Запуск CoCo — агента для написания кода для инженеров данных — это меньше история о продукте и больше история о закупках.

Что произошло

4 сентября сейлз-инженер Snowflake Джеремайя Хансен опубликовал пост, представляющий CoCo — ИИ-агент для написания кода, ориентированный именно на инженеров данных, создающих воспроизводимые пайплайны. Как сообщает StartupHub.ai, Хансен строит питч вокруг воспроизводимости, а не чистой генерации кода — это заметный риторический ход на рынке, где каждый вендор всё ещё конкурирует по скорости токенов и оценкам бенчмарков.

CoCo поставляется в трёх интерфейсах, которые используют одну и ту же базовую модель: CLI для работы в терминале, десктопный клиент на основе VS Code и версия без установки, встроенная в Snowsight для долгих облачных задач. Главная архитектурная особенность — инференция остаётся внутри инфраструктуры Snowflake. Схемы, конфигурации хранилищ и история запросов обрабатываются в соответствии с теми же политиками governance и классификации данных, которые уже действуют у клиента, а не маршрутизируются к стороннему провайдеру моделей.

Агент поставляется с готовыми навыками для Dynamic Tables, Snowpipe Streaming, Openflow, миграции Spark, dbt, Snowpark и DCM. Эти навыки активируются, когда промпт соответствует домену, так что агент не загружает все возможности в контекст при каждом вызове. Хансен откровенен насчёт точки отказа: агенты недетерминированы по своей природе, и разрешить одному из них писать напрямую в продакшн без dbt, schemachange, Flyway или Terraform в цепочке означает создавать хрупкие деплойменты. Ответ Snowflake — упаковка. Командные соглашения хранятся в файлах SKILL.md. Плагины объединяют навыки вместе с субагентами, слэш-командами, хуками и MCP-серверами, а затем разворачиваются как версионированные единицы через реестр с командами cortex plugin validate, install и update.

Техническая анатомия

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

О границе инференции: большинство универсальных агентов для написания кода работают, отправляя контекст на внешний LLM API. Для задач инженерии данных этот контекст включает схемы таблиц, названия колонок, примеры строк, историю запросов и нередко сам план запроса. Это именно та полезная нагрузка, которую регулируемый iGaming-оператор, платёжный процессор или аналитическая команда банка не может законно передать третьей стороне без соглашения об обработке данных — а зачастую и вовсе не может. Сохранение инференции Snowflake внутри своего периметра означает, что теги классификации, уже применённые клиентом в рамках существующей политики governance, продолжают действовать на этапе рассуждения агента. Это не приятное дополнение. Это разница между «мы можем запустить пилот» и «юридический отдел зарубил это на проверке».

О слое упаковки: SKILL.md — это по сути файл «соглашение как код». Он кодирует, как конкретная команда пишет dbt-модели, именует Dynamic Tables, структурирует Snowpark-задания. Плагин объединяет один или несколько навыков с исполняемой механикой, субагентами для обработки подзадач, слэш-командами для операторов, хуками для событий жизненного цикла и MCP-серверами для доступа к внешним инструментам. Модель реестра с командами validate, install, update заимствована прямо из философии пакетных менеджеров. Это важно, потому что платформенная команда может версионировать свои внутренние правила так же, как версионирует Terraform-модули или dbt-пакеты. Посмотрите на документацию dbt, чтобы оценить зрелость этого паттерна в трансформационном слое; CoCo пытается импортировать ту же дисциплину в поведение агентов.

Предупреждение Хансена о недетерминированности — честная часть. Никакая упаковка навыков не сделает LLM детерминированным. Что она делает — так это ограничивает радиус поражения. Если агент должен производить dbt-модели или schemachange-миграции, а не сырой DDL, запускаемый в продакшн, то код-ревью, CI и откат достаются вам как бесплатные побочные продукты существующего деплоймент-пайплайна. Вот в чём реальное утверждение о воспроизводимости. Не в том, что агент повторяем, а в том, что его выходные данные попадают в системы, которые уже являются таковыми. Документация платформы Snowflake — это то место, где граница между выводом агента и управляемым деплойментом в конечном счёте определяется.

Кто пострадает

Три группы ощутят этот шаг немедленно.

Во-первых, независимые вендоры ИИ-агентов для написания кода, ориентированные на команды данных. Любой стартап, чей питч звучал как «мы подключаемся к Snowflake и даём вашим инженерам Copilot для SQL», только что увидел, как владелец платформы выпустил нативного конкурента внутри периметра с готовыми навыками для тех самых поверхностей Snowflake, которые они оборачивали. Расчёт «строить или покупать» для руководителя платформы изменился в одночасье. Если вы уже платите Snowflake семизначную сумму в год, добавление агента первой стороны, наследующего ваши политики governance, — это значительно более короткий цикл закупок, чем онбординг нового вендора, переговоры по DPA и настройка правил сетевого выхода для стороннего инференционного эндпоинта.

Во-вторых, команды с тяжёлым стеком Databricks, работающие со смешанными нагрузками. Питч Snowflake теперь звучит как «ваш агент остаётся внутри забора». Это конкурентное позиционирование, на которое Databricks придётся отвечать, и ответ, скорее всего, будет связан с более глубокой интеграцией агентов для написания кода со слоем governance Databricks. Командам, которые сейчас выбирают между платформами для нового greenfield-аналитического проекта, стоит ожидать, что история об агентах станет частью RFP уже в этом квартале.

В-третьих, рынок найма старших инженеров данных. Если CoCo действительно реализует автоматизацию на основе навыков для миграции Spark, написания dbt и настройки Snowpipe Streaming, предельная ценность среднего инженера данных, который в основном пишет шаблонные трансформации, снизится. Премия переместится к инженерам, которые умеют создавать соглашения в SKILL.md, проектировать архитектуры плагинов и обеспечивать дисциплину деплоймента, на которую Хансен указал как на оставшийся пробел. Это то же самое расслоение, которое рынок разработки программного обеспечения пережил с Copilot, — теперь оно приходит к ролям на платформах данных.

CFO любого клиента Snowflake на этой неделе должен спросить своего VP Data, можно ли расторгнуть текущий контракт на внешний ИИ-инструмент для написания кода по удобству, и каков профиль потребления кредитов CoCo в сравнении с сэкономленными лицензионными расходами. Никто пока не опубликовал юнит-экономику для инференции CoCo в кредитах Snowflake, и пока эта математика не на столе, «это включено в платформу» — маркетинговое предложение, а не бюджетная строка.

План действий для команд данных

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

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

Далее — не позволяйте CoCo писать напрямую в продакшн. Хансен так и сказал, и он прав. Направляйте вывод агента через dbt, schemachange, Flyway или Terraform в зависимости от того, какой слой он затрагивает. Относитесь к коду, сгенерированному агентом, точно так же, как к коду, написанному стажёром: код-ревью, CI-проверки, поэтапное развёртывание. Утверждение о воспроизводимости работает только если вы обеспечиваете детерминированную обёртку.

Затем вложите инженерное время в написание файлов SKILL.md, кодирующих реальные соглашения вашей команды. Паттерны именования Dynamic Tables, эвристики по размеру хранилищ, стандарты тегирования. Именно здесь платформенная команда зарабатывает своё место в эпоху агентов. Универсальные навыки производят универсальный код. Закодированные соглашения производят код, который проходит ваше ревью.

Наконец, внимательно следите за зрелостью реестра плагинов. Версионированная и валидируемая система плагинов — это разница между агентами-игрушками и агентами как инфраструктурой. Если Snowflake выстроит здесь реальную экосистему, сторонние авторы навыков последуют за ней, и привязанность к платформе усилится. Если реестр застопорится, CoCo останется удобной фичей первой стороны, и рынок останется открытым. Закладывайте бюджет с учётом этого.

Ключевые выводы

• CoCo выполняет инференцию внутри периметра Snowflake, устраняя проблему утечки данных через сторонний LLM, которая блокирует большинство универсальных агентов для работы с регулируемыми нагрузками.
• Три интерфейса (CLI, VS Code Desktop, встроенный в Snowsight) используют одну и ту же модель, при этом версия Snowsight ориентирована на долгие облачные задачи.
• Встроенные навыки охватывают Dynamic Tables, Snowpipe Streaming, Openflow, миграцию Spark, dbt, Snowpark и DCM; активируются по совпадению промпта, а не загружаются в контекст постоянно.
• Воспроизводимость обеспечивается обёрткой деплоймента (dbt, schemachange, Flyway, Terraform), а не самим агентом; Хансен прямо указал, что агенты остаются недетерминированными.
• Паттерн SKILL.md плюс реестр плагинов с командами validate, install, update — это реальная стратегическая ставка: дисциплина управления пакетами, применённая к поведению агентов.