Поздний вечер пятницы. В третью декаду недели — задача 31. В очереди мелочь: убрать заархивированные закладки из поискового индекса. Хочется спать уже через час.
Дисциплина не масштабируется
Пишу однострочный промпт. Спецификация? На такую задачу — ни к чему, тут одно действие. Агент берёт флаг is_deleted, чистит индекс, прогоняет тесты. Всё зелёное. Задача закрыта.
Через два дня пользователь жалуется: ищет старую статью, а рядом с ней — десятки заархивированных записей, которых там быть не должно.
Разбираюсь — и упираюсь. В системе у «удалённой» закладки три состояния: пользователь удалил её сам — ставится is_deleted; политика хранения заархивировала через год — archived_at; модерация скрыла — hidden_by_mod. Каждое состояние проставляет своё поле, потому что они появились в разное время и решали разные задачи. Я об этом знал. Но в пятничную задачу не положил.
Агент выполнил ровно то, что было в задаче: убрал записи с is_deleted. Два других пути остались в индексе. Девяносто минут разбора в воскресенье плюс отдельная задача на полный ре-индекс.
Шаг пропустил не агент. Я.
Ранее я перечислял пять навыков нового рабочего режима: декомпозиция, контекст, архитектурные границы, критерии приёмки, диагностика сбоев. На бумаге — цельно. На практике — к пятнице вечером эти навыки проседают первыми.
Это не недостаток дисциплины. Это её естественный потолок. Любая система, построенная на том, что один человек тридцать раз в неделю не пропустит шаг, рано или поздно сталкивается со своей пятницей.
После нескольких таких пятниц пришёл к простому выводу: личная дисциплина не масштабируется. Нужна внешняя — технически встроенная в момент входа и выхода задачи.
Что такое SENAR
SENAR (от Supervised Engineering & Normative AI Regulation) — открытая методология инженерной работы с ИИ-агентами. Лицензия CC BY-SA 4.0, полные тексты — на senar.tech. Соавтор — Вадим Соглаев.
Готовой методологии под 100% ИИ-разработки не нашлось, поэтому мы собрали её по итогам практики. За полтора года, через тридцать с лишним проектов, выявилась закономерность: проблемы и решения повторяются. SENAR — это «одно место», где они систематизированы и могут работать не только для авторов.
Из чего состоит методология:
- Восемь правил. Принципы работы с агентом: формализация задачи, явные границы изменений, обязательные негативные сценарии, ручная правка как сигнал и другие. Это «что должно быть», а не «как реализовать».
- Два шлюза качества задачи. QG-0 — на входе: задача не берётся в работу без спецификации. QG-2 — на выходе: задача не закрывается, пока результат не сверен с критериями, а ручные правки не зарегистрированы. В полном стандарте шлюзов пять (QG-0..QG-4), но здесь фокус — на двух, замыкающих контур одной задачи.
- Типизированная память проекта. Решения, тупики, исключения, договорённости и контекст хранятся отдельными записями. Подаются в задачу по релевантности.
- Метрики. FPSR (доля задач, решённых с первой попытки), MIR (доля задач с ручной правкой), DER (доля тупиковых попыток). Дополнительно веду ERR — возвраты после закрытия задач, чтобы видеть дефекты в проде. Метрики работают как сигналы: показывают, где контур провисает.
Форма методологии не из соображений «так положено». Она вытекает из природы агента: он не удерживает контекст между запусками, склонен к локальной оптимизации, исполняет буквально, не задаёт вопросов. Если процесс это не учитывает, он ломается при первой же сложной задаче. SENAR — это процесс, построенный с учётом этих свойств.
Эта статья — о контуре одной задачи: ворота на входе и выходе, плюс метрики. Следующая — о среде между воротами: контекст, границы, память. Шестая — о границах применимости и открытых вопросах.
Что закрывают ворота задачи
Тесты ловят расхождения с поведением. Линтеры — отклонения от стиля. Статический анализ — подозрительные конструкции. Ревью — то, что ускользнуло выше. Эти проверки встроены в практику — в SENAR они сохраняются.
Ворота задачи закрывают другое. На входе — не пускают агента без минимальной структуры: цели, критериев, негативных сценариев, границ. На выходе — не пускают закрыть задачу, пока результат не сверен с тем, что было обещано на входе. То есть тесты и линтеры проверяют код. Ворота — постановку и приёмку, где код ещё не появился или уже произведён.
Аналогия: тесты — контроль готовых деталей на конвейере. Ворота — допуск чертежа на конвейер и приёмка партии после него. Без чертежа конвейер простаивает. Без приёмки — партия уезжает без подтверждения качества.
В TAUSIK — фреймворке, реализующем SENAR — ворота встроены технически. До QG-0 агенту не отдают задачу. После QG-2 задача физически закрывается. Пропустить шаг можно, только переписав инструмент. Это защита от пятничной усталости.
QG-0: вход. Что должно быть в спеке
Два навыка из предыдущей статьи — декомпозиция и критерии приёмки — должны быть зафиксированы в задаче. Из головы они не переходят. QG-0 — это точка, где они становятся обязательными.
Минимальная спецификация:
- Цель. Одно предложение в продуктовой логике. Хорошо: «дать пользователю возможность сменить отображаемое имя». Плохо: «добавить поле в таблицу
users» — это уже реализация. - Критерии приёмки. Перечисление, по чему подтвердится, что задача решена. Минимум один, обычно три-пять. Каждый — проверяемый, с однозначным исходом.
- Негативные сценарии. Что должно произойти при неправильном вводе, пограничном случае, отсутствующих данных. Минимум один — правило без исключений.
- Границы изменений. Какие файлы, модули, сервисы можно трогать, а какие — нельзя. Не обязательно жёсткий список; достаточно области ответственности.
- Ссылка на архитектурный контекст. Какие границы и инварианты задача пересекает и где они описаны.
Меньше нельзя. Без любого пункта агент начинает достраивать смысл. Без цели — оптимизирует локально. Без критериев — закроет по своей логике. Без негативных сценариев — напишет позитивный путь и остановится. Без границ — полезет наводить порядок, где не просили.
Больше — бюрократия. Пять-семь пунктов на типовую задачу, десять-двенадцать на сложную. Если спека занимает страницу — задачу надо резать.
QG-0 проверяет структурную полноту: есть ли все секции, не пустые ли. Качественные требования (независимая проверяемость, обязательный негатив) добавляются в зрелых конфигурациях. Содержательную правильность по-прежнему держит человек. Ворота не отменяют его роль — они снимают обязанность помнить всё в одиннадцать вечера.
Сначала казалось, что и на мелкую задачу пять секций — перебор. Через месяц стало ясно: больше всего дефектов в прод приносят мелкие задачи — там чаще срывается дисциплина. Пример с заархивированными закладками был как раз такой.
Критерии приёмки и негативные сценарии
С агентом «работает» — пустая строка. Он закроет задачу после первого позитивного сценария. Поэтому SENAR требует переводить «работает» в проверяемое.
Вместо «корректно сохранять закладку» — конкретика: при сохранении с существующим адресом возвращается ошибка 409, с пустым телом — 400, при превышении размера превью — режется до 8 КБ, при ошибке внешнего сервиса — сохраняется минимальная запись с пометкой enrichment_pending. Каждый пункт проверяем.
Негативные сценарии — это критерии про то, чего не должно произойти. Они выделены отдельной секцией, потому что чаще всего пропускаются. Человек думает в позитивной логике: что должно произойти. Негативная логика требует отдельного шага.
Один эпизод с Сортулы: задача — при повторной отправке ссылки в ВК-боте обновлять дату просмотра, а не создавать дубль. Позитивный сценарий написал. Негативный — нет: что если пользователь отправляет тот же пост с другого аккаунта ВК, привязанного к тому же телефону.
Агент создал две закладки. Пользователь видел дубли. В правильно оформленной спеке был бы критерий: «один и тот же адрес поста от разных аккаунтов одного пользователя не должен порождать вторую закладку». Этот пункт прошёл бы через QG-0, агент увидел бы его — и задача закрылась бы корректно.
Теперь на любую задачу с данными задаю простой вопрос: что должно произойти, если на вход придёт что-то неожиданное? Пустое значение, повтор, конкурентный запрос, ошибка внешнего сервиса, превышение лимита. Хотя бы один из этих сценариев почти всегда применим. Если ни один — скорее всего, я просто не подумал.
QG-2: выход. Как нельзя закрыть задачу
Если QG-0 не пускает плохую постановку, то QG-2 не пускает плохую приёмку. Три управленческие проверки на выходе:
- Сверка с критериями приёмки. Каждый критерий должен иметь явное подтверждение: тест, ручная пометка, скриншот, ссылка на артефакт. «Всё работает, я посмотрел» — не проходит. В TAUSIK задача не закрывается, пока не отмечено состояние по каждому критерию.
- Регистрация ручных правок. Если правил код вручную — каждая правка фиксируется: что изменил, почему. Запись попадает в память проекта и помечает задачу как требовавшую ручной правки. По ним считается MIR. Соблазн молча поправить остаётся, но теперь он требует явного шага.
- Обновление памяти проекта. Если всплыло что-то новое — пограничный случай, особенность инфраструктуры — это записывается типизированной заметкой. Например, фоновая задача без маршрута садится в очередь по умолчанию, которую никто не слушает. Такие заметки появляются на QG-2, когда видно, какие пробелы задача вскрыла.
- Проверка не на бумаге. В TAUSIK QG-2 встроен: команда закрытия запускает все проверки и блокирует закрытие, если хотя бы одна не пройдена. Перед глазами — список, что осталось доделать.
Ручная правка — плохой рефлекс. Сама правка может быть нужной, но без фиксации агент в следующей задаче снова опирается на исходный вариант. Запись закрывает дыру и делает MIR честным.
Эффект не виден сразу. Через месяц журнал закрытых задач выглядит честнее: меньше задач без подтверждённых критериев, меньше молчаливых правок, толще память проекта. И главное — меньше пятничных задач, возвращающихся багом в воскресенье.
Метрики: FPSR, MIR, DER и ERR операционно
Метрики — не самоцель. Это сигналы, показывающие, где контур провисает.
- FPSR — доля задач, решённых с первой попытки. На серверной части в знакомой области выросла с 40% до 75–80% после внедрения спецификаций. Низкая FPSR — чаще всего пробелы в спеке: агент достраивает смысл, задачу возвращают. Чинится через QG-0.
- MIR — доля задач с ручной правкой. На Сортуле снизился с 20% до 5–7% после накопления контекста. Высокий MIR — контекст неполный или неточный. Лечится через анализ повторяющихся правок и улучшение контекста.
- DER — доля тупиковых попыток. Считается по времени и количеству. Высокий DER — провал в контексте или слишком широкая задача. Лечится через фиксацию тупиков и декомпозицию.
- ERR — доля закрытых задач, по которым позже заводили исправление. Снизился с 15% до 6% после введения негативных сценариев и проверки критериев на выходе.
Метрики читаются связкой:
- Низкий FPSR + низкий MIR — плохие спеки: задачу возвращают, но не из-за правок.
- Высокий MIR + приличный FPSR — контекст не дотягивает: задачу берут с первой попытки, но доводят вручную.
- Высокий DER — потери на непродуктивные ветки.
- Высокий ERR при хорошем FPSR и MIR — критерии слишком позитивные.
Главное — не уровень метрик, а язык. Раньше плохая неделя была «хаос». Теперь — «MIR пошёл вверх на интеграционных задачах, контекст по новому модулю кривой». Второе чинится. Первое — нет.
Где ворота не помогают
Контур не закрывает всё.
- Задачи на ощущение продукта. «Кнопка должна быть отзывчивой», «анимация — приятной», «текст ошибки — человеческим». Эти критерии не формализуются. Спецификация может быть идеальной — а результат всё равно переделывать. Ворота помогают только структурой.
- Чужая документация, противоречащая сама себе. Когда внешний сервис возвращает не то, что обещано — никакая спека не спасёт. Сначала надо разобраться вручную, как сервис работает на самом деле. QG-0 пройдён, агент честно реализовал — а в проде сюрприз. Лечится только собственным контрактом на интеграцию.
Есть и более широкие границы: незнакомая предметная область, деградация архитектуры, переход от одного человека к команде. О них — в шестой статье. Здесь важно: ворота снимают рутину, но не отменяют понимания продукта, знания домена и умения читать чужие интерфейсы. Этого никакой контур не закроет.
Если унести из статьи одну мысль
Ворота в SENAR — не бюрократия. Это единственный способ, при котором личная дисциплина перестаёт быть единственной защитой от пятничной усталости.
На входе — не пускают задачу без цели, критериев, негативных сценариев. На выходе — не пускают закрыть задачу, пока критерии не сверены, ручные правки не зарегистрированы, память проекта не пополнена.
Между воротами агент работает не в пустоте. Его среда — контекст, архитектурные границы, типизированная память. Без них даже идеальная спека ломается. Агент в третий раз заходит в задачу с нуля, не знает, что нельзя трогать, и снова наступает на тупик, зафиксированный в чьей-то голове, но не в репозитории.
Об этой среде — в следующей статье.