Опубликовал вчера ролик в одной запрещённой в России соцсети про то, как сходил на выборы.
Видео максимально беззубое. Я не упоминал названия партий, не давал им оценку, не рассказывал как голосовал. Просто рассказал что пошёл на избирательный участок, показал людей.
Видео взлетело на 43К просмотров. Алгоритмы там всё-таки хорошо работают.
И без срача в комментах не обошлось, конечно же. Отобрал для вас самое интересное на скринах. :)
Собственно, как я и говорил, обыватель в любом случае крайний.
Но большая часть комментариев (140+) была поддерживающая, что не может не радовать. Жаль, что это не помогло.
Видео максимально беззубое. Я не упоминал названия партий, не давал им оценку, не рассказывал как голосовал. Просто рассказал что пошёл на избирательный участок, показал людей.
Видео взлетело на 43К просмотров. Алгоритмы там всё-таки хорошо работают.
И без срача в комментах не обошлось, конечно же. Отобрал для вас самое интересное на скринах. :)
Собственно, как я и говорил, обыватель в любом случае крайний.
Но большая часть комментариев (140+) была поддерживающая, что не может не радовать. Жаль, что это не помогло.
❤8😁7🤡2
Как я фиксил ошибки 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
👍6
Так-с, важный вопрос. Каким облачным хранилищем вы пользуетесь? Я в 22 году переехал в Яндекс Диск из-за того, что не мог оплачивать Google Drive. Чувствую, что пришло время переезжать в другое место.
😁3❤2🔥1💯1
yet another dev
Так-с, важный вопрос. Каким облачным хранилищем вы пользуетесь? Я в 22 году переехал в Яндекс Диск из-за того, что не мог оплачивать Google Drive. Чувствую, что пришло время переезжать в другое место.
Мы выбрали Google Drive. У них более менее адекватный ценник и, в целом, знакомая экосистема. Хочу мигрировать данные асап. А серваком можно заняться позднее.
Я ещё рассматривал Proton, но у них плохая интеграция с rclone, да и ценник почти в 2 раза выше, чем у Google.
Подписка на Google One 2 Тб стоит $100 в год. Хранилище можно пошарить с членами семьи. В итоге, выходит где-то 2-3 раза дороже, чем Яндекс Диск.
Данные мигрирую при помощи rclone. Интеграция с Яндексом у него прекрасная. А вот с Google пришлось повозиться – доступ к Drive только через API, который включается через Google Cloud Console, а ещё там надо настраивать креды и т.д.
Кстати, важный момент о котором я не знал. В мобильном приложении Яндекс Диска есть функция автозагрузки фото и видео. И они могут загружаться в так называемое "безлимитное хранилище".
Прикол в том, что это безлимитное хранилище существует отдельно от Яндекс Диска и поэтому rclone его не видит.
Я вчера потратил несколько часов перенося вручную фотографии по 500 штук (лимит Яндекса) из безлимитного хранилища на Диск. Какого-то удобного инструмента для этого в приложении и веб-версии конечно же не предусмотрено.
Я ещё рассматривал Proton, но у них плохая интеграция с rclone, да и ценник почти в 2 раза выше, чем у Google.
Подписка на Google One 2 Тб стоит $100 в год. Хранилище можно пошарить с членами семьи. В итоге, выходит где-то 2-3 раза дороже, чем Яндекс Диск.
Данные мигрирую при помощи rclone. Интеграция с Яндексом у него прекрасная. А вот с Google пришлось повозиться – доступ к Drive только через API, который включается через Google Cloud Console, а ещё там надо настраивать креды и т.д.
Кстати, важный момент о котором я не знал. В мобильном приложении Яндекс Диска есть функция автозагрузки фото и видео. И они могут загружаться в так называемое "безлимитное хранилище".
Прикол в том, что это безлимитное хранилище существует отдельно от Яндекс Диска и поэтому rclone его не видит.
Я вчера потратил несколько часов перенося вручную фотографии по 500 штук (лимит Яндекса) из безлимитного хранилища на Диск. Какого-то удобного инструмента для этого в приложении и веб-версии конечно же не предусмотрено.
Мне удалось скопировать в Google Drive практически все данные с Яндекс Диска. Осталось только 3 файла, которые всё ещё недоступны.
Изначально файлов с ошибками было 54. Но вчера утром я написал в техподдержку. Там оперативно ответили и устранили проблему. За это, конечно, огромная благодарность. Вообще, шутки про собесы Яндекса — это забавно, но инженерам Яндекса сейчас можно только посочувствовать и выразить уважение.
НО! Это всё было вчера.
А сегодня ночью Яндекс потерял ещё один ДЦ во Владимире. И сегодня я наблюдаю, что многие файлы недоступны уже через web-интерфейса Диска. Раньше такого не было.
И ещё, Яндекс вчера обновил своё пользовательское соглашение и включил БПЛА в список причин, по которым он снимает с себя ответственность. Короче, спасение фоточек только в наших руках.
Изначально файлов с ошибками было 54. Но вчера утром я написал в техподдержку. Там оперативно ответили и устранили проблему. За это, конечно, огромная благодарность. Вообще, шутки про собесы Яндекса — это забавно, но инженерам Яндекса сейчас можно только посочувствовать и выразить уважение.
НО! Это всё было вчера.
А сегодня ночью Яндекс потерял ещё один ДЦ во Владимире. И сегодня я наблюдаю, что многие файлы недоступны уже через web-интерфейса Диска. Раньше такого не было.
И ещё, Яндекс вчера обновил своё пользовательское соглашение и включил БПЛА в список причин, по которым он снимает с себя ответственность. Короче, спасение фоточек только в наших руках.
🫡4👀3😱2👍1
Что не так с маркировкой ИИ от Яндекс Музыки
На прошлых выходных появилось настроение поработать над Slopless. Как раз в GitHub предложили в расширении учитывать маркировку от Яндекса. Этим я и занялся.
За выходные я сравнил разметку Slopless и Яндекс для всех треков начиная с 2024 года, у которых есть хотя бы один лайк.
По оценке Slopless, 27% из проверенных треков созданы с помощью ИИ, а по оценке Яндекса — таких треков не более 18%.
Оценка Яндекса более комплексная. Там есть 3 категории:
- возможно ИИ;
- частично ИИ;
- полностью ИИ.
Две последние категории основаны на данных от дистрибьюторов. Некоторые из них добровольно собирают и передают информацию о том, как был использован ИИ при создании музыки: для аранжировки, для вокала или же трек сгенерирован полностью. Категория «возможно, ИИ» — это результат работы детектора ИИ от Яндекса.
Но, как я уже писал ранее, дистрибьюторы не обязаны передавать информацию об использовании ИИ, и многие этого не делают. В особенности создатели виртуальных ИИ-артистов.
Детектор ИИ от Яндекса не маркирует всю музыку таких исполнителей. А из-за того что маркировка Яндекса спрятана в метаданных треков, для пользователей эта информация труднодоступна.
Вот примеры некоторых таких исполнителей:
- Детские колыбельные
- Музыка для сна
- Музыка для сна младенцев
- Музыка для сна малыша
- КОЛЫБЕЛЬНЫЕ
- Музыка для медитации
- Спокойная фоновая музыка
- Iren Lullaby
Попробуйте там найти промаркированные треки.
#нейромузыка@yet_another_dev
На прошлых выходных появилось настроение поработать над Slopless. Как раз в GitHub предложили в расширении учитывать маркировку от Яндекса. Этим я и занялся.
За выходные я сравнил разметку Slopless и Яндекс для всех треков начиная с 2024 года, у которых есть хотя бы один лайк.
По оценке Slopless, 27% из проверенных треков созданы с помощью ИИ, а по оценке Яндекса — таких треков не более 18%.
Оценка Яндекса более комплексная. Там есть 3 категории:
- возможно ИИ;
- частично ИИ;
- полностью ИИ.
Две последние категории основаны на данных от дистрибьюторов. Некоторые из них добровольно собирают и передают информацию о том, как был использован ИИ при создании музыки: для аранжировки, для вокала или же трек сгенерирован полностью. Категория «возможно, ИИ» — это результат работы детектора ИИ от Яндекса.
Но, как я уже писал ранее, дистрибьюторы не обязаны передавать информацию об использовании ИИ, и многие этого не делают. В особенности создатели виртуальных ИИ-артистов.
Детектор ИИ от Яндекса не маркирует всю музыку таких исполнителей. А из-за того что маркировка Яндекса спрятана в метаданных треков, для пользователей эта информация труднодоступна.
Вот примеры некоторых таких исполнителей:
- Детские колыбельные
- Музыка для сна
- Музыка для сна младенцев
- Музыка для сна малыша
- КОЛЫБЕЛЬНЫЕ
- Музыка для медитации
- Спокойная фоновая музыка
- Iren Lullaby
Попробуйте там найти промаркированные треки.
#нейромузыка@yet_another_dev
👍7
Статический анализ кода и ИИ-разработка
Мы все уже не раз видели, как какая-то компания переписала проект с языка X на Rust при помощи ИИ. За примерами ходить не надо:
1. Microsoft переписали рантайм Copilot CLI с TypeScript на Rust.
2. Anthropic переписали рантайм Bun с Zig на Rust.
После моей истории с исправлением ошибок SonarQube при помощи ИИ, я начал догадываться почему для переписывания выбирают Rust – у него очень строгий компилятор, который просто не даст собраться проекту, если что-то не так.
Но похожего поведения можно добиться и с C#, например, а затем использовать такой подход не только для переписывания существующих проектов, но и для написания нового кода.
После исправления ошибок SonarQube я поэкспериментировал с возможностями .NET: добавил .editorconfig, указал там правила и сделал так, чтобы они вызывали ошибку при сборке.
Например, сейчас Microsoft рекомендует использовать LoggerAttribute для высокопроизводительного логирования. Но если жёстких ограничений нет, то ИИ всё равно может писать про старому.
Включив проверку правила CA1873, можно добиться от агента нужного кода. У него просто не будет другого выбора, кроме как писать правильный код.
Иначе говоря, детерминированность кода зависит от строгости анализаторов. Чем больше правил выбрасывают ошибки при сборке, тем более детерминированный будет результат.
Но такие проверки кода помогают определить только «форму» кода и не влияют на «смысл», то есть бизнес логику. Проверка бизнес логики – другая задача и должна решаться следующим уровнем проверок, а именно тестами.
#программирование@yet_another_dev
Мы все уже не раз видели, как какая-то компания переписала проект с языка X на Rust при помощи ИИ. За примерами ходить не надо:
1. Microsoft переписали рантайм Copilot CLI с TypeScript на Rust.
2. Anthropic переписали рантайм Bun с Zig на Rust.
После моей истории с исправлением ошибок SonarQube при помощи ИИ, я начал догадываться почему для переписывания выбирают Rust – у него очень строгий компилятор, который просто не даст собраться проекту, если что-то не так.
Но похожего поведения можно добиться и с C#, например, а затем использовать такой подход не только для переписывания существующих проектов, но и для написания нового кода.
После исправления ошибок SonarQube я поэкспериментировал с возможностями .NET: добавил .editorconfig, указал там правила и сделал так, чтобы они вызывали ошибку при сборке.
Например, сейчас Microsoft рекомендует использовать LoggerAttribute для высокопроизводительного логирования. Но если жёстких ограничений нет, то ИИ всё равно может писать про старому.
Включив проверку правила CA1873, можно добиться от агента нужного кода. У него просто не будет другого выбора, кроме как писать правильный код.
Иначе говоря, детерминированность кода зависит от строгости анализаторов. Чем больше правил выбрасывают ошибки при сборке, тем более детерминированный будет результат.
Но такие проверки кода помогают определить только «форму» кода и не влияют на «смысл», то есть бизнес логику. Проверка бизнес логики – другая задача и должна решаться следующим уровнем проверок, а именно тестами.
#программирование@yet_another_dev
👍5✍2🔥1