Статический анализ кода и ИИ-разработка

Мы все уже не раз видели, как какая-то компания переписала проект с языка 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

Любители Масс Эффекта, как дела?

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

Уязвимость позволяла выполнять произвольный код (RCE). Для этого достаточно было послать определенный запрос на сервер.

И тогда на полном серьёзе предлагалось эксплуатировать саму уязвимость чтобы пропатчить библиотеку.

Так что в шутке на картинке лишь доля шутки.

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

Финансовая сторона Slopless

Проект Slopless был и остаётся бесплатным для всех пользователей. Но поддержка проекта требует определённых затрат. Траты на инфраструктуру обходятся примерно в ₽30K в год:

- Домен: $21.11 в год.
- VPS для бэкенда и базы данных: €13.72 в месяц (€164.64 в год).
- S3 для бэкапов: €6.49 в месяц (€77.88 в год).
- Подписка на Yandex Plus: ₽4490 в год. Без неё недоступно скачивание полных треков для классификатора.

При условии, что курс евро будет ₽91, а доллара ₽79, то в год выходит ₽28227.

Я открыл сбор в Т-банке на сумму ₽30К. Пользователи расширения могут поддержать проект перечислив деньги на этот счёт. Ссылка также добавлена в само расширение, на сайт и в бота обратной связи.

Если к концу этого года удастся собрать хотя бы половину, то проект продолжит своё существование. Если нет, то постепенно отправится в архив и летом полностью прекратит своё существование.

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

Майки предложили добровольно уволиться 60 тыс. сотрудникам (около 27% штата).

Ну что, пора уже обучаться новой профессии?