Руководство SENAR: Режимы отказа

SENAR может давать сбои. Любая методология может. Этот документ описывает, как именно внедрения SENAR терпят неудачу, как обнаружить проблемы на ранней стадии и что с ними делать.

Режимы отказа разделены на три категории: процессные (методология принята, но практикуется неправильно), организационные (люди и структуры вокруг SENAR деградируют) и технические (AI-инструменты и инфраструктура подрывают процесс).

Процессные отказы

PF-1: Теневое кодирование

Описание: Супервайзеры тайно пишут код вместо направления AI-агентов. Задача выглядит как AI-сгенерированная, метрики в норме, но реализацию делает человек. Это подрывает главную предпосылку SENAR: ценность Супервайзера — в суждениях, а не в наборе текста.

Ранние признаки:

Manual Intervention Rate превышает 30% без соответствующих записей Dead End, объясняющих, почему AI не справился
Временные метки коммитов группируются за пределами окон сессий
Супервайзеры сообщают, что «быстрее без AI», но не могут сформулировать, с чем именно AI не справляется
В базе знаний нет записей Dead End или Gotcha — всё «просто работает» (потому что человек сделал сам)
Количество вызовов инструментов за сессию подозрительно мало относительно сложности задач

Действия по восстановлению:

Провести непредвзятый аудит: сравнить git diff с логами сессий AI на выборке задач
Определить, какие типы задач провоцируют теневое кодирование — скорее всего, у них плохие шаблоны контекста
Улучшить качество контекста для этих типов задач (более точные критерии приёмки, паттерны, архитектурные ограничения)
Если AI действительно не справляется с определёнными типами задач, создать явный тип работы «ручная реализация» с отдельным отслеживанием

Профилактика:

Нормализовать ручное вмешательство как документируемую, отслеживаемую активность — а не постыдный секрет
Отслеживать Manual Intervention Rate как диагностическую метрику, а не метрику эффективности
Убедиться, что Супервайзеры понимают: высокий MIR для определённых типов задач — сигнал к улучшению контекста, а не личная неудача
Логи сессий должны проверяться при Quality Sweep — не для контроля, а для выявления пробелов в контексте

PF-2: Формальное утверждение

Описание: Супервайзеры принимают результаты AI без содержательной проверки. Код проходит QG-2 (автоматические тесты, линтер, типы), но никто не проверяет, правильно ли он решает задачу, обрабатывает ли граничные случаи, соответствует ли архитектуре. Человек превращается в нажимателя кнопок.

Ранние признаки:

Defect Escape Rate растёт, а First-Pass Success Rate остаётся подозрительно высоким (всё «проходит», но баги появляются позже)
Комментарии к code review отсутствуют или формальны («LGTM», «looks good»)
Время верификации задачи опускается ниже правдоподобного минимума (изменение в 200 строк проверено за 30 секунд)
Архитектурный дрейф: паттерны расходятся по кодовой базе, потому что никто не следит за единообразием
Уязвимости безопасности появляются в продакшене, хотя рецензент-человек должен был их заметить

Действия по восстановлению:

Обязательный Quality Sweep с фокусом на последние 2 инкремента — сравнить слитый код с требованиями
Ввести QG-3 (Шлюз качества верификации), если ещё не активен: независимая проверка другим Супервайзером
Установить минимальные пороги времени проверки пропорционально объёму изменений
Создать «Чек-лист проверки AI» (см. Руководство 02) и требовать его заполнения для каждой задачи

Профилактика:

QG-3 с независимой верификацией — самая сильная защита
Ротация назначений Verification Engineer, чтобы проверяющие оставались внимательными
Отслеживать Defect Escape Rate на видном месте — это главный индикатор формального утверждения
Quality Sweep должен проверять реальный код, а не только дашборды метрик

PF-3: Нормализация обхода шлюзов

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

Ранние признаки:

Более 10% задач имеют записи об обходе шлюзов
Один и тот же шлюз обходится многократно (например, QG-0 пропускается, потому что «мы и так знаем, что делать»)
Обоснования обхода становятся шаблонными («нехватка времени», «исправим в следующем инкременте»)
Задачи технического долга, созданные из обходов, никогда не завершаются
Новые члены команды усваивают обход шлюзов как стандартную практику

Действия по восстановлению:

Аудит всех записей обходов за последние 2 инкремента — категоризировать по шлюзу и обоснованию
Для каждого регулярно обходимого шлюза определить: шлюз слишком строгий (скорректировать критерии) или команда недообучена (вложиться в процесс)?
Требовать утверждения обхода от кого-то, кроме самого Супервайзера
Ввести «бюджет обходов» на инкремент — максимальное число допустимых обходов. По исчерпании шлюз блокируется жёстко

Профилактика:

Отслеживать частоту обходов как метрику на ретроспективах инкрементов
Ретроспектива должна включать «обзор обходов» — каждый обход обсуждается, а не просто считается
Критерии шлюзов следует пересматривать ежеквартально: если шлюз регулярно обходится, возможно, нужна корректировка критериев, а не ужесточение дисциплины
Различать «шлюз слишком строгий» (проблема критериев) и «дисциплина слишком низкая» (проблема культуры) — реакция разная

PF-4: Устаревание базы знаний

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

Ранние признаки:

Knowledge Capture Rate падает ниже 0.3 записей на задачу на протяжении 3+ последовательных сессий
Новые Супервайзеры сообщают, что записи базы знаний противоречат тому, что они видят в коде
AI-агенты генерируют результат с использованием паттернов из базы знаний, от которых команда уже отказалась
Даты «последней проверки» записей старше 3 инкрементов
Записи Dead End ссылаются на инструменты или библиотеки, которых уже нет в стеке

Действия по восстановлению:

Запланировать выделенную сессию аудита базы знаний — оформить как задачу, а не побочную активность
Пометить каждую запись статусом свежести: актуальна, требует проверки, устарела
Немедленно удалить или архивировать устаревшие записи — устаревший контекст хуже его отсутствия
Назначить обслуживание базы знаний явной обязанностью (роль Knowledge Engineer)

Профилактика:

Церемония Quality Sweep (Стандарт, раздел 7.4) должна включать аудит свежести базы знаний
Записи должны иметь метку «последняя проверка», обновляемую при подтверждении актуальности
Установить целевой Knowledge Capture Rate (0.3–0.5 записей/задача) и отслеживать на ретроспективах
Если задача порождает результат, противоречащий записи базы знаний, запись должна быть обновлена до закрытия задачи

PF-5: Прекращение документирования тупиков

Описание: Команды перестают документировать неудачные подходы. Dead End — один из самых ценных типов знаний: они предотвращают повторение ошибок AI-агентами. Под давлением сроков документирование тупиков сокращается первым, потому что оно описывает то, что не сработало, а это кажется малоприоритетным.

Ранние признаки:

Записи Dead End за инкремент падают до нуля
AI-агенты пробуют подходы, которые уже были опробованы и отвергнуты в предыдущих сессиях
Длительность сессий увеличивается, потому что AI исследует пути, о провале которых человек помнит, но не задокументировал
Документы передачи упоминают «мы пробовали X, но не сработало» без создания записи в базе знаний

Действия по восстановлению:

Проверить последние 5 документов передачи на упоминание неудачных подходов — создать запись Dead End для каждого
Добавить «фиксацию Dead End» как явный шаг в церемонию Session End
Сделать документирование Dead End частью критериев приёмки QG-2 для сложных задач

Профилактика:

Шаблон Session End должен включать раздел «Неудачные подходы», который становится записью Dead End
Метрику Knowledge Capture Rate следует декомпозировать по типам записей — здоровая база знаний содержит микс решений, паттернов, подводных камней и тупиков
Отмечать документирование Dead End как ценность: это не хроника неудач, а карта территории

PF-6: Размывание дисциплины сессий

Описание: Сессии растягиваются за разумные пределы. Супервайзеры пропускают Session Start (нет загрузки контекста, нет выбора задач) или Session End (нет передачи, нет сбора метрик). Граница сессии — основной ритмический механизм SENAR — растворяется в непрерывной, бесструктурной работе.

Ранние признаки:

Длительность сессий регулярно превышает 8 часов
Записи Session Start не содержат списка задач или проверки контекста
Документы передачи пусты или отсутствуют
Контрольные точки никогда не создаются
Количество вызовов инструментов за сессию превышает 500 (зона усталости)
Качество результатов AI деградирует во второй половине сессий (исчерпание контекстного окна)

Действия по восстановлению:

Установить жёсткие ограничения по времени сессий — рекомендуемый диапазон 4–6 часов
Сделать Session End блокирующим шагом: следующая сессия не может начаться без завершённой передачи
Внедрить автоматические напоминания о контрольных точках с интервалом 40–60 вызовов инструментов
Проверить последние 10 сессий на отсутствие передач и создать их ретроспективно

Профилактика:

Session Start и Session End — это церемонии, а не необязательные шаги
Инструментарий должен обеспечивать: сессия не может начаться, если предыдущая не имеет передачи
Установить максимальный бюджет вызовов инструментов на сессию (300–500 в зависимости от сложности задач)
Усталость Супервайзера реальна: качество верификации деградирует через 4–6 часов. Процесс должен учитывать человеческие ограничения

PF-7: Метрики тщеславия

Описание: Команды оптимизируют метрики, не улучшая результатов. Производительность раздувается за счёт дробления задач на тривиально мелкие единицы. First-Pass Success Rate накручивается снижением критериев приёмки. Lead Time сокращается за счёт начала задач до их готовности. Цифры выглядят хорошо; программное обеспечение — нет.

Ранние признаки:

Производительность резко возрастает, а удовлетворённость заинтересованных сторон — нет
Средняя сложность задач падает до «тривиальной» для 80%+ задач
FPSR выше 95%, но Defect Escape Rate тоже выше 10% (противоречивые сигналы)
Lead Time уменьшается, но развёрнутые фичи неполны или содержат баги
Команды сопротивляются добавлению новых метрик или изменению существующих
Cost per Task падает, но общая стоимость инкремента — нет

Действия по восстановлению:

Перекрёстная проверка метрик: Throughput x DER, FPSR x дефекты после развёртывания, Lead Time x процент доработки
Ввести «метрики результатов» наряду с процессными: частота развёртываний, процент отказов при изменениях, время восстановления
Пересмотреть рекомендации по гранулярности задач — задача должна представлять значимое, проверяемое изменение
Ретроспектива должна сопоставлять метрики с реальными результатами для заинтересованных сторон

Профилактика:

Никогда не поощрять и не наказывать на основе одной метрики
Метрики существуют для диагностики, а не для суждений — закрепить это явно в нормах команды
DER — метрика, которую сложнее всего накрутить, потому что она измеряется внешней реальностью (баги в продакшене)
Quality Sweep должен проверять, что метрики рассказывают непротиворечивую историю

Организационные отказы

OF-1: Выгорание Супервайзеров

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

Ранние признаки:

Качество верификации падает в послеобеденных сессиях (формальное утверждение после обеда)
Супервайзеры сообщают об ощущении «измотанности», несмотря на отсутствие написания кода
Частота обходов шлюзов возрастает к концу рабочей недели
Растут больничные и текучка кадров
Супервайзеры предпочитают простые задачи и избегают сложных

Действия по восстановлению:

Сократить длительность сессий до 3–4 часов с обязательными перерывами
Чередовать глубокую работу по верификации с более лёгкими задачами (документация, курирование базы знаний)
Внедрить парную супервизию: два Супервайзера верифицируют сложные задачи друг друга
Обеспечить Супервайзерам автономию в выборе задач и планировании сессий

Профилактика:

Проектировать сессии с учётом нагрузки на верификацию — не все задачи требуют одинакового уровня тщательности
Закладывать время на работу вне верификации: обслуживание базы знаний, улучшение контекста, обучение
Отслеживать количество вызовов инструментов и длительность сессий — это опережающие индикаторы выгорания
Учитывать разницу между «AI может работать 24 часа» и «человек не может верифицировать 24 часа»

OF-2: Атрофия навыков

Описание: Супервайзеры полностью перестают писать код и постепенно теряют способность оценивать результаты AI на глубоком техническом уровне. Они замечают поверхностные проблемы (опечатки, очевидные баги), но пропускают архитектурные проблемы, антипаттерны производительности и тонкие уязвимости безопасности. Ценность «суждение важнее нажатий клавиш» требует, чтобы суждение оставалось острым.

Ранние признаки:

Супервайзеры не могут объяснить, почему конкретный подход к реализации ошибочен
Архитектурные решения всё чаще делегируются AI без возражений со стороны человека
Code review сводится к «работает ли это?» вместо «правильный ли это подход?»
Супервайзеры избегают задач в незнакомых частях кодовой базы
Новые технологии принимаются без понимания Супервайзером компромиссов

Действия по восстановлению:

Ввести «дни ручной реализации» — периодические сессии, где Супервайзеры пишут код без помощи AI
Требовать от Супервайзеров описания архитектурного подхода до того, как AI приступит к реализации
Ротировать Супервайзеров между разными частями кодовой базы для стимулирования обучения
Включить «объясните реализацию» как часть верификации: если не можешь объяснить — не можешь проверить

Профилактика:

Супервайзеры должны периодически реализовывать сложные задачи вручную для поддержания квалификации
Время на техническое обучение должно быть заложено в бюджет — не как накладные расходы, а как поддержание компетенций
Роль Context Architect поддерживает вовлечённость Супервайзеров в проектирование системы, а не только в верификацию задач
Quality Sweep, требующий глубокого понимания кода, служит двойной цели: обеспечение качества и поддержание навыков

OF-3: Привязка к поставщику AI-инструментов

Описание: Внедрение SENAR становится глубоко связанным с конкретным инструментом, моделью или платформой AI. Шаблоны сессий, формат базы знаний, механизмы инъекции контекста и процессы верификации предполагают API и возможности конкретного поставщика. Переход становится непомерно дорогим.

Ранние признаки:

Все шаблоны контекста используют специфичный для поставщика синтаксис или функции
Формат базы знаний оптимизирован под размер контекстного окна одной модели
Управление сессиями встроено в проприетарную платформу без экспорта
Отслеживание затрат зависит от API биллинга конкретного поставщика
Экспертиза команды в «использовании инструмента X», а не в «супервизии AI-агентов»

Действия по восстановлению:

Аудит всех точек соприкосновения между процессом SENAR и инструментарием AI — составить инвентарь абстракций
Определить вендоронезависимый интерфейс для инъекции контекста, захвата результатов и управления сессиями
Извлечь базу знаний в портативный формат (структурированный markdown, JSON)
Провести параллельные сессии с альтернативными инструментами для проверки портативности

Профилактика:

SENAR намеренно не предписывает конкретные AI-инструменты — сохраняйте эту нейтральность
Хранить базу знаний в формате, читаемом любой LLM (структурированный текст, не проприетарные эмбеддинги)
Управление сессиями должно быть тонким слоем, а не платформой
Периодически оценивать альтернативные инструменты для сохранения вариативности

OF-4: Избыточный процесс (бюрократический SENAR)

Описание: SENAR становится самоцелью. Каждая задача требует исчерпывающей документации. Каждая сессия начинается с 30-минутной церемонии. Каждая запись в базе знаний нуждается в трёх утверждениях. Методология, призванная повысить производительность, становится главным препятствием на пути к ней.

Ранние признаки:

Session Start занимает больше 30 минут
На церемонии SENAR тратится больше времени, чем на реальную работу
Супервайзеры создают задачи «соответствие процессу», не приносящие ценности ПО
Новые Супервайзеры подавлены количеством обязательных шагов
Команды ведут две системы: «официальный» процесс SENAR и свой реальный рабочий процесс

Действия по восстановлению:

Измерить «долю процессных накладных расходов»: время на церемонии / время на продуктивную работу. Если превышает 20%, процесс слишком тяжёлый
Пересмотреть, какой уровень SENAR (Базовая/Командная/Корпоративная) действительно соответствует потребностям команды — многие команды перестарались с внедрением
Автоматизировать всё, что можно автоматизировать — ручных церемониальных шагов должно быть минимум
Применить собственный принцип SENAR: «Принуждение вместо церемонии» — если шаг можно автоматизировать, он не должен быть ручной церемонией

Профилактика:

Начинать с SENAR Core и повышать уровень только когда конкретные болевые точки оправдывают дополнительный процесс
У каждой церемонии должен быть определённый таймбокс
У каждого ручного шага должно быть обоснование: «какой отказ он предотвращает?» Если ответ неясен — убрать шаг
Периодически проводить «аудит процесса» — все ли шаги по-прежнему оправдывают свою стоимость?

OF-5: Недостаточный процесс (вечный L2)

Описание: Команда принимает SENAR Core (уровень зрелости 2) и никогда не развивается дальше. Задачи существуют, Стартовый шлюз и Финишный шлюз работают, FPSR и DER отслеживаются — но нет независимой верификации, нет дисциплины ведения базы знаний, нет координации через федерацию. Команда получает минимальную пользу и выходит на плато.

Ранние признаки:

Один и тот же процесс 6+ месяцев без эволюции
Рост базы знаний остановился
DER стабилен, но никогда не улучшается
Кросс-проектные зависимости управляются хаотично (почта, мессенджеры), а не через федерацию
Нет ретроспектив инкрементов — метрики собираются, но не анализируются
Команда говорит «SENAR работает нормально», но не может указать на конкретные улучшения

Действия по восстановлению:

Провести оценку зрелости по всем 6 измерениям (раздел 12.2) — определить самое слабое
Выбрать ОДНО измерение для улучшения в следующем инкременте — не пытаться прыгнуть с L2 на L3 по всем измерениям одновременно
Назначить ответственного за улучшение (обязанность Flow Manager)
Установить измеримую цель: «Снизить DER с 12% до 8% к концу инкремента»

Профилактика:

Включить «улучшение процесса» как постоянный пункт в планирование инкремента
Роль Flow Manager существует именно для движения эволюции процесса — убедиться, что она укомплектована
Установить явные целевые уровни зрелости со сроками
Пересматривать модель зрелости SENAR (раздел 12) на каждой ретроспективе

OF-6: Сопротивление Супервайзеров

Описание: Разработчики отказываются принимать роль Супервайзера. Они воспринимают SENAR как деквалификацию: творческая, интересная работа по написанию кода заменяется бюрократической верификацией машинных результатов. Сопротивление может быть тихим (пассивное несоответствие) или громким (активное противодействие).

Ранние признаки:

Высокий уровень теневого кодирования (PF-1) — разработчики пишут код и ретроактивно создают задачи под него
Супервайзеры описывают себя как «рецензентов» или «тестировщиков», а не «инженеров»
Найм на роли Супервайзеров затруднён — кандидаты хотят «настоящие инженерные» позиции
Опросы настроений команды показывают неудовлетворённость определением роли
Опытные разработчики уходят на традиционные позиции

Действия по восстановлению:

Напрямую обратиться к вопросу идентичности: Супервайзер — это более старшая роль, чем разработчик, а не более низкая
Подчеркнуть аспекты роли, требующие более глубоких навыков: архитектурное суждение, проектирование контекста, верификация сложных систем
Позволить Супервайзерам выбирать, когда кодить вручную — автономия снижает сопротивление
Приводить конкретные примеры того, как роль Супервайзера усиливает индивидуальное влияние (производительность, умноженная на AI)

Профилактика:

Позиционировать переход как карьерный рост, а не понижение роли
Обеспечить соответствие компенсации увеличенному масштабу и ответственности роли Супервайзера
Предоставить Руководство по переходу (Руководство 04) и дать достаточное время на адаптацию
Создать сообщества практик, где Супервайзеры делятся техниками и отмечают успехи

OF-7: Информационные силосы

Описание: Каждый Супервайзер вырабатывает собственные недокументированные паттерны подготовки контекста, структурирования задач и взаимодействия с AI. Эти паттерны эффективны, но существуют только в голове Супервайзера. Когда он недоступен, другие Супервайзеры не могут воспроизвести его результаты.

Ранние признаки:

Производительность сильно варьируется между Супервайзерами на однотипных задачах
Записи в базе знаний скудны или общи — «настоящий» контекст в личных заметках
Супервайзеры не могут подменять друг друга во время отсутствия
Документы передачи не содержат «приёмов», делающих сессию продуктивной
Новым Супервайзерам требуются месяцы для достижения базовой продуктивности

Действия по восстановлению:

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

Профилактика:

Метрику Knowledge Capture Rate следует отслеживать по каждому Супервайзеру, а не только в совокупности
Шаблоны контекста должны быть общими артефактами, а не личными файлами
Передача сессий должна содержать «что сработало хорошо» для подготовки контекста, а не только статус задач
Роль Knowledge Engineer существует для предотвращения силосов — убедиться, что она активно практикуется

Технические отказы

TF-1: Смена модели обнуляет базовые показатели

Описание: Модель AI обновляется (новая версия, другой поставщик или изменение дообучения), и все установленные базовые показатели становятся недействительными. Throughput, FPSR, Lead Time и Cost per Task смещаются непредсказуемо. Команда теряет способность обнаруживать процессные проблемы, потому что сигнал тонет в шуме от смены модели.

Ранние признаки:

Резкий сдвиг всех метрик после обновления модели
Задачи, ранее имевшие высокий FPSR, начинают проваливаться
Cost per Task значительно меняется (часто в обе стороны для разных типов задач)
Шаблоны контекста, которые работали хорошо, теперь дают худшие результаты
Поведение AI меняется тонко: другой стиль кода, другие предпочтения библиотек, другие паттерны обработки ошибок

Действия по восстановлению:

Рассматривать смену модели как «событие сброса базовых показателей» — задокументировать изменение и зафиксировать метрики до и после
Прогнать выборку типичных задач на новой модели для установления новых базовых показателей
Обновить шаблоны контекста и записи базы знаний, предполагавшие специфическое поведение модели
Допустить 1–2 сессии со сниженными ожиданиями по производительности, пока команда калибруется

Профилактика:

Фиксировать версии моделей в продакшене — не обновлять автоматически
При оценке новой модели запускать параллельную проверку на репрезентативном наборе задач перед переходом
Писать шаблоны контекста модель-нейтрально: описывать что вы хотите, а не как модель должна это сделать
Вести «журнал смены моделей» с указанием версии модели для базовых показателей каждого инкремента

TF-2: Ограничения контекстного окна

Описание: Контекстное окно AI конечно. По мере роста проектов контекст, необходимый для задачи (знание кодовой базы, архитектурные ограничения, связанные паттерны, предыдущие решения), превышает то, что помещается в одну сессию. Задачи дробятся искусственно — не потому, что естественно разделяемы, а потому что AI не может удержать достаточно контекста.

Ранние признаки:

Задачи разбиваются на подзадачи, не имеющие смысла как самостоятельные единицы
AI «забывает» инструкции, данные ранее в сессии
Результаты в конце сессии противоречат решениям начала
Супервайзеры тратят всё больше времени на повторное объяснение контекста после контрольных точек
Сложные задачи рефакторинга проваливаются, потому что AI не видит достаточно кодовой базы одновременно

Действия по восстановлению:

Реструктурировать инъекцию контекста: приоритизировать высокоценный контекст (архитектурные ограничения, активные паттерны) над низкоценным (полное содержимое файлов)
Использовать записи базы знаний как сжатый контекст: 5-строчная запись решения заменяет чтение 500 строк кода
Реализовать прогрессивную загрузку контекста: начинать с обзора архитектуры, подгружать детали по необходимости
Принять, что некоторые задачи требуют нескольких сессий — проектировать документы передачи для переноса контекста через границу сессий

Профилактика:

Записи базы знаний — инструменты сжатия контекста. Вкладываться в качественные, лаконичные записи
Архитектурная документация должна быть структурирована для потребления AI: ясно, сжато, с явными ограничениями
Проектировать гранулярность задач вокруг естественных границ, а не размера контекстного окна
Мониторить утилизацию контекстного окна и установить командные соглашения по распределению контекстного бюджета

TF-3: Архитектурно неверный, но проходящий шлюзы код

Описание: AI генерирует код, который проходит все автоматические шлюзы качества (тесты проходят, типы проверяются, линтер чист, сканер безопасности не находит проблем), но архитектурно ошибочен. Он может использовать неправильный паттерн, создавать неуместную связность, обходить устоявшиеся абстракции или вводить зависимость, которая создаст проблемы через 6 месяцев. Автоматические шлюзы проверяют корректность; они не могут проверить суждение.

Ранние признаки:

Code review всё чаще выявляют проблемы «работает, но неправильно»
Аналогичная функциональность реализована по-разному в разных частях кодовой базы
Устоявшиеся абстракции обходятся — AI создаёт новые паттерны вместо использования существующих
Граф зависимостей растёт в неожиданных направлениях
Стоимость рефакторинга растёт со временем по мере накопления архитектурного дрейфа

Действия по восстановлению:

Усилить Шлюз качества верификации QG-3 явными критериями архитектурного ревью
Создать записи «архитектурных ограничений» в базе знаний, инъецируемые в контекст каждой сессии
Провести аудит архитектурного здоровья — выявить и задокументировать все устоявшиеся паттерны
Рассмотреть архитектурно-специфичные правила линтинга, поддающиеся автоматизации (ограничения зависимостей, нарушения слоёв)

Профилактика:

Архитектурные решения должны быть задокументированы в базе знаний, а не только в коде
Шаблоны контекста для каждой области кодовой базы должны содержать инструкции «используй этот паттерн, а не тот»
Quality Sweep должен включать проверку архитектурной согласованности
Роль Context Architect критически важна здесь: она обеспечивает получение AI правильных архитектурных ограничений
Автоматизированные функции архитектурной пригодности (правила зависимостей, проверки слоёв) превращают суждение в принуждение

TF-4: Фантомные зависимости

Описание: На протяжении сессий AI-агенты вводят зависимости (библиотеки, сервисы, вызовы API, общее состояние), которые не отслеживаются явно. Каждая зависимость по отдельности обоснована, но в совокупности создаётся хрупкая система. Ни один человек или документ не охватывает полный граф зависимостей.

Ранние признаки:

Время сборки растёт без очевидных причин
Манифест пакетов (package.json, requirements.txt, go.mod) неуклонно разрастается
Учащаются проблемы «на моей машине работает» — настройка окружения ненадёжна
Обновление одной зависимости вызывает каскадные отказы
Никто не может объяснить, зачем была добавлена конкретная зависимость
Связность сервисов растёт: изменения в одном сервисе требуют изменений в других

Действия по восстановлению:

Провести аудит зависимостей: для каждой зависимости найти задачу, которая её ввела, и проверить, нужна ли она до сих пор
Создать тип записи «решение о зависимости» в базе знаний — каждая новая зависимость требует задокументированного обоснования
Внедрить обнаружение изменений зависимостей в CI — любая новая зависимость вызывает флаг ревью
Вычистить неиспользуемые зависимости

Профилактика:

Добавить обоснование зависимостей в критерии приёмки QG-2: «никаких новых зависимостей без задокументированной причины»
Отслеживать количество зависимостей как вторичную метрику
Quality Sweep должен включать ревью зависимостей
Шаблоны контекста должны перечислять одобренные зависимости и их назначение — AI предпочитает то, о чём знает

TF-5: Бессмысленное покрытие тестами

Описание: AI генерирует тесты, которые достигают высоких метрик покрытия, но не проверяют осмысленное поведение. Тесты зеркалируют реализацию: они проверяют, что код делает то, что код делает, а не что код делает то, что требуют требования. Это особенно коварно, потому что показатель покрытия выглядит прекрасно.

Ранние признаки:

Покрытие тестами выше 90%, но Defect Escape Rate тоже высок
Тесты ломаются при изменении реализации, но не при изменении поведения (хрупкие, тесно связанные тесты)
Описания тестов обобщённые: «должен работать корректно», «обрабатывает входные данные»
Тесты не покрывают граничные случаи, пути ошибок или граничные условия
Мутационное тестирование убивает мало мутантов при высоком покрытии строк
Интеграционные тесты на самом деле являются юнит-тестами с замоканными зависимостями

Действия по восстановлению:

Запустить мутационное тестирование для оценки реальной эффективности тестов — покрытие ничего не значит без показателя убийства мутантов
Проверять качество тестов в Quality Sweep: тесты верифицируют требования или зеркалируют реализацию?
Требовать, чтобы критерии приёмки включали конкретные тестовые сценарии — AI пишет тесты от сценариев, а не от кода
Ввести property-based тестирование для критичных путей

Профилактика:

Критерии приёмки должны определять тестовые случаи: «при X, когда Y, тогда Z» — а не «напиши тесты для этой функции»
Отслеживать показатель мутационного тестирования наряду с покрытием
QG-2 должен включать проверку качества тестов, а не только порогов покрытия
База знаний должна содержать паттерны тестирования: «как мы тестируем функциональность типа X»
Разделять промпт агента для написания тестов и промпт агента для реализации — тесты должны верифицировать требования, а не зеркалировать код

Итоги

Ни один режим отказа в этом документе не является теоретическим. Каждый наблюдался на практике — либо в AI-нативной разработке, либо в аналогичных паттернах традиционного внедрения Agile/SAFe.

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

Лучшая защита — не больше процесса, а лучшие петли обратной связи:

Метрики с перекрёстной проверкой — ни одна метрика в одиночку не говорит правды
Quality Sweep, проверяющие реальность — не только дашборды метрик, а реальный код и реальные записи базы знаний
Ретроспективы, задающие трудные вопросы — не «хороши ли наши цифры?», а «хорошо ли наше программное обеспечение?»
Культура, где документирование неудач ценится — осведомлённость о Dead End и режимах отказа предотвращает повторение ошибок