Как ИИ-агенты меняют роль разработчика

Конец программной инженерии?

Полвека индустрия жила по понятному правилу: человек разбирает задачу на части, пишет код, потом чинит и переписывает его по мере изменений. В статье Чжэньфэна Цао звучит другой тезис: эпоха, где код был главным носителем логики, заканчивается. На первый план выходит ИИ-агент — система, где LLM не просто помогает писать программу, а сама рассуждает, планирует шаги, вызывает инструменты, генерирует код по ходу работы и тут же его выбрасывает, если он больше не нужен.

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

Это меняет не только инструменты разработчика. Это меняет саму единицу поставки. Вместо “мы отдали вам программу” — “мы решили вашу задачу”.

Что именно меняется

Автор предлагает разделить два мира.

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

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

Иными словами, в старом мире код хранил решение, в новом мире решение рождается во время исполнения.

Отсюда вытекает смена роли почти всего вокруг:

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

🟠 Центр управления — уже не разработчик, который вручную проводит систему по пайплайну, а LLM, которая принимает локальные решения по ходу задачи.

🟠 Роль человека — уже не “автор каждой строчки”, а тот, кто задаёт цель, ограничения, критерии качества и проверяет итог.

🟠 Единица ценности — уже не “готовое приложение”, а результат: исправленный баг, собранный отчёт, настроенный сервис, закрытая задача.

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

Почему старый подход упирается в потолок

Самая интересная часть статьи — попытка объяснить это через рост сложности.

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

Автор опирается на старую мысль Фреда Брукса: есть случайная сложность — её можно снижать лучшими языками, фреймворками и инструментами, — а есть сущностная сложность , которая заложена в самой задаче. От неё не уйти.

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

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

Коротко:

🟣 Традиционный софт пытается заранее описать мир в коде.

🟣 ИИ-агент пытается разбираться с миром по ходу работы.

🟣 Традиционный софт плохо переносит изменения без участия человека.

🟣 ИИ-агент может адаптироваться на лету, если у него хватает контекста, памяти и инструментов.

Вот почему автор настаивает: речь идёт не об ускорении программирования на 10–20%, а о смене самой вычислительной модели.

Что такое агентная инженерия

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

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

Автор отдельно описывает архитектуру такого агента. Она выглядит довольно стандартно для сегодняшнего рынка:

🟠 Модуль восприятия — принимает текст, файлы, иногда изображения и другие входы.

🟠 Память — хранит факты, прошлые эпизоды, процедуры и рабочий контекст.

🟠 Модуль действий — вызывает API, запускает код, ходит в базы, правит файлы.

🟠 LLM как ядро рассуждения — связывает всё это в единый цикл принятия решений.

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

Отсюда и новая роль человека. Автор описывает её так:

🟣 Архитектор намерения — формулирует цель и ограничения.

🟣 Координатор агентов — настраивает роли, память и взаимодействие.

🟣 Аудитор результата — проверяет не только “работает или нет”, но и качество, риски, соответствие правилам.

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

Что показывают бенчмарки

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

Первый — SWE-bench Verified. Это один из главных бенчмарков для задач по программированию на реальных задачах из GitHub. Автор приводит результаты модели Lingma SWE-GPT 72B: она закрывает 30,2% задач. Это уже рядом с GPT-4o, у которого 31,8%. Ещё интереснее, что версия на 7B параметров решает 18,2% задач — заметно меньше, но всё ещё на полезном уровне.

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

🟠 Lingma SWE-GPT 72B — 30,2% в SWE-bench Verified.

🟠 GPT-4o — 31,8%.

🟠 Lingma SWE-GPT 7B — 18,2%.

🟠 Вывод — специализация и дообучение могут быть важнее одного только масштаба модели.

Второй сигнал — мультиагентная координация. В пилотах LangChain, которые цитирует автор, координированные группы агентов сократили время поиска первопричины проблем на 93% и сэкономили более 200 инженерных часов за месяц. Здесь фокус не в том, что один агент стал умнее. Несколько специализированных агентов с общим контекстом умеют параллельно исследовать проблему и сверять выводы.

🟠 Снижение времени поиска первопричины — 93%.

🟠 Экономия инженерного времени — более 200 часов в месяц.

🟠 Вывод — координация нескольких агентов даёт отдельный выигрыш поверх качества одной модели.

Третий сигнал — самоулучшение. В качестве примера приводится Hermes Agent от Nous Research. Идея простая: после сложной задачи агент не просто завершает сессию, а сохраняет полезную процедуру в виде навыка. Потом использует этот навык снова. Если он сработал плохо, агент исправляет его сам. Получается цикл: сделал задачу → выделил процедуру → переиспользовал → заметил слабое место → поправил.

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

Короткая выжимка по результатам:

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

🟠 Координация нескольких агентов даёт отдельный выигрыш поверх качества одной модели.

🟠 Память и повторное использование навыков становятся важной частью систем, а не исследовательской экзотикой.

Где всё пока проваливается

Самое честное место в статье — обсуждение ограничений. И здесь главный герой не SWE-bench, а EvoClaw.

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

Автор приводит ключевую цифру: если на изолированных задачах успех у передовых систем бывает выше 80%, то в режиме длительной непрерывной работы он падает максимум до 38%.

Это важно.

🟣 Изолированные задачи — успех выше 80%.

🟣 Длительная непрерывная работа — максимум 38%.

🟣 Разрыв — длинный горизонт работы остаётся главным ограничением.

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

🟣 Дрейф контекста — агент перестаёт держать в голове инварианты большой системы.

🟣 Накопление ошибок — небольшая ранняя ошибка тянет за собой следующие.

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

🟣 Неполная проверка — тесты могут проходить, а смысловая ошибка остаётся внутри.

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

Что делать компаниям уже сейчас

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

Если вы строите команды и продукты сегодня, логика примерно такая:

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

🟠 Стройте проверку вокруг агента — тесты, наблюдаемость, трассировка шагов, история решений.

🟠 Давайте агенту право вести исполнение, а человеку — право задавать рамки и принимать итог.

🟠 Учите людей работать с намерением, а не только с кодом — хороший системный промт, набор ограничений и критериев качества здесь значат очень много.

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

Вывод

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

Главный сдвиг — от поставки программ к поставке результатов. Для пользователя это проще. Для компаний это меняет модель продукта. Для инженеров — роль в команде.

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

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

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