Спасибо за вопрос. Сейчас первичную валидность бага определяет не агент. Перед попаданием в очередь агента задачу проверяет QA-инженер: действительно ли это дефект и достаточно ли в описании исходных данных.
После этого агент читает репорт и отдельно формирует критерии приёмки: какое поведение должно измениться и что фикс не должен сломать. Если ожидаемый результат нельзя однозначно вывести из описания, агент не додумывает его, а останавливает прогон и возвращает задачу QA на уточнение. После исправления запускаются проверки и независимая валидация патча, а созданный MR по-прежнему проходит человеческое ревью разработчика.
При этом у текущего процесса есть ограничение: основной bugfix-пайплайн пока не воспроизводит исходный баг на живом стенде. Браузерное воспроизведение со скриншотами и видео у нас уже реализовано как отдельный процесс; следующий шаг — встроить его в цепочку «воспроизведение → исправление → повторная проверка».
Тестируем всё на собственном продукте ТестОпс, у которого бэкенд и фронтенд находятся в одном репозитории. В статье приведены результаты прогонов на реальных продуктовых багах.
Если под локальным запуском имеется в виду именно LLM, то полноценного сравнительного эксперимента с локальными моделями мы не проводили. Сейчас используем внешнюю фронтирную модель: при нашем объёме один смёрженный фикс обходится до $3 и есть большой потенциал для оптимизации. Развёртывание локальной модели потребовало бы не только GPU, но и обслуживания, мониторинга и отдельной проверки качества на наших багах. Пока экономика такого перехода для нас выглядит сомнительной
Спасибо за вопрос. Сейчас первичную валидность бага определяет не агент. Перед попаданием в очередь агента задачу проверяет QA-инженер: действительно ли это дефект и достаточно ли в описании исходных данных.
После этого агент читает репорт и отдельно формирует критерии приёмки: какое поведение должно измениться и что фикс не должен сломать. Если ожидаемый результат нельзя однозначно вывести из описания, агент не додумывает его, а останавливает прогон и возвращает задачу QA на уточнение. После исправления запускаются проверки и независимая валидация патча, а созданный MR по-прежнему проходит человеческое ревью разработчика.
При этом у текущего процесса есть ограничение: основной bugfix-пайплайн пока не воспроизводит исходный баг на живом стенде. Браузерное воспроизведение со скриншотами и видео у нас уже реализовано как отдельный процесс; следующий шаг — встроить его в цепочку «воспроизведение → исправление → повторная проверка».
Тестируем всё на собственном продукте ТестОпс, у которого бэкенд и фронтенд находятся в одном репозитории. В статье приведены результаты прогонов на реальных продуктовых багах.
Если под локальным запуском имеется в виду именно LLM, то полноценного сравнительного эксперимента с локальными моделями мы не проводили. Сейчас используем внешнюю фронтирную модель: при нашем объёме один смёрженный фикс обходится до $3 и есть большой потенциал для оптимизации. Развёртывание локальной модели потребовало бы не только GPU, но и обслуживания, мониторинга и отдельной проверки качества на наших багах. Пока экономика такого перехода для нас выглядит сомнительной