Однострочный промпт в пятницу вечером обошёлся разработчику девяноста минутами разбора в воскресенье и отдельной задачей на полный ре-индекс. Задача казалась тривиальной: убрать заархивированные закладки из поискового индекса. Агент добросовестно почистил записи с флагом is_deleted — и не тронул два других пути архивации, о которых постановщик знал, но не зафиксировал в задаче.
Эта история стала отправной точкой для описания методологии SENAR. Её авторы — разработчик, ведущий серию статей, и соавтор Вадим Соглаев — собрали её по итогам практики на тридцати с лишним проектах за полтора года. Готового стандарта для работы с ИИ-агентами в разработке на рынке не нашлось, поэтому закономерности, которые повторялись от проекта к проекту, начали оседать в одном месте. SENAR — аббревиатура от Supervised Engineering & Normative AI Regulation — это и есть то самое место, доведённое до состояния воспроизводимого процесса. Методология открытая, лицензия CC BY-SA 4.0, тексты опубликованы на senar.tech.
| Метрика | Расшифровка | Что измеряет |
|---|---|---|
| FPSR | First Pass Success Rate | Доля задач, решённых с первой попытки без возврата |
| MIR | Manual Intervention Rate | Доля задач, потребовавших ручной правки после агента |
| DER | Dead End Rate | Доля тупиковых попыток / времени на тупики |
| ERR | Exit Return Rate (служебная) | Дефекты, обнаруженные после закрытия задачи в продакшне |
Главная идея SENAR строится на наблюдении, которое авторы сформулировали ещё в предыдущих статьях серии: ИИ-агент принципиально отличается от программиста-человека. Он не удерживает контекст между запусками, склонен к локальной оптимизации, добросовестно исполняет буквальную постановку и не задаёт уточняющих вопросов там, где человек задал бы их автоматически. Личная дисциплина постановщика — держать в голове все нюансы задачи — не масштабируется: к тридцать первой задаче за неделю она начинает проседать. Методология предлагает заменить её внешней, технически встроенной в процесс.
Шлюз QG-0 блокирует передачу задачи агенту, пока не оформлена спецификация с целью, критериями приёмки и негативными сценариями.
Контур одной задачи в SENAR замыкают два шлюза качества. QG-0 стоит на входе: агент не получает задачу в работу, пока в ней не оформлена спецификация. Минимальный состав спецификации — цель в продуктовой логике (со стороны пользователя, а не реализации), критерии приёмки и негативные сценарии. Формулировка «дать пользователю возможность сменить отображаемое имя» считается корректной целью; «добавить поле в таблицу users» — нет, потому что описывает реализацию, и агент будет оптимизировать именно её. QG-2 стоит на выходе: задача не переходит в статус закрытой, пока результат не сверён с критериями, зафиксированными на входе, и пока не зарегистрированы все ручные правки, внесённые после агента. В полном стандарте SENAR шлюзов пять — QG-0 через QG-4, — но два крайних замыкают контур одной задачи и разбираются в этой части серии.
Авторы проводят чёткую границу между шлюзами и привычными инструментами контроля качества. Тесты ловят функциональные расхождения с ожидаемым поведением, линтеры — отклонения от стиля кода, статический анализ — подозрительные конструкции, ревью — всё, что не поймали предыдущие инструменты. Ворота задачи проверяют другое: постановку до того, как код появился, и приёмку после того, как он произведён. Аналогия из производства: тесты и линтеры — это контроль готовых деталей на конвейере, ворота — допуск чертежа на конвейер и приёмка партии после него. Агент опаснее конвейера именно тем, что умеет что-то сделать даже из плохого чертежа.
Техническую реализацию шлюзов берёт на себя фреймворк TAUSIK, который реализует SENAR на практике. До прохождения QG-0 агенту физически не отдают задачу; после прохождения QG-2 задача автоматически переходит в статус закрытой и уходит в журнал. Пропустить шаг можно, только переписав сам инструмент — это и есть защита от пятничной усталости, ради которой ворота появились.
Метрическая часть SENAR включает три основных показателя. FPSR — доля задач, решённых с первой попытки без возврата. MIR — доля задач, в которых после агента потребовалась ручная правка. DER (Dead End Rate) — доля тупиковых попыток или времени, потраченного на тупики. Дополнительно авторы ведут служебную метрику ERR — возвраты после закрытия задачи, то есть дефекты, ушедшие в продакшн. Метрики работают как сигналы: если FPSR падает, значит спецификации на входе недостаточно структурированы; если MIR растёт — агент систематически не справляется с каким-то классом задач без вмешательства человека.
