Прямой ответ: почему рост объёма кода не снижает нагрузку
ИИ-агенты пишут код быстро, и качество генерации растёт. Никита, Rust-разработчик с ником NikTimf, описывает ситуацию без восторга: «Сейчас агенты пишут код быстро и в целом неплохо. Но я и тогда больше боялся того, сколько кода можно нагенерировать и кому потом во всём этом разбираться» (Я всё ещё боюсь работать с ИИ, Хабра, 5 октября 2026). Опасение конкретное: производство кода подешевело, а его разбор, ревью и поддержка - нет.
Ускорение заметно там, где задача закрыта: дифф сгенерирован, тесты прошли, merge request влит. Нагрузка живёт в соседних шагах. Сгенерированный код нужно прочитать и понять, найденные баги - исправить, решения - сверить со спецификацией, а с несколькими агентами ещё и переключаться между задачами. Каждый шаг замыкается на того же разработчика, который запускал агента. Скорость набора строк как метрика продуктивности перестаёт что-либо описывать, и это подробно разобрано в материале про код-агентов и когнитивную ловушку.
Агент расширяет и зону ответственности. «С агентом тебе могут поручить задачи из другой области. Агент поможет написать незнакомый код, но разбираться в нём и отвечать за результат всё равно тебе». Эффект двусторонний: «С ИИ можно быстрее закрывать задачи и при этом больше работать». Ускорение по отдельным задачам не делает проще всю остальную работу.
Сколько кода генерируют ИИ-агенты и почему это создаёт новую нагрузку
Агент выдаёт код быстрее, чем человек успевает его прочитать. Объём зависит от задачи: на типовом CRUD агент обычно не экономит строки и охотно добавляет обработку ошибок, логирование и лишние абстракции. Каждая добавленная строка - это строка, которую кто-то должен поддерживать. Источник, на который опирается этот разбор, замеров объёма не приводит, поэтому ограничимся механикой: генерация ускоряется, а стоимость чтения остаётся прежней.
Ревью и отладка: где уходит время
«Даже хорошие результаты добавляют работы: код нужно проверить, найденные баги - исправить, а с несколькими агентами приходится ещё и переключаться между задачами». Ревью сгенерированного кода отличается от ревью кода коллеги. Аргументацию решения приходится восстанавливать самому: человек хотя бы помнит, почему выбрал такой вариант, у модели такого «почему» нет.
Дальше идёт рутина, которую никто не отменял: проверить граничные случаи, посмотреть на поведение при ошибках, сверить с контрактами API, прогнать тесты, убедиться, что новые абстракции не дублируют уже существующие. С несколькими параллельными агентами добавляется цена переключения контекста: держать в голове три незакрытых диффа дороже, чем один.
Отдельная проблема - бюджет времени. «Если на ревью не заложили время, сроки подталкивают нажать approve и разобраться потом». Approve без разбора экономит часы сегодня и создаёт долг на следующей неделе: непонятый код проходит в основную ветку, и разбираться с ним будет тот, кто откроет этот файл через месяц.
Спецификации: почему код может проходить тесты, но делать не то
«Спеки тоже надо проверять и обновлять. Если задачу поняли неверно, код может соответствовать спеке и проходить все тесты, но делать совсем не то, что нужно». Тесты подтверждают соответствие спецификации, а не соответствие задаче. Ошибка в постановке проезжает весь конвейер: агент пишет код по спеке, тесты проверяют код по спеке, ревьюер видит согласованную картину и пропускает её дальше.
Время уходит на проверку требований и разговор с теми, кто ставил задачу. Практика spec-driven development помогает, но не отменяет работу: спецификацию нужно написать, поддерживать и обновлять вместе с кодом. Разбор этого подхода есть в статье про то, почему разработка с ИИ-агентами стала тяжелее.
Передача контекста между ИИ-агентами и расхождения в ответах
«Одного болванчика уже мало. Другому агенту надо передать контекст, а если ответы расходятся - выяснить, кто прав». Второй агент не знает, что делал первый, и не имеет доступа к логике его решений: контекст между ними переносит человек, и на это уходит отдельное время.
Как организовать передачу контекста между агентами
Работает принцип единого источника правды. Спецификация, схема данных, список контрактов и ограничения задачи лежат в репозитории, а не в истории чата с моделью. Тогда каждый агент получает один и тот же текст, а расхождение между ответами становится видно сразу, а не после интеграции.
Второе правило - ограничение ролей. Один агент на задачу, явно очерченная область правок, запрет трогать соседние модули без отдельного запроса. Третье - фиксация результата: что именно сделал агент, какие файлы изменил и какие допущения принял. Без этого следующий агент получит не задачу, а ребус.
Всё это ручная работа. Полностью автоматизировать передачу контекста пока нельзя: часть знаний живёт в голове разработчика и в неявных договорённостях команды. Чем больше агентов в цикле, тем дороже обходится каждое недокументированное допущение.
Что делать, когда агенты противоречат друг другу
Арбитром становится разработчик, и выяснять правоту приходится без готового ответа. Порядок действий, который снижает расход времени: до запуска агентов зафиксировать критерии правильности (тесты, контракты, требования, ограничения по производительности), затем проверять каждый ответ по этим критериям, а не выбирать вариант, который выглядит убедительнее. Убедительность формулировок модели никак не связана с корректностью кода.
Если критериев нет, спор двух агентов превращается в спор с самим собой: оба ответа выглядят разумно, а решение принимается по ощущению. Это самый дорогой сценарий, потому что он повторяется при каждой следующей правке.
Регрессии после обновлений инструментов и корпоративные ограничения
«Привычный инструмент может начать работать хуже после обновления». Инструмент включает модель и обвязку вокруг неё: системные промпты, скрипты, правила, которые направляют агента. Обвязка подстраивается под поведение конкретной версии, поэтому обновление задевает весь рабочий процесс.
Как обновления агентов ломают привычный рабочий процесс
После апдейта агент может иначе толковать инструкции, чаще требовать уточнений, менять формат ответа или хуже удерживать контекст длинной задачи. Внешне это выглядит как «стало работать не так». Приходится заново калибровать промпты и правила, иногда переписывать обвязку. Конкретные версии и дефекты источник не называет, и выдумывать их не стоит: важна сама регулярность регрессий при быстром цикле релизов моделей.
Практический вывод: обновление стоит проверять на типовых задачах команды, а не принимать как безусловное улучшение. Стоимость отката обычно ниже стоимости недели работы с подпорченным инструментом.
Локальные и внутренние модели: чем они ограничивают разработчика
«На работе только свой болванчик. Компания может разрешать только свои или локальные модели. Если выданный помощник хуже справляется с твоими задачами, после сильных агентов к нему уже не хочется возвращаться». Ограничение обычно связано с защитой кода и данных, и у него есть цена: разрыв в возможностях между разрешённой моделью и той, что доступна снаружи.
Дальше включается фактор мотивации. «При прочих равных рискуешь ещё и отставать от тех, кому доступны передовые модели». Разрыв копится в мелочах: где-то агент не удержал длинный контекст, где-то не разобрался в незнакомой библиотеке, где-то результат пришлось переписать вручную. По одной задаче это незаметно, на дистанции сказывается на скорости команды.
Практика «meat proxy»: кто на самом деле разбирается в задаче
«Meat proxy. Коллега пересылает ответы агента, а разбираться в задаче и направлять работу приходится тебе. Твоё время в его отчёте об ускорении не учитывается» (Я всё ещё боюсь работать с ИИ). Название точное: человек работает прослойкой между агентом и задачей.
Почему время второго разработчика не попадает в отчёты
Отчёт строится вокруг того, кто запускает агента. Если коллега получил ответ модели и переслал его дальше, формально задача у него в работе и в его метриках. Время на разбор задачи, постановку уточнений и проверку результата тратит другой человек, и в отчёте оно не отражено.
Получается системная ошибка измерения, а не чей-то злой умысел. Ускорение выглядит подтверждённым, потому что учтена только видимая часть работы. Похожая логика ломает и оценку скорости на уровне команд: замеряется генерация, а не время до рабочего результата.
Как «meat proxy» влияет на команду и сроки
Нагрузка распределяется неравномерно: один человек генерирует, другой разбирается. Сроки при этом считаются по тому, кто генерирует. «Бизнес уже заложил ускорение в следующий план», а скрытые затраты остаются вне бюджета.
Дальше начинаются обычные последствия перегруза: разбор делается быстрее, чем требует задача, ревью сокращается, ошибки проходят дальше по конвейеру. Если практика повторяется, разбирающийся разработчик становится узким местом, а его время - невидимым ресурсом.
Репозиторий Шрёдингера: cognitive debt и потеря понимания проекта
«Репозиторий Шрёдингера. Фичи работают, а команда всё хуже понимает собственный проект и просит агента объяснить даже свои недавние правки». Метафора описывает состояние, в котором система ведёт себя корректно, а знание о том, почему она так устроена, у команды отсутствует.
Что такое cognitive debt и почему о ней говорят
Cognitive debt, или когнитивный долг, описывает накопление непонимания кодовой базы. Он растёт, когда код появляется быстрее, чем команда успевает его осмыслить, и проявляется в моментах, которые раньше были простыми: разобраться в причине бага, оценить последствия правки, объяснить новому коллеге устройство модуля. Термин связывают с работами Margaret-Anne Storey о понимании программ; в исходном материале, на который опирается этот разбор, ссылок на её публикации нет, поэтому конкретные формулировки оттуда мы не приводим.
Когнитивный долг требует времени на восстановление контекста. Если этот расход не заложен, непонимание продолжает копиться: появляются правки «по симптомам», файлы, которые никто не решается трогать, и вопросы агенту о собственных недавних изменениях.
Как вернуть понимание проекта
Первое - выделять время на разбор кода, написанного агентами, как на отдельный вид работы. Второе - писать и обновлять документацию по мере изменений, а не после инцидента. Третье - проводить ревью так, чтобы автор изменения объяснял логику, а не только пересказывал дифф. Четвёртое - ограничивать объём генерации на одну задачу: маленький дифф прочитать и понять реально, дифф на несколько тысяч строк - нет.
Всё это требует поддержки на уровне команды. Автор формулирует желание просто: «От агентов я бы не отказывался. Хотелось бы только тратить часть сэкономленного времени на то, чтобы разобраться в написанном коде». Без такого разрешения на разбор сэкономленное время уходит в следующую задачу, а долг остаётся.
Фулстек-ловушка: почему ИИ не отменяет необходимость разбираться в задаче
«Бизнес и до нейросетей хотел выпускать больше фич и поменьше тратить на разработку. Фулстек в эту логику хорошо вписывается». С появлением агентов аргумент усилился: «А теперь у нас есть ИИ, и к разработчику можно прийти с предложением: „Ты же с агентом работаешь, заодно и фронт сделаешь“. Потом оказывается, что ещё нужно поговорить с пользователем и решить, что вообще делать».
Расширение зоны ответственности не отменяет её содержания. Агенту можно поручить незнакомый стек, но понять, что именно нужно пользователю, и принять решение о поведении системы он не может. Фронтенд, интерфейсные тексты, путь пользователя, обработка пустых состояний - всё это возвращается к разработчику, потому что отвечать за результат будет он. Границы делегирования разобраны в статье про то, почему часть разработчиков не хочет отдавать код ИИ-агентам.
Практический эффект: человек, который раньше писал бэкенд, теперь читает и правит код фронтенда, созданный моделью, и заодно формулирует продуктовые требования. Нагрузка растёт, а агент ускоряет только ту часть, которая связана с набором строк.
Что делать: практические выводы для разработчика и команды
Отказываться от агентов причин нет: генерация кода, черновики тестов и разбор незнакомых API с ними идут быстрее. Управлять стоит не запретами, а бюджетом времени и границами задач.
Как закладывать время на ревью и разбор кода
Ревью сгенерированного кода стоит оценивать как отдельную задачу, а не как бесплатное приложение к генерации. Аргумент для планирования простой: без времени на ревью команда получает approve без разбора, а вместе с ним непонятый код в основной ветке и рост когнитивного долга. Расходы на разбор предсказуемы, расходы на инцидент - нет.
Полезно фиксировать в задаче не только объём кода, но и ожидаемое время на его проверку. Спецификацию обновлять вместе с кодом, а не после. Если бизнес уже заложил ускорение в следующий план, стоит показать, из чего складывается путь до рабочего результата: генерация, ревью, тесты, проверка требований, интеграция. Чек-лист устойчивости AI-процессов и аргументы для разговора с руководством собраны в разборе про «два вечера до магазина».
Как ограничить число агентов и не утонуть в контексте
- Один агент на задачу. Параллельные прогоны по одной области дают конфликтующие диффы и лишнюю работу по слиянию.
- Явная передача контекста. Спецификация, ограничения и критерии готовности лежат в репозитории, а не в переписке.
- Единый источник правды. Одна версия требований для всех агентов и людей.
- Ограничение переключений. Держать в работе столько незакрытых задач с агентами, сколько реально удерживать в голове.
- Фиксация понимания. Короткая заметка о том, как работает изменённый участок, дешевле повторного разбора через месяц.
Эти правила не дают ускорения сами по себе. Они снижают вероятность расхождений между ответами агентов и уменьшают когнитивную нагрузку на того, кто отвечает за результат.
Итог: агенты ускоряют задачи, но не отменяют работу
ИИ-агенты сокращают время на производство кода и не сокращают объём работы вокруг него: ревью, отладку, проверку спецификаций, передачу контекста между агентами, разбор расхождений и восстановление понимания проекта. Поэтому быстрый рост объёма сгенерированного кода не снижает нагрузку на разработчика, а в части сценариев её увеличивает.
Наблюдения Никиты (NikTimf) описывают эту механику на уровне отдельного разработчика: задачи закрываются быстрее, а работать при этом приходится больше (Я всё ещё боюсь работать с ИИ). В обсуждениях темы ссылаются на опрос Harness 2026 года, исследование Berkeley и заметки мейнтейнера curl; в исходном материале этих данных нет, поэтому конкретные цифры оттуда мы не приводим и не подтверждаем.
Что с этим делать: закладывать время на ревью и разбор кода, проверять и обновлять спецификации, ограничивать число агентов на задачу, фиксировать понимание проекта и учитывать время всех участников в отчётах об ускорении. Отказ от агентов решением не выглядит: цена отказа в конкурентоспособности разобрана в материале про то, можно ли отказаться от ИИ сегодня. Разумнее считать полную стоимость пути до рабочего, поддерживаемого и понятного результата, а не только время генерации.