Как я фиксил ошибки SonarQube и Roslyn при помощи ИИ-агентов
Несколько дней назад я провёл эксперимент с одним из наших легаси проектов. Это внутренний сервис, который был написан 3 года назад. С тех пор к нему никто не прикасался. В продакшене выполнялись только обновления райнтайма.
Это относительно небольшой проект с 11 тыс. строк кода. При этом в нём было более 500 ошибок (issue) от SonarQube и Roslyn.
Чего я хотел добиться
SonarQube – это инструмент, который мы используем для статического анализа код. Мы также стараемся поддерживать “чистоту” в репозиториях, чтобы не накапливался технический долг. Но конкретно этот проект был разработан давно, ещё до того, как мы интегрировали SonarQube в наши CI-CD-пайплайны. Поэтому в нём накопилось много проблем.
Большинство проблем были безобидными. Например, название приватного поля не соответствует правилам, или приватное поле без ключевого слова readonly, или внутренний метод без доступа к внутренним параметрам, который можно объявить статическим, и так далее.
То есть большинство проблем можно легко исправить вручную, но, тем не менее, на это требуется время, а сама задача скучная и монотонная.
Harness и LLM
Я использовал GitHub Copilot потому, что мой работодатель предоставляет подписку. Думаю, аналогичный подход можно реализовать и с помощью любого другого агента.
В качестве LLM я выбрал GPT-6 Luna. Это одна из самых дешёвых моделей в GitHub Copilot. Параметры модели были по умолчанию: размер контекстного окна в 272K токенов и средний уровень ризонинга.
Про итоговую стоимость рассказано в конце.
Кастомный агент
Я потратил какое-то время на написание промпта для агента и помимо базовых инструментов VS Code и GitHub Copilot, я выдал агенту доступ к SonarQube MCP и Microsoft Learn MCP для чтения их документации.
Финальная версия агента работала в две фазы.
Фаза 1. Подготовка
Агент собирает все доступные проблемы SonarQube для текущего репозитория и ветки. SonarQube MCP возвращает результаты постранично. Поэтому агент должен преобразовать эти результаты в единый JSON-файл с полным списком проблем.
Чтобы уменьшить размер файла, я оставил только необходимую информацию:
- GUID проблемы;
- код проблемы;
- путь к файлу;
- номер строки в файле;
- краткое описание.
Фаза 2. Цикл
1. Агент читает JSON-файл и ищет первую нерешённую проблему.
2. Затем он ищет информацию о проблеме в документации через SonarQube MCP или Microsoft Learn MCP, чтобы найти наиболее подходящий способ исправления.
3. После того вся необходимая информация собрана, он исправляет проблему, помечает соответствующий элемент в JSON-файле как FIXED и делает commit с результатами. После этого цикл повторяется.
Оценка трудозатрат
SonarQube оценивал необходимые трудозатраты в 3 рабочих дня и 3 часа. Но 289 проблем не имели оценки времени – SonarQube просто указывал для них 0 min, что, на мой взгляд, неправильно.
Даже самая маленькая проблема вроде «пометить поле как readonly» требует одной-двух минут на исправление: открыть портал SonarQube, найти проблему, найти файл и нужное место в файле, понять контекст и наконец внести исправление.
В общей сложности я оценил, что для исправления всех 500+ проблем человеку бы понадобилось около 1 рабочей недели, с учётом того, что разработчику нужны перерывы на кофе, туалет и обед.
Результаты
Я запустил агента 1 октября 2026 года в 10:28 (четверг). Последняя проблема была исправлена 2 октября 2026 года в 15:24 (пятница). Но агент не работал всё это время непрерывно – несколько раз его работа прерывалась.
Один раз возникла временная проблема с сетью. Пришлось запускать агента вручную.
Я также остановил агента в конце рабочего дня в четверг. Мне пришлось это сделать, потому что по пятницам я работаю из дома и мне нужно было забрать ноутбук домой.
Когда я приехал домой, то снова запустил цикл, и работа продолжалась до 2:00 ночи, после чего агент остановился, потому что не смог запустить субагента для поиска следующей проблемы. Утром пришлось снова запускать агента вручную.
Позже проблема с вызовом субагента возникла ещё несколько раз. Я попытался сделать промпт более надёжным, добавив конкретные инструкции о том, как вызывать сабагента корректно, но это не особо помогло.
С периодическими ручными вмешательствами агент продолжал работать и в 15:24 закончил работу.
В результате получился MR из 554 коммитов. Было изменено 171 файлов. Мы потратили 1402 кредитов, что примерно эквивалентно $14.
Я проверил большую часть изменений и не заметил никаких проблем. Пайплайн зелёный. Можно считать, что ИИ хорошо подходит для таких подоизменений в коде.
#программирование@yet_another_dev
Несколько дней назад я провёл эксперимент с одним из наших легаси проектов. Это внутренний сервис, который был написан 3 года назад. С тех пор к нему никто не прикасался. В продакшене выполнялись только обновления райнтайма.
Это относительно небольшой проект с 11 тыс. строк кода. При этом в нём было более 500 ошибок (issue) от SonarQube и Roslyn.
Чего я хотел добиться
SonarQube – это инструмент, который мы используем для статического анализа код. Мы также стараемся поддерживать “чистоту” в репозиториях, чтобы не накапливался технический долг. Но конкретно этот проект был разработан давно, ещё до того, как мы интегрировали SonarQube в наши CI-CD-пайплайны. Поэтому в нём накопилось много проблем.
Большинство проблем были безобидными. Например, название приватного поля не соответствует правилам, или приватное поле без ключевого слова readonly, или внутренний метод без доступа к внутренним параметрам, который можно объявить статическим, и так далее.
То есть большинство проблем можно легко исправить вручную, но, тем не менее, на это требуется время, а сама задача скучная и монотонная.
Harness и LLM
Я использовал GitHub Copilot потому, что мой работодатель предоставляет подписку. Думаю, аналогичный подход можно реализовать и с помощью любого другого агента.
В качестве LLM я выбрал GPT-6 Luna. Это одна из самых дешёвых моделей в GitHub Copilot. Параметры модели были по умолчанию: размер контекстного окна в 272K токенов и средний уровень ризонинга.
Про итоговую стоимость рассказано в конце.
Кастомный агент
Я потратил какое-то время на написание промпта для агента и помимо базовых инструментов VS Code и GitHub Copilot, я выдал агенту доступ к SonarQube MCP и Microsoft Learn MCP для чтения их документации.
Финальная версия агента работала в две фазы.
Фаза 1. Подготовка
Агент собирает все доступные проблемы SonarQube для текущего репозитория и ветки. SonarQube MCP возвращает результаты постранично. Поэтому агент должен преобразовать эти результаты в единый JSON-файл с полным списком проблем.
Чтобы уменьшить размер файла, я оставил только необходимую информацию:
- GUID проблемы;
- код проблемы;
- путь к файлу;
- номер строки в файле;
- краткое описание.
Фаза 2. Цикл
1. Агент читает JSON-файл и ищет первую нерешённую проблему.
2. Затем он ищет информацию о проблеме в документации через SonarQube MCP или Microsoft Learn MCP, чтобы найти наиболее подходящий способ исправления.
3. После того вся необходимая информация собрана, он исправляет проблему, помечает соответствующий элемент в JSON-файле как FIXED и делает commit с результатами. После этого цикл повторяется.
Оценка трудозатрат
SonarQube оценивал необходимые трудозатраты в 3 рабочих дня и 3 часа. Но 289 проблем не имели оценки времени – SonarQube просто указывал для них 0 min, что, на мой взгляд, неправильно.
Даже самая маленькая проблема вроде «пометить поле как readonly» требует одной-двух минут на исправление: открыть портал SonarQube, найти проблему, найти файл и нужное место в файле, понять контекст и наконец внести исправление.
В общей сложности я оценил, что для исправления всех 500+ проблем человеку бы понадобилось около 1 рабочей недели, с учётом того, что разработчику нужны перерывы на кофе, туалет и обед.
Результаты
Я запустил агента 1 октября 2026 года в 10:28 (четверг). Последняя проблема была исправлена 2 октября 2026 года в 15:24 (пятница). Но агент не работал всё это время непрерывно – несколько раз его работа прерывалась.
Один раз возникла временная проблема с сетью. Пришлось запускать агента вручную.
Я также остановил агента в конце рабочего дня в четверг. Мне пришлось это сделать, потому что по пятницам я работаю из дома и мне нужно было забрать ноутбук домой.
Когда я приехал домой, то снова запустил цикл, и работа продолжалась до 2:00 ночи, после чего агент остановился, потому что не смог запустить субагента для поиска следующей проблемы. Утром пришлось снова запускать агента вручную.
Позже проблема с вызовом субагента возникла ещё несколько раз. Я попытался сделать промпт более надёжным, добавив конкретные инструкции о том, как вызывать сабагента корректно, но это не особо помогло.
С периодическими ручными вмешательствами агент продолжал работать и в 15:24 закончил работу.
В результате получился MR из 554 коммитов. Было изменено 171 файлов. Мы потратили 1402 кредитов, что примерно эквивалентно $14.
Я проверил большую часть изменений и не заметил никаких проблем. Пайплайн зелёный. Можно считать, что ИИ хорошо подходит для таких подоизменений в коде.
#программирование@yet_another_dev