Роль дата-инженера долгое время определялась через аббревиатуру ETL - Extract, Transform, Load. Извлечь данные из разрозненных источников, привести к единому формату, загрузить в хранилище. Работа понятная, воспроизводимая и всё более автоматизируемая. Когда AI-инструменты научились генерировать пайплайны на уровне уверенного мидла, возник закономерный вопрос: что остаётся у человека? Ananth Packkildurai, автор рассылки Data Engineering Weekly, предлагает конкретный ответ. По его наблюдению, механическая работа по построению пайплайнов всегда маскировала более важную задачу — управление семантикой данных. Понимание того, что «выручка» в финансовом департаменте и «выручка» в отделе продаж считаются по-разному. Что null в одной системе означает отсутствие информации, а в другой — осознанный выбор пользователя. Что определение «активного клиента» менялось трижды за год, и каждое изменение похоронено где-то в SQL-логике трансформаций. Вместо ETL предлагается фреймворк ECL - Extract, Contextualize, Link. Извлечение данных остаётся инженерной задачей. Но центр тяжести смещается на этап контекстуализации - придания данным проверяемого семантического значения. Третий элемент, связывание, отвечает за построение устойчивых связей между сущностями из разных систем: клиент в CRM, пользователь в продуктовой базе, событие в аналитике, сессия в системе поддержки. Архитектурно это предполагает появление нового инфраструктурного компонента - Context Store, версионируемого хранилища семантических определений. Не вики-страницы с описанием полей, а инженерного артефакта, к которому обращаются downstream-системы и AI-агенты, прежде чем работать с данными. Контракты данных при этом перестают быть документацией и становятся исполняемыми ограничениями - по аналогии с интерфейсами в разработке, которые ломают сборку при нарушении. Это различие критично именно в контексте AI. Когда агент генерирует трансформационный код, он добросовестно реализует любую логику, которую ему задают. Если контракт на входе неоднозначен или не enforce-ится - ошибки становятся системными, а не единичными. Масштаб автоматизации умножает как корректные решения, так и некорректные. Примечательно, что 53% участников опроса в LinkedIn назвали архитектуру и принятие компромиссных решений тем, что останется за человеком в мире AI-генерируемого кода. Не владение конкретным инструментом и не скорость написания SQL. А способность определить, какие данные заслуживают формализованного контракта, где граница между предписанным и обнаруженным контекстом, и кто в организации несёт ответственность за то, что определение в Context Store корректно. Дата-инженер в этой модели - не тот, кто перемещает данные. А тот, кто проектирует инфраструктуру их смысла. https://www.dataengineeringweekly.com/p/data-engineering-after-ai?utm_source=post-email-title&publication_id=73271&post_id=188977018