Агенты меняют роли в программной инженерии

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

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

Это меняет задачу для инженеров-программистов.

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

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

Агент как тепловая машина

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

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

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

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

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

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

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

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

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

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

В ограниченной задаче этот цикл работает удивительно эффективно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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