Агент пишет код. Что тогда остаётся инженеру данных?

В работе инженера данных хватает повторяющихся задач: забрать данные из API, проверить структуру, преобразовать поля, записать результат в хранилище. Вокруг этого — настройки, тесты, сообщения об ошибках и документация.

Такую работу удобно поручать Агенту. Например:

Напиши граф задач Airflow: получить данные из API, сохранить в S3, проверить структуру через Pydantic и загрузить в хранилище. Добавь повторные попытки, журналирование и тесты.

Полученный код нужно проверить, но начинать с пустого файла уже необязательно.

Отсюда возникает вопрос: если реализацию всё чаще можно получить по описанию, за что будет отвечать инженер данных?

Я бы начал с того, что написание кода никогда не было всей работой. Просто его результат хорошо виден: вот задача, вот изменение в репозитории, вот новая обработка.

Гораздо хуже видны решения, благодаря которым система не потеряла данные, не завалила источник запросами и не потребовала ночного восстановления. На них и стоит посмотреть.

Сначала нужно решить, что должно происходить при сбое

Допустим, у нас ежедневная загрузка 100 файлов. После загрузки их содержимое попадает в поисковый индекс.

Реализация выглядит просто: удалить старые файлы, скачать новые, запустить обновление индекса.

Сегодня загрузилось 40 файлов, после чего источник перестал отвечать. Старой выгрузки уже нет, новой целиком ещё нет.

Даже если обновление индекса не запустится после ошибки загрузки, предыдущую выгрузку это не вернёт. Если же импорт всё-таки начнётся, придётся отдельно разбираться, что он сделает с неполным набором.

В такой задаче сначала нужны ответы на несколько вопросов. Как мы определяем, что пришли все ожидаемые файлы? Когда разрешаем их использовать? Что произойдёт при повторном запуске? Есть ли у нас предыдущая рабочая версия?

Один из возможных вариантов устройства загрузки:

1. Новые файлы сохраняются отдельно от действующей выгрузки.

2. Перед публикацией проверяются полнота набора и содержимое.

3. Потребители переключаются только на готовую версию.

4. Предыдущая версия сохраняется на согласованный срок для восстановления.

Это ещё не готовая архитектура. Нужно выбрать способ переключения, определить срок хранения и договориться с источником, откуда брать перечень ожидаемых файлов. Просто сравнивать их количество со вчерашним недостаточно: сегодня источник вполне мог законно сформировать другой набор.

Агенту можно поручить реализацию такой схемы. Можно попросить его поискать слабые места и предложить альтернативы. Но сначала кто-то должен выяснить требования и решить, какие гарантии действительно нужны.

Команда «добавь повторные попытки» этой работы не заменяет.

Предложить решение и принять решение — разные задачи

Модель может посоветовать промежуточное хранение, контрольные суммы, проверку полноты, переключение версий и сохранение предыдущего состояния.

Предложения могут быть разумными. Но каждое из них нужно примерить к системе.

Допустим, хранить две выгрузки слишком дорого. Или потребители читают файлы напрямую, и единого места переключения пока нет. Или источник не предоставляет перечень файлов, по которому можно проверить полноту. Или восстановление вчерашней версии допустимо для отчёта, но недопустимо для другой зависимой системы.

Эти ограничения нужно собрать и передать модели. Затем проверить, не потерялись ли они в предложенном решении.

Поэтому использовать Агента для проектирования вполне можно. Отказываться от его предложений только потому, что их сделала модель, смысла нет. Но принимать ответ за готовое инженерное решение тоже не стоит.

Заказчик в итоге получает работающую систему, а не удачный ответ в чате. Кто-то должен проверить, что система выполняет договорённости, и организовать восстановление, когда она их нарушит.

Знание SQL и Python никуда не девается

Из рассуждения «Агент пишет код» легко сделать неверный вывод: значит, глубоко разбираться в коде больше не нужно.

Но как тогда его проверять?

Можно получить обработку на Spark, не понимая, в какой момент данные перераспределяются между исполнителями и сколько это стоит. Можно принять SQL-запрос, не посмотрев план выполнения. Можно применить настройки Kubernetes, не разобравшись с запросами и ограничениями ресурсов.

В каждом случае текст будет выглядеть убедительно. Этого недостаточно, чтобы оценить его поведение на реальных данных.

С повторными попытками та же история. Важно не только проверить, что они настроены. Нужно понять, безопасно ли повторять операцию, не создаст ли она дубли и не увеличит ли нагрузку на уже перегруженный источник.

Тесты тоже требуют проверки. Например, тест успешной загрузки не отвечает на вопрос, что произойдёт после записи половины файлов. А проверка структуры записи ничего не говорит о полноте всего набора.

Фундаментальные знания нужны не только для самостоятельной реализации. Они нужны, чтобы заметить пропущенный случай, задать точный вопрос и отличить рабочее решение от правдоподобного.

Что нужно видеть за отдельной задачей

Инженер данных работает не с изолированным SQL-запросом или графом задач. Есть источник, доставка, преобразования, хранилище и потребители. Ошибка на одном участке может проявиться совсем в другом месте.

Например, задача загрузки завершилась успешно. Она прочитала всё, что отдал источник, и записала результат без исключений. Но источник отдал только часть данных.

С точки зрения выполнения кода всё прошло штатно. С точки зрения пользователя отчёт неверный.

Поэтому полезно разделять два вопроса: выполнилась ли обработка и получили ли потребители пригодные данные.

Для второго вопроса нужны свои проверки: свежесть данных, полнота, уникальность ключей, допустимые значения, согласованность с другими наборами. Конкретный состав зависит от задачи. Пустая таблица где-то означает аварию, а где-то — нормальный день без событий.

То же относится к наблюдаемости. Сообщение об ошибке помогает узнать, что задача упала. Для разбора причин обычно нужны дополнительные сведения: какой источник использовался, какой период обрабатывался, сколько записей пришло и какая версия кода их преобразовала.

А для оценки последствий нужно знать, какие отчёты, сервисы и другие обработки используют эти данные.

Это не повод собирать все возможные показатели. Сначала стоит определить, какие вопросы возникнут при сбое, а затем обеспечить возможность на них ответить.

Иногда полезнее пересмотреть требование, чем ускорять обработку

Представим таблицу, которая обновляется каждые пять минут. Обработка дорогая, поэтому инженер ищет способы её ускорить.

Можно переписать запрос. Изменить размещение данных. Добавить ресурсы. Попросить Агента предложить ещё несколько вариантов.

Но сначала стоит выяснить, откуда взялись пять минут.

Возможно, данные действительно нужны с такой задержкой. Тогда задача понятна: нужно обеспечить требуемую свежесть за приемлемую стоимость.

А возможно, этот интервал когда-то поставили без особых причин, а отчёт открывают раз в день. Тогда обсуждение требований может дать больше, чем оптимизация кода.

Похожие вопросы возникают со сроками хранения, глубиной пересчёта истории и объёмом собираемых данных.

Это не призыв спорить с каждым требованием. Нужно понимать его происхождение и последствия. Без этого можно добросовестно ускорять обработку, которую давно пора упростить или убрать.

Стоимость тоже относится к инженерным ограничениям. Решение должно укладываться не только в сроки выполнения, но и в доступные ресурсы, включая время команды на сопровождение.

Где Агент полезен помимо написания кода

Я бы смотрел на весь путь изменения: от появления задачи до проверки результата в рабочей системе.

Например, перед исправлением загрузки нужно найти связанные таблицы, прочитать описание источника, проверить зависимые обработки и понять, какие тесты придётся изменить. Часть этого сбора сведений можно поручить помощнику, если у него есть доступ к нужным материалам.

При разборе сбоя похожая работа: собрать ошибки, изменения кода, сведения о последних запусках и зависимости между данными. Агенту можно поручить подготовку такой сводки и поиск возможных причин.

Здесь важно отделять установленные факты от предположений. «После изменения выросло время выполнения» и «изменение вызвало замедление» — разные утверждения. Для второго нужна проверка.

Ещё одно применение — подготовка тестовых случаев. Не просто «напиши тесты», а более конкретная задача:

Найди ситуации, в которых повторный запуск создаст дубли, неполный набор будет опубликован или восстановление предыдущей версии окажется невозможным.

Ответ всё равно нужно проверять, но он может помочь рассмотреть случаи, которые не вошли в первоначальную постановку.

Для такой автоматизации я бы начинал с чтения, анализа и подготовки изменений. Перезапуск обработок, удаление данных и пересчёт истории — отдельные действия с отдельными правами и проверками.

И оценивал бы результат по времени всей работы. Если модель за минуту подготовила изменение, которое потом два часа приходится распутывать, одна скорость генерации мало о чём говорит.

Обязательно ли теперь строить Агентов?

Нет. Не каждой обработке нужен агент, и не каждую последовательность действий стоит заменять рассуждениями модели.

Для загрузки по известным правилам может быть достаточно обычного кода и планировщика. Добавление Агентов должно решать конкретную проблему, а не просто делать схему современнее на вид.

При этом опыт инженера данных полезен и в агентных системах. Вопросы знакомые: где хранится состояние, можно ли повторить действие, как ограничить нагрузку, что делать после частичного выполнения и как восстановить ход событий.

Поэтому переход к работе с агентами не обязательно означает отказ от прежней специальности. Но и обязательной следующей ступенью для всех инженеров данных я бы его не объявлял.

Сначала стоит найти задачу, в которой модель действительно полезна. Потом решать, нужен ли для неё агент.

На что я бы тратил время

SQL, Python и устройство используемых систем остаются основой. Проверять чужой код без понимания инструмента трудно — независимо от того, кто этот код написал.

Следующий слой — проектирование обработки данных: состояние, повторные запуски, согласованность, восстановление после частичного выполнения. Полезно уметь объяснить не только обычный порядок работы, но и поведение при отказах.

Отдельно — качество данных и диагностика. Какие нарушения мы проверяем, как узнаём о них и можем ли определить затронутых потребителей.

И ещё — требования и стоимость. Зачем нужна обработка, какие сроки обновления оправданны, сколько стоят выбранные гарантии и кто будет всё это сопровождать.

Агентов я бы осваивал вместе с этими задачами: поручать ему реализацию, сбор сведений и поиск пропущенных случаев, а затем проверять результат привычными инженерными средствами.

Умение писать код от этого не становится бесполезным. Меняется способ работы с ним.

В примере со 100 файлами мало показать, что загрузка успешно проходит от начала до конца. Нужно ещё объяснить, что произойдёт после сорокового файла, как система обнаружит неполную выгрузку и откуда возьмёт данные для восстановления.

Вот за такой результат и отвечает инженер данных.

Короткая версия в tg