В первый месяц после внедрения Cursor в публичных репозиториях объём добавленного кода вырос в три—пять раз, однако предупреждений статического анализа стало на 30% больше, а сложность кода — на 41%. Верификация ИИ-кода быстро превращается из финальной формальности в ограничение для всей команды: генераторы пишут быстрее, чем люди успевают понять, безопасно ли это вливать в основную ветку. Для российских команд, которые экспериментируют с агентами и ассистентами, вывод довольно приземлённый: измерять эффект числом строк — плохая идея.
Об этом сообщает The New Stack со ссылкой на исследование Carnegie Mellon, изучавшее публичные репозитории после начала работы с Cursor. Авторы наблюдали резкий стартовый прирост, который сошёл на нет примерно через два месяца. При этом следы ускорения остались в кодовой базе в менее приятной форме: больше замечаний анализаторов и более высокая сложность. Публикация подготовлена при поддержке Sonar, поэтому её рецепты нужно читать с поправкой на интерес вендора, но сама постановка проблемы знакома любой команде, где pull request внезапно вырос с пары десятков строк до нескольких сотен.
Том Хоулетт, директор Sonar по взаимодействию с AI-инженерией, описывает разрыв без особой мистики: скорость генерации выросла, а процесс проверки во многих компаниях остался ручным. Если разработчик или агент создаёт в разы больше кода, линейно наращивать время ревью не получится. Ревьюер начинает смотреть на дифф как на счёт за электричество: понимает, что платить надо, но деталей предпочитает не видеть. В результате формальное одобрение становится вероятнее, а содержательная проверка — дороже.
Проблема не сводится к синтаксическим ошибкам. Агенту часто не хватает контекста конкретного репозитория: архитектурных ограничений, договорённостей команды, причин старых обходных решений, правил работы с зависимостями. Вместо минимального изменения он может затронуть лишние файлы, добавить избыточную абстракцию или повторить уже известный дефект в нескольких местах. Такой код может собираться и проходить базовые тесты, но одновременно ухудшать сопровождаемость и увеличивать будущую стоимость изменений.
Проверять не только перед merge
Sonar предлагает встроить верификацию ИИ-кода в три связанных контура: во время работы агента, в CI перед слиянием и в постоянном обслуживании кодовой базы. Первый контур — не замена тестов и ревью, а ранняя обратная связь. Агент получает правила проекта и результаты автоматической проверки, исправляет найденное до создания pull request и лишь затем передаёт задачу человеку. Идея проста: дешевле устранить один дефект в момент генерации, чем обнаружить его после того, как тот же шаблон размножился по изменению.
Во втором контуре CI оценивает изменение целиком и независимо от модели, которая его написала. Здесь уместны привычные для инженерных команд проверки: качество, уязвимости, зависимости, сложность и соблюдение quality gate. Автоматизация не отменяет ответственность разработчика, но меняет распределение внимания. Вместо попытки одинаково тщательно читать каждую строку ревьюер может сосредоточиться на архитектурном решении, бизнес-логике, границах доступа и последствиях сбоя. Именно эти вопросы плохо укладываются в универсальный чекер.
Степень контроля должна зависеть от риска. Для внутреннего инструмента с ограниченной аудиторией допустим более лёгкий процесс; для кода, обслуживающего платежи или критичную инфраструктуру, нужны дополнительные независимые проверки и более явное человеческое решение. Хоулетт подчёркивает, что нельзя считать самооценку модели достаточной защитой: вероятностная система не даёт гарантии, что заметит собственную ошибку. По сути, это тот же принцип разделения обязанностей, который команды давно применяют в безопасности: автор изменения не должен быть единственным контролёром.
Кодовая база становится контекстом для следующего агента
Третий контур касается уже не одного pull request, а накопленного состояния репозитория. Код, созданный сегодня, завтра станет исходным материалом для следующих агентов. Если в нём много устаревших зависимостей, дефектов, противоречивых паттернов и архитектурного долга, агент будет тратить больше времени на поиск, делать больше предположений и расходовать больше токенов. Поэтому разовая «генеральная уборка перед внедрением ИИ» не решает задачу: качество базы нужно поддерживать постоянно.
Практический набор метрик здесь заметно полезнее счётчика строк. В публикации советуют смотреть на размер и управляемость pull request, частоту релизов и cycle time, но сопоставлять их с качеством и рисками. Рост добавленных строк сам по себе не означает прогресс — скорее это повод спросить, не переложила ли команда лишнюю работу с автора кода на ревьюеров, CI и будущих сопровождающих. Для руководителя разработки это также аргумент не покупать «ускорение» отдельно от тестирования, статического анализа и правил поставки.
Главный вопрос в гонке за агентной разработкой теперь не «сколько кода способен сгенерировать инструмент», а «какой объём изменений команда способна уверенно принять в продукт». Если верификация ИИ-кода останется последним барьером перед merge, она станет очередью. Если перенести проверку ближе к генерации и поддерживать качество репозитория, скорость агентов можно превратить в темп поставки, а не в отложенный долг. Детали подхода и данные исследования приведены в материале .
