Егор Урванов

Короткий цикл обратной связиОт кнопки «Сообщить о баге» до исправления с ИИ-агентом

Как сократить путь бага до исправления: кнопка в приложении, автоконтекст, ИИ-агент ищет причину, человек одобряет. Исследования, кейсы Wix и Abnormal.

создано · обновлено · 7 мин · · Харнесс

Короткий цикл обратной связи работает так: сотрудник отправляет баг кнопкой прямо из приложения, приложение само прикладывает технический контекст, ИИ-агент ищет причину и предлагает план, а человек одобряет план и исправление. Баг не проходит через пересказы менеджера и тикета. Ниже: где теряется время, что собирает кнопка, два режима работы и риски.

Где теряется время

Путь бага от того, кто его увидел, до того, кто его исправит, обычно длинный. Верхняя цепочка показывает обычный путь: сотрудник, менеджер, тикет, уточнения, воспроизведение. Нижняя показывает короткий цикл: кнопка в приложении, репорт с контекстом, агент, одобрение человека, выкатка. Полосы ниже показывают, как часто репорты неполные: 92% багов в Android без шагов воспроизведения, около 70% неполных репортов в GitHub, и лишь 37–44% багов передаются дальше.

Обычный путь
Короткий цикл
Доля багов и репортов
Без шагов (Android)92%
Неполные (GitHub)~70%
Переданы дальше37–44%
Вывод
В этом примереИз каждого пересказа выпадает то, что разработчику нужнее всего: шаги, ожидание, состояние экрана.
В общем случаеРазработчикам важнее всего шаги воспроизведения и стек ошибки, а пользователям труднее всего дать именно их. Неполный репорт воспроизводят 201 минуту против 120.
Что сделатьПосчитайте, сколько рук проходит баг от того, кто его увидел, до того, кто исправит.

Кнопка вместо пересказа

Человек отдаёт только то, чего машина знать не может: что он хотел и что увидел. Остальное приложение записывает само.

Скриншот с рамкойЧеловек обводит место, рамки вжигаются в картинку
Три вопросаЧто делали, что ждали, что вышло; первый заполняется по последним кликам
ГолосНаговорил — расшифровка дописалась в нужный шаг
ДействияКлики, переходы, ввод без значений
Запросы и ошибкиПоследние запросы к серверу с ответами, ошибки консоли, состояние сервера
Личные данные скрытыИмена, контакты и переписка в тексте маскируются, ключи вырезаются
Вывод
В этом примереОписание занимает секунды: варианты ответов выбираются одним нажатием.
В общем случаеРепорт пишется для агента, который прочитает любой объём технических деталей, поэтому их собирают все и сразу.
Что сделатьПоставьте кнопку туда, где люди видят проблему, а не в отдельный трекер.

Агент и человек

Агент делает разбор, человек принимает решения. Агент берёт каждый репорт отдельно, исследует его и приносит отчёт: что видно, вероятная причина с местом в коде, план и риски. Код и статусы он при этом не меняет. Человек одобряет план. Дальше агент делает исправление в отдельной ветке, а человек сливает изменение и выкатывает его. Фраза в рамке — готовая просьба к агенту.

  1. 1
    Агент берёт репорт
    каждый репорт — отдельным агентом, без общих догадок
  2. 2
    Исследует и отчитывается
    что видно, вероятная причина с местом в коде, план, риски, вопросы; код и статусы не трогает
  3. 3
    Человек одобряет план
    или задаёт вопросы
  4. 4
    Исправление
    ветка, проверки, запрос на слияние
  5. 5
    Человек сливает и выкатывает
    агент повторяет сценарий репорта до конца, прежде чем сказать «исправлено»

Скажите агенту

Возьми открытые баг-репорты, разбери каждый отдельным агентом и вернись со сводным отчётом. Ничего не меняй до моего одобрения.
Вывод
В этом примереПравила работы трекер отдаёт агенту сам при подключении, поэтому любая сессия ведёт себя одинаково.
В общем случаеСкорость дают агенты, решения остаются у человека в двух точках: план и слияние.
Что сделатьЗапишите порядок «исследуй → отчёт → жди одобрения» туда, откуда агент его прочитает без вас.

Два режима: по кнопке или автоматически

Режимов два. По кнопке разработчик запускает агента одной командой, агент находит причину и план, человек одобряет. Автоматически система запускает агента на каждый репорт, и он сразу пишет исправление. Таблица сравнивает режимы по скорости и цене.

По кнопкеАвтоматически
Кто запускаетразработчик одной командойсистема, как только пришёл репорт
Что делает агентнаходит причину и плансразу пишет исправление
Роль разработчикаодобряет план, проверяет правкупроверяет готовую правку
Скоростьминуты до отчётаправка готова к приходу человека
Ценаагент работает только по нужным репортамагент тратится на каждый репорт, включая дубли и не-баги
Вывод
В этом примереAbnormal AI делает оба режима метками на задаче: первая — агент ищет причину, вторая — пишет исправление.
В общем случаеНачинать дешевле с режима по кнопке: разработчик отсекает шум раньше, чем агент начнёт писать код.
Что сделатьВключайте автоматический режим, когда поток репортов чистый и дублей мало.

Кейсы и цифры

Цифры из практики компаний показывают масштаб эффекта: у Wix время сократилось с недель до часов, у Ramp с Jam репорт стал занимать секунды вместо 15–20 минут. Строка под таблицей относится к примеру автора: из 25 репортов во встроенном трекере закрыты 23.

КтоЧто сделалиБыло → стало
Wixагенты собирают контекст, пишут и проверяют исправление, человек одобряетнедели → часы
Salesforceмодель разбирает баги клиентов~300 человеко-дней → меньше недели
Metaviewагент разбирает инциденты, человек проверяет30–45 мин → ~5 мин
LaunchDarklyагенты находят баги и открывают исправления~40% уникальных багов дошли до правки
Ramp + Jamрепорт со скриншотом и автосбором контекста15–20 мин → секунды на репорт
23 из 25репортов закрыты во встроенном трекере рабочего приложения
Вывод
В этом примереУ всех кейсов общий ход: контекст собирается до того, как за баг сядет человек.
В общем случаеСокращение времени до исправления (MTTR в метриках DORA) идёт от сбора контекста и короткой цепочки людей.
Что сделатьЗамерьте время от репорта до выкатки сейчас, чтобы было с чем сравнить.

Риски

Агент читает текст, который пишут люди, поэтому у метода свои риски: поддельные репорты, личные данные на скриншотах, зелёные тесты при нерабочей функции и размытая ответственность. Четыре карточки ниже называют риск и способ его снять.

Поддельный репортТекст репорта пишут люди, агент читает его как данные, а не как команды
Личные данныеТекст маскируется, скриншот уходит как есть — об этом предупреждает окно
Зелёные тесты, нерабочая функцияПроверка — повтор точного сценария репорта на том же виде данных
Размытая ответственностьОдобрение плана и слияние делает человек, молчание не считается согласием
Вывод
В этом примереАгент с правом записи и доступом к тексту от пользователей — канал для обмана через текст.
В общем случаеПодробнее о том, как не дать данным стать командами, — в статье про data plane и control plane.
Что сделатьВыдайте агенту отдельный ключ: на чтение для разбора, на запись только после одобрения.

С чего начать

Начните с измерения: сначала замерьте путь бага, потом поставьте кнопку, потом дайте агенту доступ на чтение и правило «сначала отчёт, потом одобрение». Доступ на запись и автоматический режим добавляйте позже.

  1. 1
    Замерьте путь бага
    сколько людей и дней от «увидел» до «исправлено»
  2. 2
    Поставьте кнопку
    скриншот, три вопроса, автосбор действий и ошибок
  3. 3
    Дайте агенту доступ на чтение
    и правило: сначала отчёт, потом одобрение
Вывод
В этом примереТри шага без автоматического режима и без доступа на запись.
В общем случаеСначала короткая цепочка людей, потом скорость агента.
Что сделатьНачните с одного приложения и десяти репортов.
Цифры — из исследований баг-репортов (Zimmermann et al.; arxiv 2203.12093, 2301.01235; Jeong et al.) и инженерных блогов Wix, Salesforce, Metaview, LaunchDarkly, Abnormal AI, Jam. Пример — встроенный баг-трекер рабочего приложения, октябрь 2026.

С теми же терминами

© 2026 Егор Урванов