LLM-агенты, генерирующие код, не ускоряют разработку в том смысле, который вкладывают в это менеджеры. Узкое место давно сместилось с написания строк на проектирование, коммуникацию и поддержку. Агент выдает тысячу строк за минуту, а команда тратит часы на ревью, отладку и попытки понять, что этот код делает. Скорость набора превращается в фиктивный показатель, за которым прячется рост когнитивной нагрузки и деградация качества кодовой базы.
Проблема не в инструменте, а в иллюзии, что код - это и есть продукт. Код - это побочный эффект мышления. Когда мышление делегируется модели, не понимающей архитектурных последствий, проект получает объем, но теряет связность.
Почему code-агенты не делают разработку быстрее
Написание кода занимает 10-15% времени разработчика. Остальное - анализ требований, проектирование, обсуждение архитектуры, ревью, отладка, поддержка. Ускорение этапа, который не был узким местом, дает локальный выигрыш и системный проигрыш. Представьте конвейер: вы ускорили один станок в десять раз, но следующие за ним не справляются с потоком заготовок. На выходе - затор, брак и перегрузка.
Исследование Databricks по методологии оценки агентов-кодеров подтверждает: открытая модель Z.ai GLM 5.2 не уступает проприетарным по качеству кода при затратах в 4 раза ниже. Но даже эта производительность не решает главного - код все равно требует человеческой валидации. Databricks вырос до $188 млрд за полтора года, но их исследование подчеркивает: выбор harness-обвязки и методологии оценки влияет на результат сильнее, чем сырая мощность модели. Агент пишет код быстро - но проверка этого кода съедает сэкономленное время с запасом.
Лавина кода: как агенты увеличивают объем merge request'ов
Первый видимый симптом внедрения code-агентов - разбухание merge request'ов. MR на 500-800 строк становится нормой там, где раньше разработчик присылал 100-150. Агент не умеет думать минимальными изменениями: он генерирует решение целиком, часто дублируя существующую функциональность или добавляя избыточные абстракции.
Ревью такого объема требует полного погружения в контекст задачи. Разработчик, не писавший этот код, вынужден восстанавливать логику с нуля. Время ревью растет нелинейно: MR на 500 строк требует не в пять раз больше усилий, чем MR на 100 строк, а в десять-пятнадцать. Наступает усталость от ревью, падает бдительность, баги просачиваются в основную ветку.
Почему объем кода растет незаметно для менеджмента
Менеджмент смотрит на метрики, которые видят: количество закрытых задач, velocity команды, throughput. На старте внедрения агентов эти показатели растут. Задачи закрываются быстрее, код появляется в репозитории активнее. Руководитель видит ускорение и делает вывод об успехе.
Проблема в том, что метрики скорости не учитывают отложенные эффекты: рост технического долга, увеличение времени на ревью в расчете на одного разработчика, падение покрытия кодовой базы ментальной моделью команды. Через три-шесть месяцев velocity начинает падать, но причину уже сложно связать с внедрением агентов - слишком много переменных. Менеджмент списывает замедление на «сложность проекта» и требует еще больше автоматизации, замыкая порочный круг.
Когнитивная ловушка: почему ревьюить сгенерированный код сложнее
Ревью кода, написанного человеком, опирается на общий контекст: ревьюер знает стиль коллеги, понимает, какие решения тот обычно принимает, может предугадать логику. С кодом агента этот механизм ломается. Разработчик открывает MR и видит чужеродный текст - синтаксически корректный, но лишенный «истории мысли».
Агент не объясняет, почему выбрал именно эту структуру, почему обошелся без кэширования, зачем добавил дополнительный уровень абстракции. Разработчик вынужден восстанавливать эти решения задним числом, проверяя каждую строку на соответствие требованиям. Это не ревью, а обратный инжиниринг чужого мышления - или его имитации.
Опыт перехода с Qwen3.6-27B на Gemma3-31B в роли основного кодера показателен: Qwen зацикливался на простых багах при кодинге, а Gemma справилась за день. Но ключевой вывод не в том, какая модель лучше, а в том, что выбор «роли» модели так же важен, как и ее мощность. Неправильно назначенный агент-кодер плодит ошибки, которые команда вынуждена вылавливать вручную.
Эффект «чужого кода»: потеря контекста и рост числа багов
Когда разработчик не чувствует код «своим», снижается ответственность за его качество. Это известный психологический эффект: отчуждение от результата труда ведет к снижению внимания к деталям. Если баг пропущен на ревью, разработчик склонен думать: «это не я писал, это агент сгенерировал». Ответственность размывается между человеком и моделью, и в итоге не лежит ни на ком.
Анализ 146 тысяч тикетов Service Desk, проведенный на реальных данных, показал: учет реальных паттернов работы сократил проблемные кандидаты в 4.5 раза. Без понимания контекста, в котором работает система, даже качественный код агента становится источником ложных срабатываний и пропущенных инцидентов. Агент не знает реальных паттернов использования - он знает только код.
Потеря понимания кодовой базы: скрытая угроза для проекта
Самый опасный долгосрочный эффект - размывание коллективного понимания системы. Кодовая база перестает быть результатом осознанных архитектурных решений и превращается в наслоение сгенерированных фрагментов, логика которых не хранится в головах разработчиков.
Через полгода активного использования агентов команда обнаруживает: никто не знает, как связаны модули, почему выбрана та или иная структура данных, какие инварианты должны соблюдаться. Изменение одной фичи ломает три других, потому что агент, генерируя код для каждой задачи, не учитывал перекрестные зависимости. Он не может их учитывать - у него нет целостной модели системы.
Новые разработчики входят в проект мучительно долго. Документация, если она есть, не соответствует реальности: агенты меняют код быстрее, чем люди обновляют описания. Поддержка превращается в археологию: вместо чтения понятного кода приходится раскапывать слои сгенерированных решений, пытаясь восстановить утраченный контекст.
Почему менеджмент игнорирует риски: хайп vs реальность
Давление трендов и обещания вендоров создают среду, в которой отказ от внедрения code-агентов воспринимается как отставание от индустрии. Руководитель, не развернувший AI-инструменты для команды, рискует выглядеть консервативным на фоне конкурентов, публикующих кейсы «ускорения в 10 раз».
Проблема усугубляется отсутствием технической экспертизы на уровне принятия решений. Менеджер видит демо: агент генерирует работающий CRUD за 30 секунд. Выглядит впечатляюще. Менеджер не видит: этот CRUD не обрабатывает граничные случаи, не интегрирован с существующей архитектурой, не покрыт тестами и потребует полного рефакторинга через месяц. Технический долг не виден на демо.
Метрики, которые врут: почему «больше кода» не значит «лучше»
Строки кода - худшая метрика продуктивности из возможных. Она поощряет многословие, дублирование и избыточные абстракции. Агенты, оптимизированные на генерацию текста, естественным образом максимизируют этот показатель. Результат - раздутая кодовая база, которая требует больше ресурсов на поддержку.
Полезные метрики лежат в другой плоскости: время от постановки задачи до стабильной работы в production, плотность дефектов, время восстановления после сбоя, скорость входа новых разработчиков в проект. Эти показатели code-агенты не улучшают автоматически, а при неконтролируемом использовании - ухудшают. Разговор с менеджментом стоит вести на языке этих метрик: деньги, сроки, качество, риски.
Где code-агенты действительно полезны: баланс между скоростью и качеством
Отказ от агентов не нужен. Нужен контроль. Агенты хорошо справляются с задачами, где контекст минимален, а проверка результата быстра и однозначна: генерация тестов по спецификации, форматирование кода, создание boilerplate-структур, прототипирование изолированных компонентов.
Google Antigravity 2.0 показывает перспективный подход: ИИ-агенты работают автономно без IDE, выполняя асинхронные задачи через JSON-хуки и планировщик. Такой режим снижает соблазн вмешиваться в основную кодовую базу без контроля. Агент делает черновую работу в изолированной среде, а разработчик принимает решение о переносе в проект.
Критически важно разделить зоны ответственности: архитектурные решения принимает человек, агент работает в заданных рамках. Ревью кода агента обязательно и не должно отличаться по строгости от ревью кода джуниора. Лимит на размер MR должен соблюдаться независимо от источника кода: если агент сгенерировал 800 строк, разбейте задачу на части.
Правила безопасного внедрения: что должен контролировать человек
- Архитектурные решения - только человек. Агент не выбирает паттерны, не проектирует схему данных, не принимает решения о зависимостях между модулями.
- Ревью каждого MR, сгенерированного агентом, проводится на общих основаниях. Никаких «быстрых аппрувов» для AI-кода.
- Лимит на размер MR не превышает 200-300 строк. Большие задачи декомпозируются до генерации.
- Метрики качества отслеживаются в динамике: плотность дефектов, время ревью, покрытие тестами. Ухудшение любого показателя - повод пересмотреть подход.
- Ротация: каждый разработчик должен периодически работать без агентов, чтобы сохранять понимание кодовой базы.
Заключение: узкое место - не код, а мышление
Скорость написания кода не была проблемой последние двадцать лет. Проблемой были и остаются неверные архитектурные решения, потерянные требования, сломанная коммуникация в команде и лавинообразный рост сложности поддержки. Code-агенты, примененные без стратегии, не решают эти проблемы - они их маскируют за валом сгенерированных строк.
Пересмотрите метрики эффективности разработки. Вместо «строк кода в день» и «скорости закрытия задач» измеряйте время до production, стабильность релизов и скорость восстановления после инцидентов. Агенты должны обслуживать эти метрики, а не подменять их иллюзией продуктивности. Инструмент не виноват в том, что его используют бездумно. Но и спасением он не станет, пока команда не вернет себе контроль над тем, что происходит с кодовой базой.