Автор является практикующим инженером, поэтому ему есть, что рассказать.
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, но с помощью агентов я могу найти исходный код и использовать его в решениях дата-инжиниринга. Или попробовать докопаться до бага в данных.
Есть и примеры, когда продуктовые менеджеры не хотят ждать дата-команду и сами создают аналитические решения. Они решают задачи, но не в долгосрочной перспективе — скорее как поделка. Зато возможности у всех стали безграничными.
