
Когда ИИ-агенты пишут код, они берут на себя всё больше сугубо человеческих задач - планирование, прогон тестов, да и даже последовательный рефакторинг. Авторы статьи Agentic Refactoring: An Empirical Study of AI Coding Agents впервые широко и глубоко посмотрели на эту практику: как агенты рефакторят в реальных open-source проектах, приносит ли это пользу и чем их стиль отличается от человеческого.
Почему это важно
Рефакторинг — это эффективное средство профилактики, которое избавляет от технических ошибок и снижает уровень технического долга. Он улучшает читаемость и сопровождение системы, подготавливает систему к будущим изменениям без изменения поведения системы. LLM-агенты дополнительно позволяют автоматизировать рефакторинг кода, генерируя предложения по изменениям, сами разбивают задачу на шаги, прогоняют сценарии проверки изменений и предоставляют отчет о проделанной работе в виде Pull Request, выступая в некотором роде коллегой. Насколько это эффективно? Не станет ли автоматический рефакторинг источником новых проблем?
Как исследовали
Проведя анализ большого числа Java-проектов из датасета AIDev и коммиты, собранные на Github, авторы использовали RefactoringMiner (выделяет 103 типа изменений), чтобы определить наличие любых рефакторинговых изменений и наличие сигнала о намерении произвести именно рефакторинг в PR и сообщениях коммитов.

Как часто и как выглядит рефакторинг у агентов
Это довольно распространенная практика: 26.1% Java-коммитов явно посвящены рефакторингу и демонстрируют больше рефакторинговых операций за счёт того, что они сконцентрированы в одном месте. То есть это не побочный эффект других правок, а именно продуманная задача (часто в отдельном PR).

Что именно меняют агенты при рефакторинге
Картина отличается от человеческой. У агентов доминируют рефакторинги с локальным воздействием - перемотка, работающее пространство, похожие операции. Коммиты людей чаще содержат изменения интерфейсов и архитектуры (входящие/исходящие зависимости). То есть агент скорее занимается «повседневным уходом» за кодовой базой и реже трогает архитектуру системы.
Даёт ли это измеримую пользу
Основные заявленные мотивы агента - сопровождаемость и читаемость (52.5 % и 28.1 % изменений соотвественно). Архитектурные мотивы встречаются гораздо реже чем у людей. То есть агент по своим объяснениям больше заботится об удобстве чтения кода, чем о переиспользовании кода и устранении его дублирования. В итоге улучшения в метриках есть, но небольшие.

Живые примеры
Разделение длинного метода на несколько вспомогательных. Классический способ повысить читаемость и сделать контроль потока программы более предсказуемым. PR
Переименование различных переменных во многих файлах. Повышает понятность, но мало влияет на метрики структуры. PR
Что это значит на практике
Доверяйте агенту, чтобы справиться с рутиной. Такой рефакторинг уже полезен с точки зрения типовых исправлений, выравнивания стиля, декомпозиции и сокращения времени на код-ревью.

В половине задач рефакторинг перемешан с другими правками. От агентов стоит дополнительно требовать коммитов и группировки однотипных изменений.

Авторы изучают только Java-репозитории. “Agentic” коммиты, выделенные по сообщениям, могут содержать как другие правки, так и код, написанный людьми. Поэтому распространять эти результаты на другие языки и проектные контексты стоит с большой опаской.
Вывод
Агенты уже активно занимаются рефакторингом кода. Это приносит много пользы локально, но на уровне метрик выдающихся улучшений не наблюдается, как и эффекта на архитектуру. Поэтому роли стоит разделять: пусть на агентах остается гигиена системы, а архитектурные решения по-прежнему будут принимать люди.
***
Если вам интересна тема ИИ, подписывайтесь на мой Telegram-канал — там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.
Wesha
Я за такие коммиты линейкой по пальцам бью. Нахуа выносить три строчки в отдельный метод, если он нигде не переиспользуется??? Если «трудно читать» — так отдели его комментарием от окружающего кода, для визуальной группировки строчек. Но зачем, сцуко, стек без нужды дёргать, новую область видимости заводить, убеждаться, что все требуемые переменные в неё попадают...