Как ИИ-агенты научились рефакторить код: что получается хорошо, а что не очень

Когда ИИ-агенты пишут код, они берут на себя всё больше сугубо человеческих задач – планирование, прогон тестов, да и даже последовательный рефакторинг. Авторы статьи Agentic Refactoring: An Empirical Study of AI Coding Agents впервые широко и глубоко посмотрели на эту практику: как агенты рефакторят в реальных open-source проектах, приносит ли это пользу и чем их стиль отличается от человеческого.

Почему это важно

Рефакторинг — это эффективное средство профилактики, которое избавляет от технических ошибок и снижает уровень технического долга. Он улучшает читаемость и сопровождение системы, подготавливает систему к будущим изменениям без изменения поведения ^[1] системы. LLM-агенты дополнительно позволяют автоматизировать рефакторинг кода, генерируя предложения по изменениям, сами разбивают задачу на шаги, прогоняют сценарии проверки изменений и предоставляют отчет о проделанной работе в виде Pull Request, выступая в некотором роде коллегой. Насколько это эффективно? Не станет ли автоматический рефакторинг источником новых проблем?

Как исследовали

Проведя анализ большого числа Java-проектов из датасета AIDev и коммиты, собранные на Github, авторы использовали RefactoringMiner (выделяет 103 типа изменений), чтобы определить наличие любых рефакторинговых изменений и наличие сигнала о намерении произвести именно рефакторинг в PR и сообщениях коммитов.

Как часто и как выглядит рефакторинг у агентов

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

Что именно меняют агенты при рефакторинге

Картина отличается от человеческой. У агентов доминируют рефакторинги с локальным воздействием – перемотка, работающее пространство, похожие операции. Коммиты людей чаще содержат изменения интерфейсов и архитектуры (входящие/исходящие зависимости). То есть агент скорее занимается «повседневным уходом» за кодовой базой и реже трогает архитектуру системы.

Даёт ли это измеримую пользу

Основные заявленные мотивы агента – сопровождаемость и читаемость (52.5 % и 28.1 % изменений соотвественно). Архитектурные мотивы встречаются гораздо реже чем у людей. То есть агент по своим объяснениям больше заботится об удобстве чтения кода, чем о переиспользовании кода и устранении его дублирования. В итоге улучшения в метриках есть, но небольшие.

Живые примеры

Разделение длинного метода на несколько вспомогательных. Классический способ повысить читаемость и сделать контроль потока программы более предсказуемым. PR ^[2]

Переименование различных переменных во многих файлах. Повышает понятность, но мало влияет на метрики структуры. PR ^[3]

Что это значит на практике

• Доверяйте агенту, чтобы справиться с рутиной. Такой рефакторинг уже полезен с точки зрения ^[4] типовых исправлений, выравнивания стиля, декомпозиции и сокращения времени на код-ревью.

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

Авторы изучают только Java-репозитории. “Agentic” коммиты, выделенные по сообщениям, могут содержать как другие правки, так и код, написанный людьми. Поэтому распространять эти результаты на другие языки и проектные контексты стоит с большой опаской.

Вывод

Агенты уже активно занимаются рефакторингом кода. Это приносит много пользы локально, но на уровне метрик выдающихся улучшений не наблюдается, как и эффекта на архитектуру. Поэтому роли стоит разделять: пусть на агентах остается гигиена системы, а архитектурные решения по-прежнему будут принимать люди.

📜 Полная статья ^[5]

💾 Код ^[6]

***

Если вам интересна тема ИИ, подписывайтесь на мой Telegram-канал ^[7] — там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.