ИИ-агенты в разработке уже умеют быстро собирать рабочие фичи, но это не означает автоматического сокращения нагрузки на инженеров. Вместо ручного написания каждой строки команда получает новый слой работы: ревью сгенерированного кода, проверку требований и восстановление контекста. Для российских разработчиков и IT-руководителей это повод считать не только скорость закрытия задач, но и стоимость последующей поддержки.
Об этом пишет Habr / Карьера в колонке Rust-разработчика Никиты. Автор не спорит с тем, что современные агенты заметно сильнее инструментов 2024–2025 годов: они читают репозитории, предлагают правки, запускают тесты и помогают зайти в незнакомую часть стека. Проблема, по его мнению, возникает после успешного прогона CI. Фича может работать, тесты — быть зелёными, а разработчик при этом не понимать, почему изменение устроено именно так и какие ограничения оно затрагивает.
Такой сценарий особенно знаком командам с плотным бэклогом. Код, созданный агентом, легко принять, чтобы быстрее перейти к следующей задаче. Позже с ним столкнётся другой инженер — возможно, тоже с ИИ-помощником. В итоге проект формально развивается, но знание о его устройстве накапливается не у команды, а в разрозненных чатах, контекстных окнах и подсказках к агентам. Автор называет это «репозиторием Шрёдингера»: функции работают, но объяснить собственные недавние изменения без помощи модели становится всё сложнее.
Главное противоречие здесь простое. Автоматизация способна ускорить создание кода, однако не отменяет ответственности за него. Неверно понятая задача может быть аккуратно реализована, покрыта тестами и всё равно оказаться бесполезной для продукта. Спецификации тоже требуют ревью: если исходное требование устарело или было сформулировано неясно, агент лишь быстрее закрепит ошибку в кодовой базе.
От одного помощника — к диспетчерской моделей
Отдельная нагрузка появляется, когда в рабочем процессе используется несколько моделей. Один агент хорошо справляется с генерацией кода, другой удобнее для поиска дефектов, третий выбирают из-за лимитов или требований безопасности. Но новому помощнику нужно передать историю задачи: что уже проверяли, какие решения отбросили, почему в проекте существует странное на первый взгляд ограничение. И этот пересказ нельзя принимать на веру — его тоже необходимо читать и проверять.
Если два агента дают разные, но одинаково убедительные ответы, окончательное решение всё равно принимает человек. Модель не становится правой только потому, что написала более уверенное объяснение. На практике разработчик переключается между контекстами, сверяет выводы, запускает проверки и исправляет ошибки, которые нашёл предыдущий агент. Экономия на написании кода в таком процессе может превратиться в дополнительную работу по координации.
Предсказуемость самих инструментов тоже остаётся проблемой. В апреле 2026 года Anthropic разбирала ухудшение качества Claude Code: среди причин компания называла изменения глубины рассуждений по умолчанию, ошибку с удалением предыдущих рассуждений и корректировку системного промпта. Для пользователя подобная регрессия выглядит прозаичнее: вчера привычный сценарий работал, а сегодня агент снова предлагает уже отвергнутый подход. Приходится заново проверять инструкции, чистить контекст и искать обходной путь — в то самое время, которое бизнес уже записал в ускорение команды.
«Продуктовый инженер» без права не знать предметную область
ИИ подталкивает компании расширять зону ответственности разработчика. Если агент помогает быстро собрать интерфейс, бэкенд и тесты, инженеру могут передать задачу из соседней специализации: например, фронтендеру — изменение в старом C++-монолите. Идея продуктового инженера, который отвечает за пользовательский результат по всему стеку, не нова. В 2023 году Ли Робинсон писал, что жёсткое разделение на фронтенд и бэкенд теряет ценность для части продуктовых команд, тогда как инфраструктурой занимаются платформенные инженеры.
В сентябре 2026 года Лори Восс сформулировал ещё более смелый прогноз: агенты со временем смогут закрывать технический цикл, а человек сосредоточится на понимании пользовательской потребности и выборе результата. Но между демонстрацией работающей функции и готовностью отвечать за её последствия остаётся большая дистанция. Чтобы оценить изменения в незнакомом сервисе, мало выбрать сильную модель: нужно понимать архитектуру, риски, эксплуатационные ограничения и цену ошибки.
Для компаний с закрытым контуром вопрос ещё острее. Внешние сервисы могут быть запрещены из-за кода, персональных данных или внутренних требований безопасности; сотруднику доступна только корпоративная либо локальная модель. Если она слабее привычных инструментов, разработчик тратит больше времени на подробные инструкции и ручную доработку. При этом сравнение производительности сотрудников без учёта качества доступных им помощников быстро превращается в плохую управленческую метрику.
ИИ-агенты в разработке не отменяют инженера, а переносят его работу с набора кода на постановку задачи, проверку решений и сохранение знания в команде. Самый рискованный сценарий — заложить ускорение в планы, но не выделить время на ревью и разбор изменений. Тогда скорость релизов вырастет лишь до момента, когда следующую «быструю» задачу придётся чинить в коде, который никто по-настоящему не успел понять.