Работа программистов постепенно смещается к проектированию правил и систем обратной связи для ИИ

В Venture Beat вышел ^[1] материал, посвящённый изменениям в работе программистов из‑за широкого внедрения искусственного интеллекта ^[2]. Автор считает, что теперь вместо реализации отдельных функций они переходят к проектированию правил, границ и систем обратной связи для ИИ.

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

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

Он предлагает заимствовать подход из термодинамики, которая предоставляет язык для направленной работы, обратной связи, потерь и границ, обеспечивающих согласованность сложной системы. По словам автора, LLM, расположенный в центре обработки данных, обладает огромной мощностью, но он не выполняет полезной работы, пока ему не задать задачу. При этом каждый цикл работы агента сопровождается потерями. «Он начинает с чёткой задачи. Затем следует устаревшему предположению, исправляет симптом, а не причину, рассматривает старую миграцию как текущее поведение ^[3] и начинает накапливать свою собственную историю. После нескольких вызовов инструментов контекст содержит достаточно правдоподобных, но противоречивых деталей, так что следующий шаг становится менее определённым, чем первый», — пишет автор.

Редактор предлагает назвать это явление операционной энтропией. По его мнению, вмешательство человека способно скорректировать процесс, но это сложно реализовать в корпоративных системах. «Данные о кликах меняются в зависимости от поведения ^[4] продукта. Операционные базы данных мутируют под воздействием активности клиентов. API устанавливают ограничения скорости и меняют версии. Схемы развиваются. Политики безопасности меняются. Устаревшие системы содержат правила, которые никто не записал, потому что они годами были скрыты в обработке исключений… То, что начиналось как запрос на локальную доработку, начинает затрагивать всю систему», — пишет он.

«Представим гипотетическую ситуацию: агенту поручают добавить поле customer_tier (уровень клиента) в модель расчёта выручки. Он находит в операционной базе поле status, включает его в процесс преобразования данных и успешно проходит тесты на соответствие типам и допустимость пустых значений. Код чист. Конвейер обработки данных работает без ошибок. Но результат всё равно неверен. Семантический контракт данных гласит, что customer_tier вычисляется на основе расходов клиента за последние 12 месяцев, имеет ответственного владельца со стороны бизнеса и не может быть заполнен на основе статуса учётной записи. Контракт блокирует изменение еще до того, как оно попадет на дашборд. Ценность работы инженера заключалась не в самом преобразовании, а в создании границ, благодаря которым ошибка ^[5] агента стала явной, конкретной и исправимой», — такой пример приводит автор.

Таким образом, по его словам, задача инженера‑программиста больше не сводится к написанию каждого фрагмента микрологики, а сводится к созданию условий, при которых сгенерированной логике ^[6] можно доверять. При этом разработчику приходится выстраивать защитные контуры: строгие семантические уровни, неизменяемые журналы событий, контракты данных, идемпотентные API и детерминированные автоматы состояний.

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

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

Ранее анализ SignalFire, отслеживающий карьеру миллионов сотрудников в более чем 80 млн компаний, показал ^[7], что инженерная сфера оказалась наиболее устойчивой в 2025 году. В то время как общий объем найма в крупных технологических компаниях снизился на 25% по сравнению с уровнем 2019 года, в инженерных должностях наблюдалось гораздо меньшее падение — всего на 11%.