Senar: لماذا لا يستبدل وكلاء AI المبرمجين ويغيّرون عملية التطوير

Во второй части серии про SENAR автор разбирает не качество моделей, а сам процесс разработки с ИИ-агентами. Главная мысль простая: агент может писать код быстрее человека, но он не ведёт себя как инженер, когда сталкивается с пробелом в знаниях.

Где агент ошибается

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

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

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

«Разница между программистом и агентом не в скорости».

Пять ключевых выводов

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

• У агента нет памяти проекта: если история решений не передана явно, её для него не существует.
• Он выполняет задачу буквально и не достраивает бизнес-контекст так, как это делает опытный разработчик.
• Одно неверное предположение быстро размножается по серии похожих файлов и утилит.
• Агент не видит архитектуру за пределами текущего промпта и выбирает локально удобный путь.
• Он не живёт с последствиями своих решений, поэтому ответственность за релиз и данные остаётся у человека. Практический вывод из этих наблюдений жёсткий: в задаче должны быть не только цель и критерии приёмки, но и негативные сценарии, ограничения, запреты и архитектурные рамки. Если оставить пустоты, агент заполнит их сам. Поэтому входной шлюз качества в SENAR требует сначала собрать спецификацию и контекст, а уже потом запускать генерацию. Скорость здесь полезна только тогда, когда пространство для домысливания заранее сужено человеком.

Цена быстрой автоматизации Быстрый код от агента создаёт другой тип долга — когнитивный.

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

На зрелых проектах у него эта метрика держалась в районе 5–15%, на старте нового — около 20%. Смысл не в красивом отчёте, а в обратной связи: если ручные правки повторяются, значит, проблема не в одном файле, а в контексте, спецификации, архитектурных границах или выбранной модели.

Новая роль инженера Из-за этого меняется и роль человека в команде.

По оценке автора, теперь до 60% времени уходит на постановку задач, сбор контекста и архитектурные решения, около 30% — на проверку результатов и ещё 10% — на настройку инструментов, метрик и самого процесса. Само написание кода перестаёт быть центром работы: инженер всё больше похож на того, кто задаёт допуски, декомпозирует сложную систему и проверяет, не превратился ли аккуратный вывод агента в дорогую ошибку. Отдельный вывод звучит жёстко: всё, что не записано, для агента не существует.

Если границы модулей, API-конвенции, причины прошлых решений и запрещённые зависимости живут только в голове техлида, агент почти наверняка их нарушит, потому что технически импорт может работать и тесты могут проходить. Поэтому документация в модели SENAR нужна не для отчётности, а как рабочий интерфейс между человеком, агентом и будущими разработчиками, которым потом придётся сопровождать этот код.

Что это значит

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