Новая задача инженеров-программистов — не писать код, а проектировать границы, которые не смогут преодолеть агенты искусственного интеллекта.

Ананта Паккилдурай

Если взглянуть на историю изменений современных платформ обработки данных, за последние два года произошли глубокие перемены. Проблемы с написанием синтаксиса исчезли. Благодаря тому, что Cursor, Claude Code и агентные рабочие процессы теперь находятся внутри наших Docker-контейнеров и IDE, создание первой реализации распределенного потокового конвейера или сложной интеграции API больше не является центральным узким местом.

Агенты могут перемещаться по репозиториям, писать тестовое покрытие, анализировать трассировки стека и предлагать варианты рефакторинга. Если описать отображение Kafka-to-Iceberg sink простым языком, агент сможет предложить надежную отправную точку еще до того, как инженер откроет все соответствующие файлы.

Это меняет вопрос, стоящий перед инженерами-программистами.

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

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

Агент как тепловой двигатель

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

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

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

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

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

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

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

Бесконечная обезьяна и ускоряющееся пространство поиска

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

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

В условиях ограниченной задачи этот цикл оказывается на удивление эффективным.

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

Но корпоративные системы редко обеспечивают подобную стабильность. Система ценообразования в реальном времени может зависеть от изменяющегося операционного состояния, API сторонних разработчиков, событий, поступающих с задержкой, региональной политики и бизнес-правил, которые существуют частично в коде, а частично в чьей-то голове. Хранилище данных может быть физически согласованным, но семантически некорректным. Конвейер обработки данных может пройти свои тесты и при этом выдавать цифры, которые финансовый отдел не признает.

Окружающая среда меняется, пока обезьяна печатает.

Проблема трех тел в корпоративной логике

Вот почему задача трех тел является таким полезным образом для корпоративного программного обеспечения.

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

Современные платформы данных имеют схожую структуру. Данные о последовательности кликов меняются в зависимости от поведения пользователя. Операционные базы данных изменяются под воздействием активности клиентов. API-интерфейсы устанавливают ограничения на количество запросов и меняют версии. Схемы развиваются. Политики безопасности меняются. В устаревших системах хранятся правила, которые никто не записал, потому что они годами были скрыты в обработке исключений.

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

Рассмотрим гипотетическую ситуацию: агенту поручено добавить поле customer_tier в модель дохода. Он находит поле status в операционной базе данных, сопоставляет его с преобразованием и проходит существующие проверки типа и возможности значения NULL. Код чистый. Конвейер работает без сбоев. Ответ всё ещё неверный.

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

Новый мандат: разработка равновесия.

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

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

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

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

Ценность разработки программного обеспечения не исчезает с удешевлением генерации кода — она становится более заметной, и именно это изменение действительно имеет значение.

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

Ананта Паккилдурай — ведущий специалист в области инженерии данных, писатель и автор Data Engineering Weekly, где он делится своими знаниями о современных платформах обработки данных, крупномасштабных конвейерах и архитектурах на основе искусственного интеллекта.

Источник: venturebeat.com