Комментарии 27
Слышали что нибудь про модель ChatGPT? И я нет, но у автора она есть. Вроде не много цифр нужно, одна-две, чтобы написать конкретную модель.
Каковы комплексные результаты сравнения со статическими анализаторами кода? Или цель была заменить классический алгоритм нейросетевым и посмотреть, что получится?
Серьезного сравнения с топовыми статическими анализаторами, такими как SwiftLint или SonarQube, не проводилось. Однако субъективно, они уже уступают анализу с использованием нейронной сети. Даже при грубой настройке удавалось находить больше критических ошибок, при этом ошибки, которые выявляют статические анализаторы, также не оставались незамеченными. Мы проводили проверки на Swift, но до анализа на Java или Go пока не дошли. Тем не менее, возможно, на других языках ситуация обстоит иначе.
Спасибо, за интересный вопрос.
Насчет Swift ничего сказать не могу, но для Си++ SonarQube никоим образом не тянет на топовой анализатор, несмотря на генерацию массы подсказок. PVS Studio в наших тестах оказался на голову выше.
Интересно. А какие модели использовали?
Всё "из коробки" без дополнительных настроек, кодовая база небольшая около 100К строк, тесты делали 4 года назад. Цена разнилась, соответственно: 100 долл/год за лицензию у Сонара и до 10К у PVS
4 года назад все-таки давненько... сейчас меняется чуть ли каждый месяц модели... у меня опыт со стат анализаторами небольшой есть и они не так быстро эволюционируют... Пока статью писал, появились новые версии доступных моделей не говоря о платных... ИМХО все скатывается в использование нейронок. Статические анализаторы останутся, но их будет меньше... Но посмотрим. Да, и опять же никто не запрещает использовать оба подхода на одном проекте, если все работает локально.
Если нужно решить проблему одноразово, то очередная модель сможет помочь, видимо. Если анализ кода включен в цепочку разработки, то проблема недетерминированности встанет в полный рост. С тем же успехом можно пытаться заменять компилятор и получать всякий раз разные результаты даже на одном и том же наборе исходников. А ведь исходники активно меняются. Также ключевым показателем будет процент ложных срабатываний, требующий участия оператора
Эффективность моделей зависит от их правильного встраивания в процесс, наличия механизмов контроля качества и прозрачных метрик оценки их работы. При хорошей настройке они могут стать инструментом, дополняющим существующие этапы разработки. Соглашусь, что проблем масса их все предстоит решить и от проекта к проекту они будут проявляться по разному.
топовыми статическими анализаторами, такими как SwiftLint или SonarQube
А вот сейчас PVS-Studio обидно было.
.
Используем авторевью около года. Полезная штука. Редко, когда срабатывает неправильно. Предусмотрен фидбек. Ещё пишет summary по изменения. Прямо чудеса.
Немного вопросов в основном морально-этического характера
1) было ли решение о внедрении ИИ-ревью демократически-коллегиальным или спущенным сверху на разработчиков?
2) почему был выбран строгий тон ревьювера? не кажется ли Вашим коллегам он токсичным и душным?
3) насколько ИИ-ревью обязательно к резолву? Можно ли резолвить с пустым ответом.
Что если ИИ ошибается в совете, должен ли разработчик обосновывать ошибочное суждении ИИ. Описаны ли подобные схемы в style guide отдела.
Интересные вопросы, раньше не рассматривал их с такой точки зрения.
Идея использования LLM для код-ревью у меня появилась ещё пару лет назад, но основным препятствием была безопасность — из-за невозможности развернуть решение локально многие коллеги были против. Как только появилась техническая возможность, удалось уговорить команду попробовать. И я об этом не жалею.
Тон ревью был выбран скорее формальным, чтобы на первых порах покрыть большинство стандартных требований в проектах. Хотелось, чтобы модель максимально тщательно проверяла код.
Комментарии ИИ — это всего лишь подсказки, которые могут содержать ошибки или ложные срабатывания. Это похоже на работу со статическими анализаторами: их предупреждения и исправления остаются на усмотрение разработчика. ИИ просто помогает находить проблемы, но, в отличие от живого ревьюера, не спорит и не обижается.
С живым ревьюрером можно поговорить, оспорить его ревью. А здесь в пайплайне это не предусмотрено. Можно ли расширить?
Отличная идея! Возьму на заметку. Чат можно прикрутить.
А что это даст? LLM обладает близко к нулевой сопротивляемостью к изменениям. Ей скажи "мы тут делает так, потому что...." и дальше любую чушь, и она согласится.
Чат нужен не для спора с LLM, а для удобной коммуникации. Он позволит уточнять детали, объяснять причины решений и быстрее находить компромиссы. LLM не заменяет ревьюера, но может ускорить процесс и сделать его более интерактивным. А если нужна критика изменений, можно предусмотреть гибридный вариант — например, в сложных случаях подключать живого ревьюера.
Я один не понимаю как можно ревьювить только чейнжи, без контекста всего файли или проекта? Ну хорошо когда сам чейнж большой и сам имеет какой то контекст. А если там пару строчек изменено, то что хорошего по этим строчкам может сказать модель без контекста в котором эти изменнния сделаны?
Зависит от того, какие именно строки изменены и в каком месте. Ошибки можно найти даже в небольших изменениях, но без контекста действительно сложно дать осмысленное ревью. Запихнуть весь проект в контекст проблематично, но можно подгружать связанные части кода, чтобы улучшить анализ. В нашем пробном проекте код был небольшим, поэтому весь проект помещался в контекст. В идеале такую задачу должно решать обучение модели на конкретном проекте, чтобы она понимала его структуру и особенности.
Исходя из полученного вами опыта, как посоветовали бы реализовать схожий сценарий, но с такими ограничениями:
я как разработчик, хочу локальной LLM проверять свои коммиты до отправки на ревью т.к. нет возможности получать хуки от гитлаба и допустим фирма не хочется внедрять описанный вами LLM проект, при этом лично я заинтересован в улучшении безопасности своего кода.
Локальное развертывание LLM — это не самое дешевое решение. Помимо стоимости оборудования, необходимо учитывать обслуживание, поддержку и дообучение модели. Если этим занимается не команда, то потребуется хотя бы один специалист или значительное время кого-то из сотрудников, чтобы инструмент работал эффективно.
В России есть компании, предлагающие локальные решения с поддержкой. Я не сторонник изобретать велосипед, поэтому перед покупкой всё тщательно просчитал, чтобы понять, насколько оправдана такая инвестиция. Уверен, что со временем рынок будет развиваться, и появятся как бесплатные, так и коммерческие решения.
Если говорить о проверке коммитов перед отправкой на ревью, но без возможности использовать хуки GitLab и без внедрения LLM на уровне компании, можно реализовать локальную проверку следующим образом:
Развернуть локальную LLM — например, CodeLlama, GPT4All или Llama.cpp.
Настроить pre-commit хук на уровне локального репозитория, который будет запускать LLM для анализа кода.
Обучить модель проверять уязвимости, ошибки и соответствие кодстайлу.
При необходимости добавить автоматические исправления — чтобы LLM могла предлагать исправления, которые можно применять вручную или автоматически.
Дообучать модель, пожалуй, самое интересное. С каждым новым MR модель должна мутировать. Да и промт рекурсивно подстраиваться под изменяющиеся требования. Это лучше пробовать на большом проекте с тысячами MR. К сожалению, на большом проекте данный механизм не исследовал.
Первый шаг к кибернетическому тимлиду: автоматическое ревью кода на основе LLM