yet another dev

Как я фиксил ошибки 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

Что интересного в этой статье:

1. Потрачено $120К, а агенты суммарно отработали около 3-х недель. Вся работа фактически заняла на 14.5 недель. Очевидно, что пока не получается просто поручить задачу агентам и пойти лежать на диване. Приходится проверять работу, вносить корректировки и так далее.

2. Переписываемый проект должен быть покрыт E2E тестами вдоль и поперек. У Copilot было много таких тестов, но даже это не помогло от регрессии.

Microsoft выкатывали pre-release версии в продакшн, чтобы протестировать на реальных пользователях и дополнительно исправляли обнаруженные баги.

3. «Чатжипити, перепиши мне проект на Rust» всё ещё не работает.

Разработчикам необходимо было отлично понимать архитектуру проекта для грамотного планирования миграции.

Кроме того, разработчикам иногда приходилось детально и на довольно низком уровне описывать желаемый результат из-за того, что агенты делали не то, что требуется.

Короче, программировать пока ещё надо уметь.

#программирование@yet_another_dev

Лайфхак: экономим токены в GitHub Copilot

Если вы, как и я, пользуетесь VS Code в связке с Copilot, то вот вам несколько лайфхаков для экономии токенов/кредитов:

1. Я использую только GPT-5.6 Luna потому что это одна из самых дешёвых моделей, которая пишет добротный код. Но агент VS Code может использовать другие модели для исследования, вызова сабагентов, вызова инструментов (tools), автокомплита и так далее.

Можно сделать так, чтобы агент VS Code использовал только нужную вам модель, указав её название в settings.json.

{
"chat.defaultModel": "GPT-5.6 Luna (Copilot)",
"chat.exploreAgent.defaultModel": "GPT-5.6 Luna (copilot)",
"chat.planAgent.defaultModel": "GPT-5.6 Luna (copilot)",
"github.copilot.chat.askAgent.model": "GPT-5.6 Luna (Copilot)",
"github.copilot.chat.exploreAgent.model": "GPT-5.6 Luna (Copilot)",
"github.copilot.chat.implementAgent.model": "GPT-5.6 Luna (Copilot)",
"github.copilot.selectedCompletionModel": "GPT-5.6 Luna (Copilot)",
"inlineChat.defaultModel": "GPT-5.6 Luna (copilot)",
}

2. Вызовы некоторых инструментов могут сопровождаться длинным выводом. В прошлом году я писал об этом пост. В VS Code сейчас появились настройки, которые позволяют сжимать вывод CLI-утилит или вывод инструментов:

{
"chat.tools.compressOutput.enabled": true,
"chat.tools.terminal.outputCompaction": true,
"chat.tools.terminal.outputDeltas": true,
}
#программирование@yet_another_dev

👩‍💻 Используем OpenAPI для синхронизации API на Frontend и Backend

Ровно год назад писал пост про синхронизацию через OpenAPI.

Тот подход был основан на Swagger. С тех пор в .NET появился встроенный функционал для генерации спецификаций OpenAPI. Держите короткий гайд:

1. Создаём новый проект:

mkdir -p backend
cd backend
dotnet new webapi

По умолчанию файл проекта backend.csproj уже использует нужный пакет Microsoft.AspNetCore.OpenApi.



Можно запустить приложение и перейти по адресу https://localhost:{port}/openapi/v1.json, чтобы убедиться, что всё работает.

2. Следующий шаг – автоматическая генерация спецификации в виде файла.

Для этого нужно установить ещё один пакет:

dotnet add package Microsoft.Extensions.ApiDescription.Server

И включить генерацию при сборке, добавив в backend.csproj вот этот блок:

⚡️DeepSeek В-С-Ё

Беру свои слова обратно. Спустя 4 месяца я вернулся к GitHub Copilot. Недавнее изменение цен на модели DeepSeek сделало их менее выгодными. Например, я пополнил счёт 14 августа на $10 и к 30 августа уже всё было потрачено. Использовалась только Flash модель в связке с OpenCode.

За это время стоимость Copilot Pro не изменилась — всё те же $10. Плюс Copilot в том, что там есть GPT-5.6 Luna. Эта модель дешёвая и хорошо пишет код. На работе я использую только её.

#программирование@yet_another_dev

В Slopless появился бот обратной связи

Наконец-то я навайбкодил бота обратной связи. Теперь об ошибках в маркировке можно сообщать тут: @slopless_feedback_bot.

Бот запрашивает:

1. Корректную маркировку
2. Ссылку на артиста в Яндекс Музыке
3. Ссылки на трек(и) артиста в Яндекс Музыке, маркировку которых надо исправить.
4. Ссылку на артиста в Deezer (опционально)
5. Скриншот проверки треков в submithub (опционально)

Чем больше информации будет прислано, тем быстрее мною будет обработан запрос.

#нейромузыка@yet_another_dev

Прошло 3 месяца с момента принятия закона о "соответствии сетевых адресов доменным именам" и вот появились первые практические попытки осуществить DNS-спуфинг от нашего родного начальства. Конечно же, исключительно с целью заботы о нашей безопасности.

⚡️Slopless рекомендуют в Госдуме

Ну я даже не знаю как реагировать. Тема с нейрослопом уже дошла до нашего мудрого начальства и теперь они рекомендуют Slopless.

В целом, всё идёт таким образом, как я описывал месяц назад:

«Яндекс Музыка» намерена предоставить артистам и правообладателям возможность информировать слушателей об использовании искусственного интеллекта при создании музыки. Эти планы «Известиям» подтвердили в компании.

Кстати, ранее депутат Горелкин, ник в Telegram которого «Интернет-душитель», заявлял ТАСС:

Маркировка сгенерированного контента может утратить актуальность, так как в будущем придется помечать уже 90% всех публикаций. При этом обязательная проверка маркировки приведет к высоким затратам соцсетей на автоматизированные программы.

Но как мы выяснили, детектить нейрослоп довольно просто и совсем не дорого. По крайней мере в музыке. Бюджет Slopless ~€15 в месяц. Требуемые вычислительные мощности — дешёвый сервер на Linux. Вам даже GPU не нужен. Представьте, что бы мог сделать Яндекс, если бы захотел?

А вообще, маркировка и детект ИИ контента — две похожие, но принципиально разные вещи. Не надо путать и заменять одно другим.

На загнивающем западе во всю развиваются и совершенствуются методы выявления ИИ. Но также и развиваются стандарты C2PA (Коалиция по происхождению и подлинности контента) для маркировки контента.

Если реализовать стандарт C2PA, то у пользователей будет возможность проверить, какие инструменты использовались для его создания и изменения. И всё это дело будет криптографически проверяемо, потому что технически основано на подписях и работает аналогично PKI. Можете посмотреть короткий ролик о том, как это примерно работает.

#нейромузыка@yet_another_dev

Мой опыт использования reg[.]ru

#программирование@yet_another_dev

На прошлой неделе перевёз свой домен alexeyfv.xyz из рег ру в porkbun. Жалею, что не сделал это раньше — сэкономил бы деньги.

Почему я бы никому не советовал пользоваться рег ру:

1. Цены. В рег-ру я продлевал домен в январе 25 года. Тогда стоимость была ~5000 рублей за 2 года. В porkbun сейчас продление моего домена на 2 года стоит ~2000 рублей ($25.96). Разница примерно в 2 раза.

2. Скрытие информации из WHOIS — это платная услуга в рег ру. И меня всегда это бесило. Эта контора прекрасных людей и так собирает все возможные данные о вас. А потом ещё попросит заплатить денег, чтобы не публиковать их в открытый досутп. В porkbun достаточно просто оплатить домен. Скрытие данных автоматическое.