не плохо работает определение риска регресса и blast radius + то, насколько агент может написать внятные тесты на всю эту историю - буду в 3 оси вкладываться
{
"points": 0.5,
"fixPlan": {
"risks": "Минимальный риск: изменится label во всех местах, где рендерится `LaunchPermissonField` для `launch:close`, включая создание и редактирование проектной роли. Это ожидаемое поведение.",
"approach": "Заменить i18n-маппинг для `LAUNCH_PERMISSIONS.CLOSE` на `t($ => $[\"close-launches\"])`, не меняя enum, API-контракт и локали.",
"rootCause": "`LaunchPermissionField.tsx` для права `launch:close` использует устаревший i18n-ключ `complete-launches`, из-за чего показывается текст «Завершать запуски» вместо актуального `close-launches` / «Закрывать запуски».",
"testStrategy": "Проверить targeted frontend test/snapshot для формы проектной роли либо вручную открыть модальное окно создания роли и убедиться, что для `launch:close` отображается «Закрывать запуски». При наличии formatter gate запустить релевантный lint/spotless для frontend-файла.",
"affectedAreas": "`src/main/javascript/features/project-roles/ui/role-form/LaunchPermissionField.tsx`; frontend/i18n отображение проектных ролей."
},
"rationale": "Тривиальный frontend-text баг: один слой, root cause однозначен, правка локальная в одном маппинге i18n-ключа для `LAUNCH_PERMISSIONS.CLOSE` с `complete-launches` на уже существующий `close-launches`. Контракт, backend, данные и верстка не меняются. Тест либо не нужен, либо тривиальный snapshot/unit на отображение label. Нет сигнала крупности для 1+ кроме того, что компонент переиспользуется, но сам фикс общий и минимальный.",
"threshold": 2,
"awaitingApproval": false
}
В сам механизм оценки мы пока глубоко не вкладывались, поэтому он ещё требует калибровки: иногда агент относит достаточно простые задачи к тем, для которых необходимо подтверждение разработчика. Но сама идея оказалась полезной — выражать уровень доверия разработчиков к агенту через порог в стори-поинтах. Это позволяет не только постепенно расширять границы автономности агента, но и точнее считать его экономику с учётом сложности задач, которые он способен решать без вмешательства человека
Спасибо за вопрос. Сейчас первичную валидность бага определяет не агент. Перед попаданием в очередь агента задачу проверяет QA-инженер: действительно ли это дефект и достаточно ли в описании исходных данных.
После этого агент читает репорт и отдельно формирует критерии приёмки: какое поведение должно измениться и что фикс не должен сломать. Если ожидаемый результат нельзя однозначно вывести из описания, агент не додумывает его, а останавливает прогон и возвращает задачу QA на уточнение. После исправления запускаются проверки и независимая валидация патча, а созданный MR по-прежнему проходит человеческое ревью разработчика.
При этом у текущего процесса есть ограничение: основной bugfix-пайплайн пока не воспроизводит исходный баг на живом стенде. Браузерное воспроизведение со скриншотами и видео у нас уже реализовано как отдельный процесс; следующий шаг — встроить его в цепочку «воспроизведение → исправление → повторная проверка».
Тестируем всё на собственном продукте ТестОпс, у которого бэкенд и фронтенд находятся в одном репозитории. В статье приведены результаты прогонов на реальных продуктовых багах.
Если под локальным запуском имеется в виду именно LLM, то полноценного сравнительного эксперимента с локальными моделями мы не проводили. Сейчас используем внешнюю фронтирную модель: при нашем объёме один смёрженный фикс обходится до $3 и есть большой потенциал для оптимизации. Развёртывание локальной модели потребовало бы не только GPU, но и обслуживания, мониторинга и отдельной проверки качества на наших багах. Пока экономика такого перехода для нас выглядит сомнительной
не плохо работает определение риска регресса и blast radius + то, насколько агент может написать внятные тесты на всю эту историю - буду в 3 оси вкладываться
ЛЛМ выводит оценку, в таком виде:
В сам механизм оценки мы пока глубоко не вкладывались, поэтому он ещё требует калибровки: иногда агент относит достаточно простые задачи к тем, для которых необходимо подтверждение разработчика. Но сама идея оказалась полезной — выражать уровень доверия разработчиков к агенту через порог в стори-поинтах. Это позволяет не только постепенно расширять границы автономности агента, но и точнее считать его экономику с учётом сложности задач, которые он способен решать без вмешательства человека
DIAGNOSE — примерно $0.69.
IMPLEMENT — примерно $0.66.
BRT — примерно $0.25.
SELF_REVIEW — примерно $0.11.
JUDGE — примерно $0.06.
VALIDATE — примерно $0.06.
ACCEPTANCE — примерно $0.02.
ESTIMATE — примерно $0.01.
PREPARE, QUALITY, PUBLISH, TRANSITION — $0, поскольку LLM не вызывают.
Медианная стоимость — $1.85.
Но стоимость фикса, который уже попадает в релиз дороже, доллара 3, из-за того, что есть не успешные фиксы и доработки в рамках мра
input — $1.25 / output - 10$
После стабилизации самого процесса, цель довести до 1$ за фикс
Спасибо за вопрос. Сейчас первичную валидность бага определяет не агент. Перед попаданием в очередь агента задачу проверяет QA-инженер: действительно ли это дефект и достаточно ли в описании исходных данных.
После этого агент читает репорт и отдельно формирует критерии приёмки: какое поведение должно измениться и что фикс не должен сломать. Если ожидаемый результат нельзя однозначно вывести из описания, агент не додумывает его, а останавливает прогон и возвращает задачу QA на уточнение. После исправления запускаются проверки и независимая валидация патча, а созданный MR по-прежнему проходит человеческое ревью разработчика.
При этом у текущего процесса есть ограничение: основной bugfix-пайплайн пока не воспроизводит исходный баг на живом стенде. Браузерное воспроизведение со скриншотами и видео у нас уже реализовано как отдельный процесс; следующий шаг — встроить его в цепочку «воспроизведение → исправление → повторная проверка».
Тестируем всё на собственном продукте ТестОпс, у которого бэкенд и фронтенд находятся в одном репозитории. В статье приведены результаты прогонов на реальных продуктовых багах.
Если под локальным запуском имеется в виду именно LLM, то полноценного сравнительного эксперимента с локальными моделями мы не проводили. Сейчас используем внешнюю фронтирную модель: при нашем объёме один смёрженный фикс обходится до $3 и есть большой потенциал для оптимизации. Развёртывание локальной модели потребовало бы не только GPU, но и обслуживания, мониторинга и отдельной проверки качества на наших багах. Пока экономика такого перехода для нас выглядит сомнительной