Дообучать модель, пожалуй, самое интересное. С каждым новым MR модель должна мутировать. Да и промт рекурсивно подстраиваться под изменяющиеся требования. Это лучше пробовать на большом проекте с тысячами MR. К сожалению, на большом проекте данный механизм не исследовал.
Локальное развертывание LLM — это не самое дешевое решение. Помимо стоимости оборудования, необходимо учитывать обслуживание, поддержку и дообучение модели. Если этим занимается не команда, то потребуется хотя бы один специалист или значительное время кого-то из сотрудников, чтобы инструмент работал эффективно.
В России есть компании, предлагающие локальные решения с поддержкой. Я не сторонник изобретать велосипед, поэтому перед покупкой всё тщательно просчитал, чтобы понять, насколько оправдана такая инвестиция. Уверен, что со временем рынок будет развиваться, и появятся как бесплатные, так и коммерческие решения.
Если говорить о проверке коммитов перед отправкой на ревью, но без возможности использовать хуки GitLab и без внедрения LLM на уровне компании, можно реализовать локальную проверку следующим образом:
Развернуть локальную LLM — например, CodeLlama, GPT4All или Llama.cpp.
Настроить pre-commit хук на уровне локального репозитория, который будет запускать LLM для анализа кода.
Обучить модель проверять уязвимости, ошибки и соответствие кодстайлу.
При необходимости добавить автоматические исправления — чтобы LLM могла предлагать исправления, которые можно применять вручную или автоматически.
Чат нужен не для спора с LLM, а для удобной коммуникации. Он позволит уточнять детали, объяснять причины решений и быстрее находить компромиссы. LLM не заменяет ревьюера, но может ускорить процесс и сделать его более интерактивным. А если нужна критика изменений, можно предусмотреть гибридный вариант — например, в сложных случаях подключать живого ревьюера.
Зависит от того, какие именно строки изменены и в каком месте. Ошибки можно найти даже в небольших изменениях, но без контекста действительно сложно дать осмысленное ревью. Запихнуть весь проект в контекст проблематично, но можно подгружать связанные части кода, чтобы улучшить анализ. В нашем пробном проекте код был небольшим, поэтому весь проект помещался в контекст. В идеале такую задачу должно решать обучение модели на конкретном проекте, чтобы она понимала его структуру и особенности.
Интересные вопросы, раньше не рассматривал их с такой точки зрения.
Идея использования LLM для код-ревью у меня появилась ещё пару лет назад, но основным препятствием была безопасность — из-за невозможности развернуть решение локально многие коллеги были против. Как только появилась техническая возможность, удалось уговорить команду попробовать. И я об этом не жалею.
Тон ревью был выбран скорее формальным, чтобы на первых порах покрыть большинство стандартных требований в проектах. Хотелось, чтобы модель максимально тщательно проверяла код.
Комментарии ИИ — это всего лишь подсказки, которые могут содержать ошибки или ложные срабатывания. Это похоже на работу со статическими анализаторами: их предупреждения и исправления остаются на усмотрение разработчика. ИИ просто помогает находить проблемы, но, в отличие от живого ревьюера, не спорит и не обижается.
Эффективность моделей зависит от их правильного встраивания в процесс, наличия механизмов контроля качества и прозрачных метрик оценки их работы. При хорошей настройке они могут стать инструментом, дополняющим существующие этапы разработки. Соглашусь, что проблем масса их все предстоит решить и от проекта к проекту они будут проявляться по разному.
4 года назад все-таки давненько... сейчас меняется чуть ли каждый месяц модели... у меня опыт со стат анализаторами небольшой есть и они не так быстро эволюционируют... Пока статью писал, появились новые версии доступных моделей не говоря о платных... ИМХО все скатывается в использование нейронок. Статические анализаторы останутся, но их будет меньше... Но посмотрим. Да, и опять же никто не запрещает использовать оба подхода на одном проекте, если все работает локально.
Серьезного сравнения с топовыми статическими анализаторами, такими как SwiftLint или SonarQube, не проводилось. Однако субъективно, они уже уступают анализу с использованием нейронной сети. Даже при грубой настройке удавалось находить больше критических ошибок, при этом ошибки, которые выявляют статические анализаторы, также не оставались незамеченными. Мы проводили проверки на Swift, но до анализа на Java или Go пока не дошли. Тем не менее, возможно, на других языках ситуация обстоит иначе. Спасибо, за интересный вопрос.
Спасибо за интересный вопрос. Что касается SE то это аналог Apple Watch Series 4 (насколько мне известно - очень похожа элементная база хотя могу ошибаться) 7 ая серия стала намного энергоэфективнее. Одно из ограничений это энергоэфективность. Приложение не должно высаживать батарею и существенно сокращать время работы. Не важно чем занимается приложение: коммуникация с переферией, длительный расчет или оставлять не включенным workout. Долгое использование процессора например при пересчете данных акселерометра может привести к удалению из памяти приложения, когда оно например находится в background. Каких то конкретных цифр, к сожалению, привести не могу так как в своих проектах мы просто ставили паузу на расчет, чтобы приложение оставалось рабочим в течении всего времени пока часы были включены. По поводу переферии, то часы, когда уходят в background и гаснут существенно снижают частоту опроса и с учетом того, что это BLE устройство, не значительно просаживают батарею. Что касается разработки переферии то есть определенные требования https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf которым надо следовать.
SwiftUI в любом случае надо учить - за ним будущее на мой субьективный взгляд. Много ограничений снимает (при разработке на часах UI) и его скорее всего будет продвигать Apple как единый способ разработки UI на всех платформах (iOS, watchOS, tvOS). Новые функции (UI) например сейчас только там появляются. Пока что еще полностью от Storyboards не ушли, но вектор развития понятен.
Да, конечно. Размеры, позиции все есть. Единственно UIKit (изначально) не доступен, а так ограничений по сравнению c iOS не нашел. Хотя справедливости ради, пока только несколько экранов перевел. Возможно какой то функционал еще не успел затронуть с которым есть трудности.
Спасибо за ссылки — обязательно попробую. C проектами использующие тайфун не приходилось встречаться, к сожалению. Возможно имеет смысл в таких случаях исполльзовать run-time анализатор.
Дообучать модель, пожалуй, самое интересное. С каждым новым MR модель должна мутировать. Да и промт рекурсивно подстраиваться под изменяющиеся требования. Это лучше пробовать на большом проекте с тысячами MR. К сожалению, на большом проекте данный механизм не исследовал.
Локальное развертывание LLM — это не самое дешевое решение. Помимо стоимости оборудования, необходимо учитывать обслуживание, поддержку и дообучение модели. Если этим занимается не команда, то потребуется хотя бы один специалист или значительное время кого-то из сотрудников, чтобы инструмент работал эффективно.
В России есть компании, предлагающие локальные решения с поддержкой. Я не сторонник изобретать велосипед, поэтому перед покупкой всё тщательно просчитал, чтобы понять, насколько оправдана такая инвестиция. Уверен, что со временем рынок будет развиваться, и появятся как бесплатные, так и коммерческие решения.
Если говорить о проверке коммитов перед отправкой на ревью, но без возможности использовать хуки GitLab и без внедрения LLM на уровне компании, можно реализовать локальную проверку следующим образом:
Развернуть локальную LLM — например, CodeLlama, GPT4All или Llama.cpp.
Настроить pre-commit хук на уровне локального репозитория, который будет запускать LLM для анализа кода.
Обучить модель проверять уязвимости, ошибки и соответствие кодстайлу.
При необходимости добавить автоматические исправления — чтобы LLM могла предлагать исправления, которые можно применять вручную или автоматически.
Чат нужен не для спора с LLM, а для удобной коммуникации. Он позволит уточнять детали, объяснять причины решений и быстрее находить компромиссы. LLM не заменяет ревьюера, но может ускорить процесс и сделать его более интерактивным. А если нужна критика изменений, можно предусмотреть гибридный вариант — например, в сложных случаях подключать живого ревьюера.
Извините, я ж для iOS инструмент проверял а там PVS-Studio не поддерживает Swift. Никого не хотел обидеть.
Зависит от того, какие именно строки изменены и в каком месте. Ошибки можно найти даже в небольших изменениях, но без контекста действительно сложно дать осмысленное ревью. Запихнуть весь проект в контекст проблематично, но можно подгружать связанные части кода, чтобы улучшить анализ. В нашем пробном проекте код был небольшим, поэтому весь проект помещался в контекст. В идеале такую задачу должно решать обучение модели на конкретном проекте, чтобы она понимала его структуру и особенности.
Отличная идея! Возьму на заметку. Чат можно прикрутить.
Интересные вопросы, раньше не рассматривал их с такой точки зрения.
Идея использования LLM для код-ревью у меня появилась ещё пару лет назад, но основным препятствием была безопасность — из-за невозможности развернуть решение локально многие коллеги были против. Как только появилась техническая возможность, удалось уговорить команду попробовать. И я об этом не жалею.
Тон ревью был выбран скорее формальным, чтобы на первых порах покрыть большинство стандартных требований в проектах. Хотелось, чтобы модель максимально тщательно проверяла код.
Комментарии ИИ — это всего лишь подсказки, которые могут содержать ошибки или ложные срабатывания. Это похоже на работу со статическими анализаторами: их предупреждения и исправления остаются на усмотрение разработчика. ИИ просто помогает находить проблемы, но, в отличие от живого ревьюера, не спорит и не обижается.
А какая модель в нейронке используется, если не секрет?
Эффективность моделей зависит от их правильного встраивания в процесс, наличия механизмов контроля качества и прозрачных метрик оценки их работы. При хорошей настройке они могут стать инструментом, дополняющим существующие этапы разработки. Соглашусь, что проблем масса их все предстоит решить и от проекта к проекту они будут проявляться по разному.
4 года назад все-таки давненько... сейчас меняется чуть ли каждый месяц модели... у меня опыт со стат анализаторами небольшой есть и они не так быстро эволюционируют... Пока статью писал, появились новые версии доступных моделей не говоря о платных... ИМХО все скатывается в использование нейронок. Статические анализаторы останутся, но их будет меньше... Но посмотрим. Да, и опять же никто не запрещает использовать оба подхода на одном проекте, если все работает локально.
Интересно. А какие модели использовали?
Серьезного сравнения с топовыми статическими анализаторами, такими как SwiftLint или SonarQube, не проводилось. Однако субъективно, они уже уступают анализу с использованием нейронной сети. Даже при грубой настройке удавалось находить больше критических ошибок, при этом ошибки, которые выявляют статические анализаторы, также не оставались незамеченными. Мы проводили проверки на Swift, но до анализа на Java или Go пока не дошли. Тем не менее, возможно, на других языках ситуация обстоит иначе.
Спасибо, за интересный вопрос.
.
ChatGPT локально не запустишь. Мы ориентировались на модели, которые можно запустить локально. Для сравнения использовалась ChatGPT 4.
Спасибо за интересный вопрос. Что касается SE то это аналог Apple Watch Series 4 (насколько мне известно - очень похожа элементная база хотя могу ошибаться) 7 ая серия стала намного энергоэфективнее. Одно из ограничений это энергоэфективность. Приложение не должно высаживать батарею и существенно сокращать время работы. Не важно чем занимается приложение: коммуникация с переферией, длительный расчет или оставлять не включенным workout. Долгое использование процессора например при пересчете данных акселерометра может привести к удалению из памяти приложения, когда оно например находится в background. Каких то конкретных цифр, к сожалению, привести не могу так как в своих проектах мы просто ставили паузу на расчет, чтобы приложение оставалось рабочим в течении всего времени пока часы были включены. По поводу переферии, то часы, когда уходят в background и гаснут существенно снижают частоту опроса и с учетом того, что это BLE устройство, не значительно просаживают батарею. Что касается разработки переферии то есть определенные требования https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf которым надо следовать.
SwiftUI в любом случае надо учить - за ним будущее на мой субьективный взгляд. Много ограничений снимает (при разработке на часах UI) и его скорее всего будет продвигать Apple как единый способ разработки UI на всех платформах (iOS, watchOS, tvOS). Новые функции (UI) например сейчас только там появляются. Пока что еще полностью от Storyboards не ушли, но вектор развития понятен.
Да, конечно. Размеры, позиции все есть. Единственно UIKit (изначально) не доступен, а так ограничений по сравнению c iOS не нашел. Хотя справедливости ради, пока только несколько экранов перевел. Возможно какой то функционал еще не успел затронуть с которым есть трудности.