Когда ИИ-агенты пишут код, они берут на себя всё больше сугубо человеческих задач – планирование, прогон тестов, да и даже последовательный рефакторинг. Авторы статьи 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-канал — там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.
Автор: andre_dataist
