SENAR introduce portais de qualidade para desenvolvimento de IA: como especificações e métricas reduzem erros

На Habr вышла четвёртая статья цикла о SENAR — открытой методологии для разработки с AI-агентами. Андрей Юмашев описывает, как формальные входные и выходные «ворота» должны заменить личную дисциплину постановщика и сократить число ошибок, которые всплывают уже после закрытия задачи.

Как устроен SENAR SENAR автор называет инженерной методологией для

работы с AI-агентами в разработке. Она выросла не из теории, а из практики: по словам Юмашева, за полтора года через такой режим прошли более тридцати проектов, где код всё чаще писал агент, а человек занимался постановкой, приёмкой и разбором сбоев. Основная мысль статьи простая: агент не держит контекст между запусками, буквально следует формулировке и легко оптимизирует локально, если задача описана небрежно.

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

Именно это, по мысли автора, и защищает команду от «пятничной» усталости, когда самые мелкие задачи чаще всего и пролезают в прод с дефектом.

Что проверяют ворота На входе SENAR использует шлюз QG-0.

Он не пускает задачу в работу, пока в ней нет минимальной спецификации: цели, критериев приёмки, негативных сценариев, границ изменений и ссылки на архитектурный контекст. Юмашев отдельно спорит с популярной установкой, что мелкие задачи можно отдавать агенту «в одну строку». Именно такие задачи, по его наблюдению, чаще других ломаются в проде, потому что постановщик держит важные детали в голове, но не фиксирует их в карточке.

«Шаг пропустил не агент, а я».

На выходе работает QG-2 — шлюз, который блокирует закрытие задачи, пока результат не сверен с обещаниями на входе. В статье автор выделяет три обязательные проверки: подтверждение каждого критерия приёмки тестом, ручной проверкой или артефактом; фиксацию всех ручных правок после работы агента; обновление памяти проекта, если задача вскрыла новый пограничный случай или инфраструктурную особенность. Такой режим нужен не ради бюрократии, а чтобы агент в следующей задаче не повторял те же ошибки из-за молча внесённых человеком исправлений.

Метрики и пределы

Отдельный блок статьи посвящён метрикам, которые SENAR использует как сигналы состояния процесса. FPSR показывает долю задач, решённых с первой попытки; MIR — как часто после агента потребовалась ручная правка; DER измеряет тупиковые ветки и потери времени; ERR отражает задачи, которые пришлось чинить уже после закрытия. По рабочему журналу автора, на серверных задачах в знакомом домене FPSR вырос примерно с 40% до 75–80%, MIR на проекте Sortule снизился с 20% до 5–7%, а ERR опустился примерно с 15% до 6%.

При этом Юмашев честно описывает и пределы методологии. Ворота плохо помогают там, где результат трудно формализовать: в задачах на «ощущение» интерфейса, тон текста или продуктовую интуицию. Не спасают они и при работе с внешними сервисами, если чужая документация противоречит реальному поведению API.

В таких случаях формальный процесс может удержать структуру задачи, но не заменяет знание домена, ручную проверку гипотез и предварительное исследование интеграции.

Что это значит SENAR оформляется не как набор советов, а как жёсткий

операционный контур для AI-разработки: без нормальной спеки агент не стартует, без подтверждённой приёмки задача не закрывается. Для команд, которые уже отдают часть кода агентам, это сильный сигнал: главный риск теперь не только в модели, но и в качестве постановки, памяти проекта и дисциплине процесса.