Кому это в принципе не подходит

Начну с оговорки, которую стоило сделать ещё в первой статье; я жалею, что не сделал.

SENAR собирался под опытного инженера, который уже умеет строить софт и хочет структурированный процесс работы с агентами. Под того, кто способен декомпозировать задачу до уровня агента, спроектировать архитектурную границу, увидеть тонкий баг в сгенерированном коде, отличить тест, проверяющий поведение, от теста, повторяющего реализацию. Без этих навыков ворота качества из четвёртой статьи превращаются в ритуал: формально QG-0 пройден, спецификация заполнена, критерии приёмки перечислены, всё мимо.

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

Методология не заменяет инженерную базу. Она работает поверх неё.

Где это не работает

Дальше про области, в которых конструкция из пяти предыдущих статей не доводит до результата вне зависимости от того, насколько хорошо вы её освоили. В концечетвёртой статьия обещал вернуться к незнакомому домену, деградации архитектуры и переносу на команду; ниже пять категорий с разными механизмами отказа, часть из них перекрывается с теми обещаниями.

Регулируемые отрасли.Медицина по IEC 62304, финансы под SOX, авиация под DO-178C. Регуляторов объединяет требование ответственности и прослеживаемости: решение принимает и отвечает за него конкретный человек с подтверждённой квалификацией, не модель. SENAR даёт трассируемость, каждое требование привязано к задаче, каждая задача к коду, каждое решение зафиксировано. Это близко к тому, что хочет аудитор, но не равно. Аудитор смотрит на ответственного за модуль; одна трассируемость документов вопрос не закрывает. Ответ в стилеагент сгенерировал по спецификации, человек верифицировал по чеклистуработает только если в журнале аудита человек берёт на себя ответственность за результат, а не ИИ. И тогда экономия от агентной разработки съедается стоимостью верификации, которая по факту становится плотнее, чем была бы у инженера, пишущего код руками.

В финансовом контуре есть отдельная проблема. SOX требует разделения обязанностей: тот, кто пишет код, не имеет права его проверять. А в модели одной ячейки одинИИ-инженери набор агентов, как я описывал роль человека втретьей статье, и код, и его проверку делает один и тот же человек. Формально L3 adversarial-ревью канона SENAR (независимый агент без доступа к рассуждениям первого) подходит под определение независимой проверки, но примет ли это аудитор как разделение обязанностей в смысле SOX, открытый вопрос. По моему опыту разговоров с аудиторами, ответ скорее отрицательный, пока регуляторная база не подстроится явно. А подстраивается она годами.

Это не значит, что в регулируемых отраслях ИИ-разработка бесполезна. Гибридная модель работает: агент генерирует код, инженер верифицирует и подписывается под результатом, журнал аудита называет именно инженера. SENAR с его трассируемостью ближе к тому, что нужно аудитору, чем неструктурированная разработка. Но 100% делегирование, как у меня на закрытом тестовом проекте, тут невозможно.

Глубокий R&D без критериев приёмки.Если задачу нельзя сформулировать в критериях приёмки до начала работы, это не задача в смысле SENAR, а исследование. У меня есть несколько таких случаев: разобраться, годится ли определённый алгоритм машинного обучения для нашего класса задач; понять, насколько определённый сторонний сервис стабилен под нагрузкой; найти, где в системе теряется производительность под профайлером.

В каждом из этих случаев QG-0 нельзя пройти честно. Критерии приёмки нечего написать, потому что результат заранее неизвестен. Можно их выдумать, и тогда задача формально открывается, но это самообман: критерии не привязаны к реальной цели, верификация на выходе ничего не значит.

Лечится разделением. Сначала человек проводит исследование как исследование, без агента или с агентом в режиме помощника по чтению, без обязательства закрывать задачу с критериями. По результатам появляется понимание, что должно получиться. Только после этого формируется задача с критериями приёмки, и она уже передаётся в обычный SENAR-контур. У меня от исследовательской фазы до фазы реализации обычно неделя-две, и эти две недели я работаю как инженер до агентной эры, со всеми её ограничениями.

Глубокий legacy без живого носителя контекста.Система на миллион строк, документации нет, авторы ушли. Контекст под задачу собирать неоткуда: код не самоописывается на нужном уровне, неявных договорённостей много, и они известны только тем, кого уже нет. Агент может вычитать архитектуру по коду, но эта восстановленная архитектура правдоподобна, не настоящая. Подсветить разницу нечем, носителей нет.

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

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

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

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

Рабочая модель здесь следующая: доменный эксперт валидирует спецификацию до начала работы, код — нет. На русском языке, со всеми привычными для эксперта оборотами. Проверить Python-код бухгалтер не может, проверить текстовое описание налоговой логики бухгалтер может. Это другая работа эксперта, и она в работу ячейки должна встраиваться явно. Без неё SENAR превращается в инструмент быстрой генерации формально-корректного, но фактически неверного кода.

Высокая конкурентность и системы реального времени.Многопоточность, race conditions, distributed consensus, мягкая согласованность (eventual consistency). Класс задач, где дефект не воспроизводится по команде: он всплывает редко, по сложному стечению обстоятельств. У меня такой случай был на проекте в закрытом тесте, в очереди обогащения данных из внешних источников. Архитектура была корректна по описанию, тесты проходили, ревью прошло, на тестовом окружении всё работало. На проде через пару дней появились двойные записи у некоторых пользователей. Гонку между двумя потоками обогащения, которые в редких условиях одновременно претендовали на одну запись, обнаружили только по жалобе из техподдержки.

Базовый чеклист верификации из SENAR Core плохо ловит такие дефекты: в нём нет обязательного стресс- и нагрузочного контура на уровне процесса. L3-ревью каноном помогает, но недостаточно: независимый агент тоже работает с описанием системы, а гонка появляется только под нагрузкой и при определённом таймлайне. Сюда нужны другие инструменты: chaos testing, нагрузочное тестирование с воспроизведением реальных паттернов, property-based тесты, формальная верификация для критичных мест. Это вторая нормативная надстройка над SENAR, которой у меня пока нет, и я не уверен, что она в принципе хорошо ложится на агентный процесс. Открытый вопрос: как автоматически отличить задачу, которая требует расширенного тестирования, от задачи, которая обходится QG-2.

Пять категорий выше идут по убыванию частоты, с которой я с ними сталкивался; по важности порядок был бы другим. Объединяет их одно: в каждой из них дефект не ловится тем механизмом, который сделан под основную массу задач. Либо требования формализуются плохо, либо ответственность не делегируется одному человеку, либо контекст распылён настолько, что собрать его дороже, чем работать без агента. SENAR не претендует на покрытие этих случаев. Это рамка для основной массы инженерной работы, не универсальный инструмент.

Что ломается при переходе на команду

Дальше про границу, которую я не пересёк сам.

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

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

Лечится переоформлением каждой записи под коллективное чтение, и это отдельная работа, которую я только начинал. Каждыйdead_endдолжен содержать достаточно контекста, чтобы новый ИИ-инженер мог его прочитать как самостоятельный документ, без обращения к автору. Каждыйpatternдолжен быть привязан не только к классу задач, но и к обоснованию: почему именно этот чертёж, какие альтернативы рассматривались. На объёме памяти, который у меня накопился за полтора года, это месяцы работы. Я её пока не начинал в полную силу, и здесь я честен: моя память остаётся читаемой только мной.

Риск единственного носителя знаний.Это вытекает из предыдущего, но шире. Ячейка из одного ИИ-инженера и набора агентов даёт кратный выигрыш по скорости, но bus factor у такой структуры жёстко равен единице. Если ИИ-инженер ушёл, проект встал. База знаний и документация смягчают, не устраняют. Я не нашёл способа полностью устранить этот риск, не потеряв главное преимущество ячейки, скорость. Возможно, парная ячейка с двумя ИИ-инженерами, которые работают над разными модулями, но читают чужую память каждый день, частично закрывает риск. Возможно, не закрывает. У меня этого опыта нет.

Координация между ячейками, когда их становится несколько.Когда в проекте становится десять-пятнадцать человек, ИИ-инженеров оказывается больше одного, и появляется задача координации. Канон SENAR описывает её для конфигураций Team и Enterprise, в которые внесены дополнительные роли, метрики, церемонии. Это направление развития, но именно как направление, не как проверенная мной практика. Гипотеза, к которой я пришёл, ближе всего к федерации ячеек по принципу микросервисов для людей: каждая ячейка автономна, координация идёт через явные API-контракты и общую базу знаний. Со всеми известными проблемами микросервисов: знания расходятся со временем, отладка тупиков распределена между командами, спор о том, кто сломал общий контракт. Парная ячейка из двух человек выглядит компромиссным минимумом, но и его я не проверил настолько, чтобы рекомендовать.

RENAR как нормативный слой над требованиями.Один конкретный кусок этой командной перестройки собираю отдельно. Когда агенты производят не только код, но и артефакты требований, нужен нормативный слой жизненного цикла: иерархия BR / SR / TR, типы SPEC, ADAPT. Подробнее — в разделе «Что лежит рядом с SENAR» ниже; сейчас это черновик 0.1-draft наrenar.tech.

В сумме это самая честная граница серии. SENAR работает в ячейке. На переходе к команде он требует доработки, часть которой я только начал, а часть пока существует как гипотеза.

Одна ячейка собирается чисто, попытка собрать вторую такую же ровно по образцу первой даёт неплотные стыки. Образец недостаточно описан, чтобы воспроизводиться без автора.

Что я до сих пор не знаю

Третий слой границ: вопросы, на которые у меня нет ответа после полутора лет работы.

Масштаб 50 и больше ИИ-инженеров на одной кодовой базе.Все мои проекты были одной ячейкой или, в редких случаях, парой ячеек на разных модулях. Что происходит, когда ИИ-инженеров пятьдесят, а ячеек, возможно, и больше, потому что ИИ-инженер может вести несколько проектов параллельно. Как разрешается конфликт памяти, когда одинdead_endзафиксирован в одном проекте, а в соседнем тот же подход оказался работающим. Как федерация ячеек ведёт себя на длинной дистанции, когда у каждой ячейки накапливается своя локальная история, и часть истории становится несовместимой с историей соседей. В каноне SENAR это описано как федерация (Federation), на уровне принципов, но проверенной практики у меня нет.

Длинная дистанция, три года и больше.Это вопрос, который меня беспокоит больше остальных. Сейчас я ещё помню, как устроены модули, которые агент собирал полгода назад. Я помню, почему именно эта структура данных, почему именно этот паттерн обработки ошибок, какие альтернативы рассматривались и были отвергнуты. Через три года? Через пять?

База знаний фиксирует решения, но не фиксирует контекст принятия этих решений целиком. Записать всё нельзя, накладные расходы станут неподъёмными, и память превратится из инструмента в дисциплинарную обязанность, которую все начнут саботировать. Сколько именно записывать, я до сих пор не понял. Есть подозрение, что через три-четыре года проект на 100% ИИ-разработке окажется в ситуации, очень похожей на классический legacy без документации: формально документация есть, неявного знания, которое делает её полезной, уже нет ни у кого. Это и есть кумулятивный когнитивный долг, о котором писал вовторой статье. Текущий MIR держится низким, но это снимок состояния, не прогноз на пять лет: низкий MIR сейчас не гарантирует отсутствие этого долга через годы.

Экономика при изменении цен на API.Соотношение стоимости агентной разработки к ручной держится в диапазоне 1:10–1:20, по оценке из рабочего журнала, без контрольной группы. Задача на два-три дня руками закрывается за пару часов с обвязкой SENAR. Это провремя и деньги в целом, не про отдельный счёт токенов.

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

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

В сумме на проекте падает не только цена хода, но и число лишних итераций: меньше повторных прогонов, меньше переделок из-за потерянного контекста. Именно это и даёт экономику на большой подписке (фиксированный лимит, корпоративный план, Max/Team у Anthropic): можно работать плотно, не считая каждый ход. На оплате по факту с жёстким потолком тот же процесс может не сойтись, даже если соотношение 1:10 по времени выглядит убедительно.

Провайдеры меняют тарифы когда захотят; на это повлиять нельзя. Если цены вырастут и соотношение сожмётся до 1:3 или 1:2, методология останется применимой, но экономическое обоснование изменится. Фиксирую границу: то, что сходится по деньгам сегодня, завтра может перестать; это внешнее условие, не баг SENAR.

Что лежит рядом с SENAR

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

SENAR— методология: что должно быть в работе с агентами. Открытая, лицензия CC BY-SA 4.0, полные тексты наsenar.tech. Соавтор:Вадим Соглаев. Включает восемь правил, два шлюза качества в Core-конфигурации (QG-0 и QG-2), пять шлюзов в полном Standard (QG-0..QG-4), типизированную память проекта, метрики FPSR, MIR и DER, чеклист верификации из 28 пунктов. Это описание процесса, не реализация.

TAUSIK(Task Agent Unified Supervision, Inspection & Knowledge)— реализация SENAR с открытым кодом. Среда, в которой правила исполняются: хуки блокируют код без активной задачи, ворота QG-0 и QG-2 не дают закрыть задачу без проверки, типизированная память и двадцать пять проверок качества с учётом стека встроены в рабочий цикл. Лицензия Apache 2.0, код наGitHub, документация наtausik.tech. На моих проектах работает в продакшене; рассчитан на одну ячейку или пару.

RENAR— самостоятельный нормативный стандарт инженерии требований, совместимый со SENAR. Отвечает на вопрос: как требования, спецификации и тест-кейсы живут в проекте, когда ИИ-инженеров больше одного и когда агенты производят код и сами артефакты требований. Иерархия BR / SR / TR, девять типов SPEC, ADAPT, парность позитивных и негативных тест-кейсов, версионирование без привязки к git; шесть возможностей субстрата (V1–V6) описывают правила независимо от хранилища. Лицензия CC BY-SA 4.0. Соавтор:Вадим Соглаев. Сейчас черновик 0.1-draft: тексты иrenar.tech(сайт в проработке, не финальная редакция). Реализация будет в TAUSIK, как только нормативка устаканится.

Три части отвечают на три вопроса: SENAR (что делать), TAUSIK (на чём поднимать), RENAR (как нормировать требования, когда ячейка превращается в команду). Это готовые открытые стандарты и инструмент. Если что-то в тексте стандарта или в коде TAUSIK кажется слабым местом, пишите в issues на GitHub: что улучшить, что вынести в следующую ревизию, где формулировка не держит практику.

Если унести из всей серии одну мысль

Серия закрывается не на тезисе, что SENAR решает всё. Она закрывается на другом утверждении: вот рамка, в которой я её проверил, и вот границы.

Контур задачи с воротами на входе и выходе, среда задачи между ними из контекста, архитектурных границ и типизированной памяти, и метрики, которые показывают, что в контуре провисает. Две инженерные конструкции, которые в сумме держат работу с агентом на уровне, на котором MIR и DER устойчиво низкие, FPSR устойчиво высокий, и по журналу за плотный день закрывается 8–12 задач без накопления когнитивного долга. Вот вся рамка, которую я для себя зафиксировал.

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

SENAR, RENAR и TAUSIK открыты как готовые стандарты и инструмент, которые можно проверить в своей практике. Если рамка ломается там, где у меня не ломалась, всем нам это полезнее, чем если она везде работает одинаково.

На этом шестичастную серию про SENAR закрываю.

Что дальше

Следующий небольшой цикл проTAUSIK: как SENAR держится в коде, а не в PDF. В начале лета планируюверсию 2.0; сейчас в продакшене 1.4.x. В мае прошёл независимый аудит всей экосистемы: шесть параллельных аналитиков, три продукта, тридцать с лишним конкурентов, сорок мировых стандартов. Выводы легли в план релизов.

В черновике аудита методологическая работа получила высокую оценку по нормативной дисциплине: RFC 2119, закрытые списки, обязательные пункты, отрицательные доказательства в RENAR. Такой язык в AI-разработке почти никто не использует; рынок до сих пор живёт советами вAGENTS.md. SENAR, RENAR и TAUSIK вместе задуманы как пред-стандарт с переводом в исполняемые правила вместо очередного списка принципов.

TAUSIK— единственное место в экосистеме, где правила SENAR принудительны. Агент не пишет код без активной задачи: блокирует хук. Задача не закрывается без свежей верификации:task doneчитает кэш проверки за последние десять минут и сверяет хеш файлов с diff. Среди тридцати с лишним изученных продуктов аналогов не нашли; это исполняемый контракт.

Технически: двадцать пять проверок качества с учётом стека, память с полнотекстовым поиском и графом связей, учёт тупиков, шесть метрик SENAR по канону наsenar.techплюс стоимость задачи, лимит сессии по реальному времени работы, параллельное ревью шестью агентами, ~3400 тестов на Python stdlib без core-зависимостей, соотношение тестов к исходникам 1,4×. FPSR на отдельных проектах с полной обвязкой доходит до 90% и выше; это верх диапазона, не среднее по всем тридцати с лишним.

Слабые места аудит назвал без скидок: RENAR внутри TAUSIK пока на ~20%, два правила из восьми не реализованы (External Validation и Rollback Planning), одно только предупреждением; документация периодически отстаёт от кода. План 2.0 построен на этих пробелах.

В 2.0:примитивы RENAR (журнал рассуждений на задачу, воспроизведение решения с фиксацией модели, цепочка происхождения артефактов), изоляция контекста при работе нескольких агентов, план отката в QG-0, поддержка Cursor и других IDE, внешняя верификация на другой модели для сложных задач. Слой дисциплины, который не даёт агенту врать «готово» и режет лишние токены там, где подписка позволяет работать плотно.

Что было бы полезно от читателей

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

• SENAR Core за пределами моего стека.У меня в основном TypeScript и Python, бэкенд и инфраструктура. Опыт на mobile, embedded, data science, low-level графике, ML-пайплайнах не валидировал. Если конструкция ворот и среды там разваливается, нужен конкретный эпизод, не общая критика.
• FPSR и DER из независимых проектов.Мои значения собраны на моих проектах с моим набором привычек. Базовая линия из чужой команды, другой класс данных; она нужна, чтобы откалибровать ориентиры.
• Масштабирование на команду больше пяти ИИ-инженеров.Такой команды в действии не видел. Если кто-то пробует сейчас, разбор реальных швов на переходе ценнее любых гипотез про федерацию ячеек.
• Критика пяти наблюдений из второй статьи.Что пропустил, что переформулировал так, что потерял резкость, что добавил, а в чужом опыте не встречается.
• Альтернативы там, где у меня слабо:коллективное чтение памяти, длинная дистанция, регулируемые отрасли. Рабочая модель, которая закрывает один из этих швов лучше моей, нужнее подтверждения того, что и так уже знаю.

Если после шести статей про границы методологии интереснее посмотреть,какона держится в коде, цикл про TAUSIK начнётся через несколько недель после публикации этой статьи.

Словарь терминов

SENAR(от английского Supervised Engineering & Normative AI Regulation, контролируемая инженерия и нормативное регулирование ИИ). Открытая методология инженерной работы с ИИ-агентами при разработке. Лицензия CC BY-SA 4.0. Полные тексты наsenar.tech. Соавтор:Вадим Соглаев.

TAUSIK(от английского Task Agent Unified Supervision, Inspection & Knowledge). Реализация SENAR с открытым кодом: хуки, ворота качества, метрики, типизированная память, ~3400 тестов. Лицензия Apache 2.0. Репозиторий:github.com/Kibertum/tausik-core, документация:tausik.tech.

RENAR(от английского Requirements Engineering & Normative Adaptive Regulation). Самостоятельный нормативный стандарт инженерии требований, совместимый со SENAR и работающий независимо. Иерархия BR / SR / TR, девять типов SPEC, ADAPT, тест-кейсы как полноценные артефакты, версионирование без привязки к конкретному хранилищу (шесть возможностей субстрата V1–V6). Лицензия CC BY-SA 4.0. Соавтор:Вадим Соглаев. Сейчас черновик 0.1-draft наrenar.tech(сайт в проработке). Реализация планируется в TAUSIK.

Ячейка.Производственная единица из одного человека (ИИ-инженера), набора ИИ-агентов и среды задачи (контекст, архитектурные границы, типизированная память). Заменяет классическую команду со специализациями по слоям как основную единицу ИИ-нативной разработки. Роль человека в такой единице разбирал втретьей статье серии; термин «ячейка» ввожу здесь.

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

Среда задачи.Авторская рабочая категория пятой статьи: то, в чём агент работает между QG-0 и QG-2. Состоит из трёх слоёв: контекст под задачу, архитектурные границы, типизированная память проекта.

Bus factor.Минимальное число людей в проекте, чьё одновременное выпадение остановит работу. В модели одной ячейки равен единице по построению, что является основным системным риском.

FPSR / MIR / DER / ERR.Метрики SENAR. FPSR (First-Pass Success Rate): доля задач, решённых с первой попытки. MIR (Manual Intervention Rate): доля задач, в которых потребовалась ручная правка кода; подробнее вовторой статье. DER (Dead End Rate): доля времени и попыток, ушедших в тупиковые ветки; подробнее вчетвёртойипятойстатьях. ERR (Escape Rate): доля задач, где дефект проявился после закрытия; впервой статьета же аббревиатура DER означала Defect Escape Rate, с четвёртой части это значение перешло в ERR.

L3, adversarial-ревью.Уровень независимой проверки в полном каноне SENAR: отдельный агент перепроверяет результат, не имея доступа к рассуждениям того, кто его получил. В предыдущих статьях серии не разбирался; здесь упомянут как механизм, ближайший к независимой проверке в смысле регуляторов. Подробно в каноне наsenar.tech.

Ворота качества, спецификация задачи.Подробно разобраны вчетвёртой статье серии.

Серия про инженерный процесс для разработки с ИИ-агентами:

• Часть 1:Полтора года без ручного кода: почему инструкции ИИ-агенту не заменяют инженерную дисциплину
• Часть 2:ИИ-агент не программист: пять наблюдений и три следствия
• Часть 3:Если агент пишет код, то кем становится человек?
• Часть 4:Спецификация, ворота, метрики: как SENAR закрывает вход и выход задачи
• Часть 5:Среда агента: контекст, архитектурные границы, память проекта
• Часть 6:Чего я не закрыл: границы 100% разработки с агентами

Кому это в принципе не подходит

Начну с оговорки, которую стоило сделать ещё в первой статье; я жалею, что не сделал.

SENAR собирался под опытного инженера, который уже умеет строить софт и хочет структурированный процесс работы с агентами. Под того, кто способен декомпозировать задачу до уровня агента, спроектировать архитектурную границу, увидеть тонкий баг в сгенерированном коде, отличить тест, проверяющий поведение, от теста, повторяющего реализацию. Без этих навыков ворота качества из четвёртой статьи превращаются в ритуал: формально QG-0 пройден, спецификация заполнена, критерии приёмки перечислены, всё мимо.

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

Методология не заменяет инженерную базу. Она работает поверх неё.

Где это не работает

Дальше про области, в которых конструкция из пяти предыдущих статей не доводит до результата вне зависимости от того, насколько хорошо вы её освоили. В концечетвёртой статьия обещал вернуться к незнакомому домену, деградации архитектуры и переносу на команду; ниже пять категорий с разными механизмами отказа, часть из них перекрывается с теми обещаниями.

Регулируемые отрасли.Медицина по IEC 62304, финансы под SOX, авиация под DO-178C. Регуляторов объединяет требование ответственности и прослеживаемости: решение принимает и отвечает за него конкретный человек с подтверждённой квалификацией, не модель. SENAR даёт трассируемость, каждое требование привязано к задаче, каждая задача к коду, каждое решение зафиксировано. Это близко к тому, что хочет аудитор, но не равно. Аудитор смотрит на ответственного за модуль; одна трассируемость документов вопрос не закрывает. Ответ в стилеагент сгенерировал по спецификации, человек верифицировал по чеклистуработает только если в журнале аудита человек берёт на себя ответственность за результат, а не ИИ. И тогда экономия от агентной разработки съедается стоимостью верификации, которая по факту становится плотнее, чем была бы у инженера, пишущего код руками.

В финансовом контуре есть отдельная проблема. SOX требует разделения обязанностей: тот, кто пишет код, не имеет права его проверять. А в модели одной ячейки одинИИ-инженери набор агентов, как я описывал роль человека втретьей статье, и код, и его проверку делает один и тот же человек. Формально L3 adversarial-ревью канона SENAR (независимый агент без доступа к рассуждениям первого) подходит под определение независимой проверки, но примет ли это аудитор как разделение обязанностей в смысле SOX, открытый вопрос. По моему опыту разговоров с аудиторами, ответ скорее отрицательный, пока регуляторная база не подстроится явно. А подстраивается она годами.

Это не значит, что в регулируемых отраслях ИИ-разработка бесполезна. Гибридная модель работает: агент генерирует код, инженер верифицирует и подписывается под результатом, журнал аудита называет именно инженера. SENAR с его трассируемостью ближе к тому, что нужно аудитору, чем неструктурированная разработка. Но 100% делегирование, как у меня на закрытом тестовом проекте, тут невозможно.

Глубокий R&D без критериев приёмки.Если задачу нельзя сформулировать в критериях приёмки до начала работы, это не задача в смысле SENAR, а исследование. У меня есть несколько таких случаев: разобраться, годится ли определённый алгоритм машинного обучения для нашего класса задач; понять, насколько определённый сторонний сервис стабилен под нагрузкой; найти, где в системе теряется производительность под профайлером.

В каждом из этих случаев QG-0 нельзя пройти честно. Критерии приёмки нечего написать, потому что результат заранее неизвестен. Можно их выдумать, и тогда задача формально открывается, но это самообман: критерии не привязаны к реальной цели, верификация на выходе ничего не значит.

Лечится разделением. Сначала человек проводит исследование как исследование, без агента или с агентом в режиме помощника по чтению, без обязательства закрывать задачу с критериями. По результатам появляется понимание, что должно получиться. Только после этого формируется задача с критериями приёмки, и она уже передаётся в обычный SENAR-контур. У меня от исследовательской фазы до фазы реализации обычно неделя-две, и эти две недели я работаю как инженер до агентной эры, со всеми её ограничениями.

Глубокий legacy без живого носителя контекста.Система на миллион строк, документации нет, авторы ушли. Контекст под задачу собирать неоткуда: код не самоописывается на нужном уровне, неявных договорённостей много, и они известны только тем, кого уже нет. Агент может вычитать архитектуру по коду, но эта восстановленная архитектура правдоподобна, не настоящая. Подсветить разницу нечем, носителей нет.

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

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

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

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

Рабочая модель здесь следующая: доменный эксперт валидирует спецификацию до начала работы, код — нет. На русском языке, со всеми привычными для эксперта оборотами. Проверить Python-код бухгалтер не может, проверить текстовое описание налоговой логики бухгалтер может. Это другая работа эксперта, и она в работу ячейки должна встраиваться явно. Без неё SENAR превращается в инструмент быстрой генерации формально-корректного, но фактически неверного кода.

Высокая конкурентность и системы реального времени.Многопоточность, race conditions, distributed consensus, мягкая согласованность (eventual consistency). Класс задач, где дефект не воспроизводится по команде: он всплывает редко, по сложному стечению обстоятельств. У меня такой случай был на проекте в закрытом тесте, в очереди обогащения данных из внешних источников. Архитектура была корректна по описанию, тесты проходили, ревью прошло, на тестовом окружении всё работало. На проде через пару дней появились двойные записи у некоторых пользователей. Гонку между двумя потоками обогащения, которые в редких условиях одновременно претендовали на одну запись, обнаружили только по жалобе из техподдержки.

Базовый чеклист верификации из SENAR Core плохо ловит такие дефекты: в нём нет обязательного стресс- и нагрузочного контура на уровне процесса. L3-ревью каноном помогает, но недостаточно: независимый агент тоже работает с описанием системы, а гонка появляется только под нагрузкой и при определённом таймлайне. Сюда нужны другие инструменты: chaos testing, нагрузочное тестирование с воспроизведением реальных паттернов, property-based тесты, формальная верификация для критичных мест. Это вторая нормативная надстройка над SENAR, которой у меня пока нет, и я не уверен, что она в принципе хорошо ложится на агентный процесс. Открытый вопрос: как автоматически отличить задачу, которая требует расширенного тестирования, от задачи, которая обходится QG-2.

Пять категорий выше идут по убыванию частоты, с которой я с ними сталкивался; по важности порядок был бы другим. Объединяет их одно: в каждой из них дефект не ловится тем механизмом, который сделан под основную массу задач. Либо требования формализуются плохо, либо ответственность не делегируется одному человеку, либо контекст распылён настолько, что собрать его дороже, чем работать без агента. SENAR не претендует на покрытие этих случаев. Это рамка для основной массы инженерной работы, не универсальный инструмент.

Что ломается при переходе на команду

Дальше про границу, которую я не пересёк сам.

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

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

Лечится переоформлением каждой записи под коллективное чтение, и это отдельная работа, которую я только начинал. Каждыйdead_endдолжен содержать достаточно контекста, чтобы новый ИИ-инженер мог его прочитать как самостоятельный документ, без обращения к автору. Каждыйpatternдолжен быть привязан не только к классу задач, но и к обоснованию: почему именно этот чертёж, какие альтернативы рассматривались. На объёме памяти, который у меня накопился за полтора года, это месяцы работы. Я её пока не начинал в полную силу, и здесь я честен: моя память остаётся читаемой только мной.

Риск единственного носителя знаний.Это вытекает из предыдущего, но шире. Ячейка из одного ИИ-инженера и набора агентов даёт кратный выигрыш по скорости, но bus factor у такой структуры жёстко равен единице. Если ИИ-инженер ушёл, проект встал. База знаний и документация смягчают, не устраняют. Я не нашёл способа полностью устранить этот риск, не потеряв главное преимущество ячейки, скорость. Возможно, парная ячейка с двумя ИИ-инженерами, которые работают над разными модулями, но читают чужую память каждый день, частично закрывает риск. Возможно, не закрывает. У меня этого опыта нет.

Координация между ячейками, когда их становится несколько.Когда в проекте становится десять-пятнадцать человек, ИИ-инженеров оказывается больше одного, и появляется задача координации. Канон SENAR описывает её для конфигураций Team и Enterprise, в которые внесены дополнительные роли, метрики, церемонии. Это направление развития, но именно как направление, не как проверенная мной практика. Гипотеза, к которой я пришёл, ближе всего к федерации ячеек по принципу микросервисов для людей: каждая ячейка автономна, координация идёт через явные API-контракты и общую базу знаний. Со всеми известными проблемами микросервисов: знания расходятся со временем, отладка тупиков распределена между командами, спор о том, кто сломал общий контракт. Парная ячейка из двух человек выглядит компромиссным минимумом, но и его я не проверил настолько, чтобы рекомендовать.

RENAR как нормативный слой над требованиями.Один конкретный кусок этой командной перестройки собираю отдельно. Когда агенты производят не только код, но и артефакты требований, нужен нормативный слой жизненного цикла: иерархия BR / SR / TR, типы SPEC, ADAPT. Подробнее — в разделе «Что лежит рядом с SENAR» ниже; сейчас это черновик 0.1-draft наrenar.tech.

В сумме это самая честная граница серии. SENAR работает в ячейке. На переходе к команде он требует доработки, часть которой я только начал, а часть пока существует как гипотеза.

Одна ячейка собирается чисто, попытка собрать вторую такую же ровно по образцу первой даёт неплотные стыки. Образец недостаточно описан, чтобы воспроизводиться без автора.

Что я до сих пор не знаю

Третий слой границ: вопросы, на которые у меня нет ответа после полутора лет работы.

Масштаб 50 и больше ИИ-инженеров на одной кодовой базе.Все мои проекты были одной ячейкой или, в редких случаях, парой ячеек на разных модулях. Что происходит, когда ИИ-инженеров пятьдесят, а ячеек, возможно, и больше, потому что ИИ-инженер может вести несколько проектов параллельно. Как разрешается конфликт памяти, когда одинdead_endзафиксирован в одном проекте, а в соседнем тот же подход оказался работающим. Как федерация ячеек ведёт себя на длинной дистанции, когда у каждой ячейки накапливается своя локальная история, и часть истории становится несовместимой с историей соседей. В каноне SENAR это описано как федерация (Federation), на уровне принципов, но проверенной практики у меня нет.

Длинная дистанция, три года и больше.Это вопрос, который меня беспокоит больше остальных. Сейчас я ещё помню, как устроены модули, которые агент собирал полгода назад. Я помню, почему именно эта структура данных, почему именно этот паттерн обработки ошибок, какие альтернативы рассматривались и были отвергнуты. Через три года? Через пять?

База знаний фиксирует решения, но не фиксирует контекст принятия этих решений целиком. Записать всё нельзя, накладные расходы станут неподъёмными, и память превратится из инструмента в дисциплинарную обязанность, которую все начнут саботировать. Сколько именно записывать, я до сих пор не понял. Есть подозрение, что через три-четыре года проект на 100% ИИ-разработке окажется в ситуации, очень похожей на классический legacy без документации: формально документация есть, неявного знания, которое делает её полезной, уже нет ни у кого. Это и есть кумулятивный когнитивный долг, о котором писал вовторой статье. Текущий MIR держится низким, но это снимок состояния, не прогноз на пять лет: низкий MIR сейчас не гарантирует отсутствие этого долга через годы.

Экономика при изменении цен на API.Соотношение стоимости агентной разработки к ручной держится в диапазоне 1:10–1:20, по оценке из рабочего журнала, без контрольной группы. Задача на два-три дня руками закрывается за пару часов с обвязкой SENAR. Это провремя и деньги в целом, не про отдельный счёт токенов.

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

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

В сумме на проекте падает не только цена хода, но и число лишних итераций: меньше повторных прогонов, меньше переделок из-за потерянного контекста. Именно это и даёт экономику на большой подписке (фиксированный лимит, корпоративный план, Max/Team у Anthropic): можно работать плотно, не считая каждый ход. На оплате по факту с жёстким потолком тот же процесс может не сойтись, даже если соотношение 1:10 по времени выглядит убедительно.

Провайдеры меняют тарифы когда захотят; на это повлиять нельзя. Если цены вырастут и соотношение сожмётся до 1:3 или 1:2, методология останется применимой, но экономическое обоснование изменится. Фиксирую границу: то, что сходится по деньгам сегодня, завтра может перестать; это внешнее условие, не баг SENAR.

Что лежит рядом с SENAR

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

SENAR— методология: что должно быть в работе с агентами. Открытая, лицензия CC BY-SA 4.0, полные тексты наsenar.tech. Соавтор:Вадим Соглаев. Включает восемь правил, два шлюза качества в Core-конфигурации (QG-0 и QG-2), пять шлюзов в полном Standard (QG-0..QG-4), типизированную память проекта, метрики FPSR, MIR и DER, чеклист верификации из 28 пунктов. Это описание процесса, не реализация.

TAUSIK(Task Agent Unified Supervision, Inspection & Knowledge)— реализация SENAR с открытым кодом. Среда, в которой правила исполняются: хуки блокируют код без активной задачи, ворота QG-0 и QG-2 не дают закрыть задачу без проверки, типизированная память и двадцать пять проверок качества с учётом стека встроены в рабочий цикл. Лицензия Apache 2.0, код наGitHub, документация наtausik.tech. На моих проектах работает в продакшене; рассчитан на одну ячейку или пару.

RENAR— самостоятельный нормативный стандарт инженерии требований, совместимый со SENAR. Отвечает на вопрос: как требования, спецификации и тест-кейсы живут в проекте, когда ИИ-инженеров больше одного и когда агенты производят код и сами артефакты требований. Иерархия BR / SR / TR, девять типов SPEC, ADAPT, парность позитивных и негативных тест-кейсов, версионирование без привязки к git; шесть возможностей субстрата (V1–V6) описывают правила независимо от хранилища. Лицензия CC BY-SA 4.0. Соавтор:Вадим Соглаев. Сейчас черновик 0.1-draft: тексты иrenar.tech(сайт в проработке, не финальная редакция). Реализация будет в TAUSIK, как только нормативка устаканится.

Три части отвечают на три вопроса: SENAR (что делать), TAUSIK (на чём поднимать), RENAR (как нормировать требования, когда ячейка превращается в команду). Это готовые открытые стандарты и инструмент. Если что-то в тексте стандарта или в коде TAUSIK кажется слабым местом, пишите в issues на GitHub: что улучшить, что вынести в следующую ревизию, где формулировка не держит практику.

Если унести из всей серии одну мысль

Серия закрывается не на тезисе, что SENAR решает всё. Она закрывается на другом утверждении: вот рамка, в которой я её проверил, и вот границы.

Контур задачи с воротами на входе и выходе, среда задачи между ними из контекста, архитектурных границ и типизированной памяти, и метрики, которые показывают, что в контуре провисает. Две инженерные конструкции, которые в сумме держат работу с агентом на уровне, на котором MIR и DER устойчиво низкие, FPSR устойчиво высокий, и по журналу за плотный день закрывается 8–12 задач без накопления когнитивного долга. Вот вся рамка, которую я для себя зафиксировал.

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

SENAR, RENAR и TAUSIK открыты как готовые стандарты и инструмент, которые можно проверить в своей практике. Если рамка ломается там, где у меня не ломалась, всем нам это полезнее, чем если она везде работает одинаково.

На этом шестичастную серию про SENAR закрываю.

Что дальше

Следующий небольшой цикл проTAUSIK: как SENAR держится в коде, а не в PDF. В начале лета планируюверсию 2.0; сейчас в продакшене 1.4.x. В мае прошёл независимый аудит всей экосистемы: шесть параллельных аналитиков, три продукта, тридцать с лишним конкурентов, сорок мировых стандартов. Выводы легли в план релизов.

В черновике аудита методологическая работа получила высокую оценку по нормативной дисциплине: RFC 2119, закрытые списки, обязательные пункты, отрицательные доказательства в RENAR. Такой язык в AI-разработке почти никто не использует; рынок до сих пор живёт советами вAGENTS.md. SENAR, RENAR и TAUSIK вместе задуманы как пред-стандарт с переводом в исполняемые правила вместо очередного списка принципов.

TAUSIK— единственное место в экосистеме, где правила SENAR принудительны. Агент не пишет код без активной задачи: блокирует хук. Задача не закрывается без свежей верификации:task doneчитает кэш проверки за последние десять минут и сверяет хеш файлов с diff. Среди тридцати с лишним изученных продуктов аналогов не нашли; это исполняемый контракт.

Технически: двадцать пять проверок качества с учётом стека, память с полнотекстовым поиском и графом связей, учёт тупиков, шесть метрик SENAR по канону наsenar.techплюс стоимость задачи, лимит сессии по реальному времени работы, параллельное ревью шестью агентами, ~3400 тестов на Python stdlib без core-зависимостей, соотношение тестов к исходникам 1,4×. FPSR на отдельных проектах с полной обвязкой доходит до 90% и выше; это верх диапазона, не среднее по всем тридцати с лишним.

Слабые места аудит назвал без скидок: RENAR внутри TAUSIK пока на ~20%, два правила из восьми не реализованы (External Validation и Rollback Planning), одно только предупреждением; документация периодически отстаёт от кода. План 2.0 построен на этих пробелах.

В 2.0:примитивы RENAR (журнал рассуждений на задачу, воспроизведение решения с фиксацией модели, цепочка происхождения артефактов), изоляция контекста при работе нескольких агентов, план отката в QG-0, поддержка Cursor и других IDE, внешняя верификация на другой модели для сложных задач. Слой дисциплины, который не даёт агенту врать «готово» и режет лишние токены там, где подписка позволяет работать плотно.

Что было бы полезно от читателей

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

• SENAR Core за пределами моего стека.У меня в основном TypeScript и Python, бэкенд и инфраструктура. Опыт на mobile, embedded, data science, low-level графике, ML-пайплайнах не валидировал. Если конструкция ворот и среды там разваливается, нужен конкретный эпизод, не общая критика.
• FPSR и DER из независимых проектов.Мои значения собраны на моих проектах с моим набором привычек. Базовая линия из чужой команды, другой класс данных; она нужна, чтобы откалибровать ориентиры.
• Масштабирование на команду больше пяти ИИ-инженеров.Такой команды в действии не видел. Если кто-то пробует сейчас, разбор реальных швов на переходе ценнее любых гипотез про федерацию ячеек.
• Критика пяти наблюдений из второй статьи.Что пропустил, что переформулировал так, что потерял резкость, что добавил, а в чужом опыте не встречается.
• Альтернативы там, где у меня слабо:коллективное чтение памяти, длинная дистанция, регулируемые отрасли. Рабочая модель, которая закрывает один из этих швов лучше моей, нужнее подтверждения того, что и так уже знаю.

Если после шести статей про границы методологии интереснее посмотреть,какона держится в коде, цикл про TAUSIK начнётся через несколько недель после публикации этой статьи.

Словарь терминов

SENAR(от английского Supervised Engineering & Normative AI Regulation, контролируемая инженерия и нормативное регулирование ИИ). Открытая методология инженерной работы с ИИ-агентами при разработке. Лицензия CC BY-SA 4.0. Полные тексты наsenar.tech. Соавтор:Вадим Соглаев.

TAUSIK(от английского Task Agent Unified Supervision, Inspection & Knowledge). Реализация SENAR с открытым кодом: хуки, ворота качества, метрики, типизированная память, ~3400 тестов. Лицензия Apache 2.0. Репозиторий:github.com/Kibertum/tausik-core, документация:tausik.tech.

RENAR(от английского Requirements Engineering & Normative Adaptive Regulation). Самостоятельный нормативный стандарт инженерии требований, совместимый со SENAR и работающий независимо. Иерархия BR / SR / TR, девять типов SPEC, ADAPT, тест-кейсы как полноценные артефакты, версионирование без привязки к конкретному хранилищу (шесть возможностей субстрата V1–V6). Лицензия CC BY-SA 4.0. Соавтор:Вадим Соглаев. Сейчас черновик 0.1-draft наrenar.tech(сайт в проработке). Реализация планируется в TAUSIK.

Ячейка.Производственная единица из одного человека (ИИ-инженера), набора ИИ-агентов и среды задачи (контекст, архитектурные границы, типизированная память). Заменяет классическую команду со специализациями по слоям как основную единицу ИИ-нативной разработки. Роль человека в такой единице разбирал втретьей статье серии; термин «ячейка» ввожу здесь.

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

Среда задачи.Авторская рабочая категория пятой статьи: то, в чём агент работает между QG-0 и QG-2. Состоит из трёх слоёв: контекст под задачу, архитектурные границы, типизированная память проекта.

Bus factor.Минимальное число людей в проекте, чьё одновременное выпадение остановит работу. В модели одной ячейки равен единице по построению, что является основным системным риском.

FPSR / MIR / DER / ERR.Метрики SENAR. FPSR (First-Pass Success Rate): доля задач, решённых с первой попытки. MIR (Manual Intervention Rate): доля задач, в которых потребовалась ручная правка кода; подробнее вовторой статье. DER (Dead End Rate): доля времени и попыток, ушедших в тупиковые ветки; подробнее вчетвёртойипятойстатьях. ERR (Escape Rate): доля задач, где дефект проявился после закрытия; впервой статьета же аббревиатура DER означала Defect Escape Rate, с четвёртой части это значение перешло в ERR.

L3, adversarial-ревью.Уровень независимой проверки в полном каноне SENAR: отдельный агент перепроверяет результат, не имея доступа к рассуждениям того, кто его получил. В предыдущих статьях серии не разбирался; здесь упомянут как механизм, ближайший к независимой проверке в смысле регуляторов. Подробно в каноне наsenar.tech.

Ворота качества, спецификация задачи.Подробно разобраны вчетвёртой статье серии.

Серия про инженерный процесс для разработки с ИИ-агентами:

• Часть 1:Полтора года без ручного кода: почему инструкции ИИ-агенту не заменяют инженерную дисциплину
• Часть 2:ИИ-агент не программист: пять наблюдений и три следствия
• Часть 3:Если агент пишет код, то кем становится человек?
• Часть 4:Спецификация, ворота, метрики: как SENAR закрывает вход и выход задачи
• Часть 5:Среда агента: контекст, архитектурные границы, память проекта
• Часть 6:Чего я не закрыл: границы 100% разработки с агентами