В посте From Data Engineer To ?? Engineer автор затронул тему изменений в дата инжиниринге, связанных с развитием AI. Автор является практикующим инженером, поэтому ему есть, что рассказать. __1. От Data Engineer → Landing Engineer Что изменилось: • Раньше пользователи хотели готовые дашборды, витрины данных (data marts) и полностью смоделированный BI-слой • Теперь запрос стал проще: «просто дай мне сырые данные» Почему: Пользователи сами «вайб-кодят» последнюю милю с помощью Claude, Codex и подобных инструментов Следствие для стека: • Дорогие Snowflake/Databricks нужны лишь для хранения и контроля доступа • Альтернатива: партиционированные Parquet/Iceberg/DuckLake + несколько DuckDB-трансформаций • Документация схемы в Markdown — и пользователи готовы к работе __ Тут я бы добавил, что просто так вряд ли всё заработает без хорошего семантического слоя. Хороший семантический слой — это модель данных (например, по Кимбалу) и описание каждой таблицы, каждого поля, каждого соединения между таблицами. По моему опыту, это самое сложное. Возможно, когда у вас 1–2 датасета, ИИ сможет понять, что и как, но такой подход не масштабируется. А главное — ИИ может легко накосячить. Важно понимать, что желание использовать ИИ в аналитике для поиска инсайтов и реальные возможности компании не совпадают. Купить подписку на Claude или Codex не решит накопившиеся проблемы, а только усугубит их. Чем больше legacy и tech debt, тем сложнее проверить такой «фокус». Но если у вас заведётся, то, как я писал раньше, С-уровень будет в восторге, и у вас появятся бюджеты на новые инструменты, а вас будут ценить как никогда. Можно смело сказать, что ИИ-аналитика сейчас является одним из самых впечатляющих достижений, поэтому я всех прошу добавлять такой кейс в резюме и делать подобные пет-проекты — hiring manager оценит такой бонус. __2. От Data Engineer → DevOps Engineer Что изменилось: • Data engineering децентрализуется: инженер создаёт центральные артефакты, а команды сами строят свои пайплайны • Пользователи хотят запускать агентов для построения дашбордов Новая инфраструктура, которую нужно поднимать: • Cloud sandboxes — среда для агентов • Data storage (bucket) — хранение данных • LLM governance — контроль затрат и безопасности • Best practices — стандарты для агентного кода Вывод: ~90% этой работы — чистый DevOps__ Всё, что касается инфраструктуры, для меня всегда было приоритетом, поэтому тут ничего нового — просто стало проще и удобнее. ИИ может писать скрипты для Terraform, и они достаточно простые и надёжные. А вот про LLM governance и sandboxes для агентов я не подскажу — как-то не доводилось. Обычно в дата-инжиниринге инфраструктура и среды (dev/test/prod) — не проблема. Проблема — иметь свежие данные в среде разработки. Ведь не хочется дублировать все data pipelines на все среды. Главный бонус DevOps — менеджеры с Claude туда не полезут. Поэтому у вас остаётся хоть немного задач, где вы сами себе хозяин: сами придумываете сроки и сами решаете, как лучше сделать. __3. От Data Engineer → Software Engineer Что изменилось: __• __Пользователи с доступом к данным, агенту и sandbox-у неизбежно строят прототипы приложений __• __И затем просят «просто поднять это в прод» — что, конечно, совсем не просто __ __Два пути для инженера: __• __Go Deep — стать специалистом (Streaming, Iceberg и т.д.), скорее всего в software vendor __• __Go Wide — стать DevOps-data-software инженером, владеющим всем циклом внутри компании__ Безусловно, для пет-проектов я теперь Software Engineer. Для компании — я не хочу быть SDE, но с помощью агентов я могу найти исходный код и использовать его в решениях дата-инжиниринга. Или попробовать докопаться до бага в данных. Есть и примеры, когда продуктовые менеджеры не хотят ждать дата-команду и сами создают аналитические решения. Они решают задачи, но не в долгосрочной перспективе — скорее как поделка. Зато возможности у всех стали безграничными.