Поначалу мы думали использовать только ИИ. Но увидели, что если просто «скармливать» код Llama и Mistral, качественные исправления получаются только в 13% случаев (привет, DevinAI). Вместо того чтобы бесконечно долго дообучать модель, мы решили сперва прогонять код через линтеры и SAST-анализаторы — и только потом делиться результатом с LLM.
Как обычно в общем. Взяли LLM, на реальной задаче она оказалась бесполезна. Поэтому взяли старые проверенные решения, и пропускаем их отчёты через LLM. Теперь вместо скучного линтера получился ИИ помощник, модно-молодежно. Ждём историю успеха о том как языковая модель зажевала какой-то важный выхлоп из линтера и её пришлось убрать, и вернуться к скучным не-ИИ отчётам.
В среднем ALT-man в десять раз быстрее, чем человек. Так, на проверку и заведение детализированных задач на исправление для пяти пулл-реквестов (в каждом десять файлов кода) опытный тимлид тратит 2 часа, а наше решение справляется за 10–15 минут.
Вы просто выкинули ревьювера из процесса. Линтинг или анализ это не замена ревью. Ревьювер может например посмотреть в ПР и в задачу, и понять, что код, пускай и идеально правильный, просто делает не то что просили в задаче. Ваша языковая модель так может?
Здравствуйте. Хорошие замечания, сейчас постараюсь ответить развернуто
Ждём историю успеха о том как языковая модель зажевала какой-то важный выхлоп из линтера и её пришлось убрать, и вернуться к скучным не-ИИ отчётам.
Логика системы построена так, что никто и ничего не "зажует". Все ошибки и дефекты не остаются незамеченными. К тому же ни один линтер не проверит корректность реализации принятых архитектурных подходов.
Вы просто выкинули ревьювера из процесса. Линтинг или анализ это не замена ревью. Ревьювер может например посмотреть в ПР и в задачу, и понять, что код, пускай и идеально правильный, просто делает не то что просили в задаче. Ваша языковая модель так может?
Проверка корректности реализации бизнес-логики не всегда является частью код-ревью. Для этого существует такая штука как E2E автотесты. Но не суть. В любом случае, проверку реализации бизнес-логики мы не игнорируем. Основная техническая сложность, которую мы практически решили - это репрезентация того, что у нас содержит СПТ (логика, макеты, api) в формат, который будет удобен для дальнейшего процессинга LLM-кой. Как только мы интегрируемся с нашими системами хранения СПТ, модуль анализа реализации логики будет включен в состав нашего ревьювера.
Поначалу мы думали использовать только ИИ. Но увидели, что если просто «скармливать» код Llama и Mistral, качественные исправления получаются только в 13% случаев (привет, DevinAI). Вместо того чтобы бесконечно долго дообучать модель, мы решили сперва прогонять код через линтеры и SAST-анализаторы — и только потом делиться результатом с LLM.
Как обычно в общем. Взяли LLM, на реальной задаче она оказалась бесполезна. Поэтому взяли старые проверенные решения, и пропускаем их отчёты через LLM. Теперь вместо скучного линтера получился ИИ помощник, модно-молодежно. Ждём историю успеха о том как языковая модель зажевала какой-то важный выхлоп из линтера и её пришлось убрать, и вернуться к скучным не-ИИ отчётам.
В среднем ALT-man в десять раз быстрее, чем человек. Так, на проверку и заведение детализированных задач на исправление для пяти пулл-реквестов (в каждом десять файлов кода) опытный тимлид тратит 2 часа, а наше решение справляется за 10–15 минут.
Вы просто выкинули ревьювера из процесса. Линтинг или анализ это не замена ревью. Ревьювер может например посмотреть в ПР и в задачу, и понять, что код, пускай и идеально правильный, просто делает не то что просили в задаче. Ваша языковая модель так может?
Здравствуйте. Хорошие замечания, сейчас постараюсь ответить развернуто
Ждём историю успеха о том как языковая модель зажевала какой-то важный выхлоп из линтера и её пришлось убрать, и вернуться к скучным не-ИИ отчётам.
Логика системы построена так, что никто и ничего не "зажует". Все ошибки и дефекты не остаются незамеченными. К тому же ни один линтер не проверит корректность реализации принятых архитектурных подходов.
Вы просто выкинули ревьювера из процесса. Линтинг или анализ это не замена ревью. Ревьювер может например посмотреть в ПР и в задачу, и понять, что код, пускай и идеально правильный, просто делает не то что просили в задаче. Ваша языковая модель так может?
Проверка корректности реализации бизнес-логики не всегда является частью код-ревью. Для этого существует такая штука как E2E автотесты. Но не суть. В любом случае, проверку реализации бизнес-логики мы не игнорируем. Основная техническая сложность, которую мы практически решили - это репрезентация того, что у нас содержит СПТ (логика, макеты, api) в формат, который будет удобен для дальнейшего процессинга LLM-кой. Как только мы интегрируемся с нашими системами хранения СПТ, модуль анализа реализации логики будет включен в состав нашего ревьювера.