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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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

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