Основы SENAR
8 правил для AI-разработки
Версия: 1.3 | Дата: 2026-03-25 Авторы: Андрей Юмашев (Andrey Yumashev), Вадим Соглаев (Vadim Soglaev) Copyright: (C) 2026 Andrey Yumashev, Vadim Soglaev. Лицензия CC BY-SA 4.0. Сайт: senar.tech
8 правил, 2 шлюза качества, 2 метрики и чеклист верификации — всё, что нужно для работы с AI-ассистентами без багов в продакшене. Никакого специального инструментария не требуется. Текстовый редактор и система контроля версий — достаточно для старта. По мере зрелости практики автоматизация помогает поддерживать дисциплину при масштабировании. Время чтения: 15 минут.
Для кого это
Вы пишете код с AI-ассистентами — Copilot, Claude, Cursor или аналогами. Вы заметили: результат AI выглядит правильно, но иногда ломается в продакшене. Вам нужна лёгкая дисциплина, которая ловит проблемы до развёртывания.
Основы SENAR — это такая дисциплина. Работает с любым AI-инструментом, любым языком, любым процессом.
Для организаций, масштабирующих AI-разработку на несколько команд, есть полный SENAR Standard.
Ключевой термин
Супервайзер — человек, который направляет AI. Если работаете один — это вы. В команде — тот, кто ставит задачу и проверяет результат AI. Один человек на задачу.
8 правил
Правило 1. Задача до кода
Каждое изменение начинается с задачи:
- Цель — что нужно сделать (одно предложение).
- Критерии приёмки — нумерованные условия, определяющие «готово». Каждое проверяется независимо.
- Негативный сценарий — хотя бы одна ситуация, которая может пойти не так (ошибка, некорректный ввод, граничное условие).
Для задач, затрагивающих авторизацию, платежи, персональные данные или внешние API — включите хотя бы один критерий приёмки про валидацию входных данных и контроль доступа.
Не начинайте кодить без задачи. Исследования — свободно, но коммит результатов исследования требует задачи.
Зачем это нужно. Качество результата AI равно качеству входных данных. «Добавь логин» порождает правдоподобный код, который проваливается на граничных случаях. «POST /auth/login возвращает JWT; возвращает 401 при неверном пароле; возвращает 422 при отсутствующем email» даёт тестируемый код с первой попытки.
Правило 2. Границы области изменений
Каждая задача явно определяет:
- Что менять — файлы, модули или компоненты в рамках задачи.
- Чего не трогать — минимум: «не изменять файлы за пределами указанной области». Будьте конкретнее, когда задача рядом с чувствительными зонами.
Без границ AI-агенты уверенно рефакторят код за пределами задачи, добавляют лишние абстракции или правят работающие системы, которых никто не просил трогать. Расползание границ — самая частая ошибка AI.
Также полезно: указать шаблоны для подражания («следуй структуре auth/router.py») и ограничения («не изменяй схему базы данных»).
Правило 3. Верификация по критериям
Каждый критерий приёмки проверяется фактически — запустить тест, проверить вывод, измерить результат, просмотреть diff.
«Работает» — это не верификация. «Выглядит правильно» — это не верификация. Для каждого критерия нужно зафиксированное свидетельство: пройденный тест, вывод команды, измеренное значение, подтверждённое поведение.
Нет свидетельства по критерию? Этот критерий не верифицирован. Где автоматические тесты уместны — пишите их. Где нет (документация, конфигурация, инфраструктура) — подойдут другие свидетельства: вывод команды, скриншот, результат grep.
Никогда не принимайте результат AI на основании интуиции, внешнего вида кода или заявления AI о готовности. Уверенность AI — это не доказательство.
Правило 4. Тесты проверяют требования, а не реализацию
Тесты берутся из критериев приёмки. Они проверяют что система делает, а не как.
Тест, который ломается при рефакторинге реализации (без изменения поведения) — это тест реализации. Тесты реализации создают ложные падения при рефакторинге и ложную уверенность при изменении функциональности.
Хороший тест: «POST /auth/login с валидными учётными данными возвращает 200 и JWT».
Плохой тест: «Метод _hash_password вызывается ровно один раз с bcrypt».
Следите за тестами, которые генерирует AI: он склонен создавать тесты, отражающие реализацию, а не проверяющие требование. Тест, который просто повторяет то, что делает код, ничего не проверяет.
Правило 5. Проверка на скрытые дефекты
Перед тем как объявить задачу «готовой», пройдите чеклист верификации (см. ниже). Три уровня по степени риска:
- Стандартный уровень (каждая задача): область изменений, удаления, фантомные импорты, качество тестов, подмена тестов, валидация входных данных, захардкоженные секреты, устаревшие паттерны, межфайловая согласованность.
- Высокий уровень (безопасность, авторизация, платежи, данные): стандартный плюс обход null-проверок, обход пустой конфигурации, доверие заголовкам, IDOR, шорткат return-True, покрытие авторизации, небезопасная десериализация.
- Критический уровень (продакшен-инциденты, регуляторика, сложные фичи): все пункты.
Задачи с пользовательским вводом, записью в базу, аутентификацией, файловым вводом-выводом или вызовами внешних API — минимум высокий уровень. При сомнениях берите выше.
Зачем это нужно. AI-дефекты сложно заметить — они проходят автоматические проверки, но содержат тонкие логические или архитектурные ошибки и проблемы безопасности. Чеклист бьёт по конкретным паттернам: возврат True без валидации, обход проверок через сравнение с null, доверие HTTP-заголовкам, пустые значения конфигурации, которые молча отключают защиту.
Правило 6. Нулевая терпимость к незавершённой работе
Каждое утверждение о завершённости подкрепляется свидетельством:
- «Все тесты проходят» — покажи вывод тестового прогона.
- «Нет нарушений линтера» — покажи вывод линтера.
- «API возвращает 401» — покажи ответ.
- «Файл обновлён» — покажи diff.
«Готово» без верификации — это не готово. «Вероятно работает» — это не готово. Если у задачи 5 критериев приёмки, все 5 нуждаются в зафиксированном свидетельстве. Заявить о полном завершении при частичной готовности — хуже, чем честно сказать «не закончил».
Правило 7. Устраняй причины, а не симптомы
Нашли дефект — установите корневую причину до того, как чинить.
Быстрый фикс, подавляющий симптом, создаёт техдолг, маскирует смежные дефекты и гарантирует повторение. AI-агенты особенно склонны к таким фиксам — они добавят null-проверку там, где настоящая проблема в том, что данные вообще не должны быть null.
Прежде чем чинить, ответьте на вопрос: «Почему этот дефект существует?» Если ответ — «не знаю», продолжайте расследование до наложения патча. Минимум: определить точку отказа и условие, которое её вызвало. Для сложных дефектов (конкурентность, состояние, внешние зависимости) — воспроизведите проблему для проверки гипотезы.
Гигиена контекста: не отправляйте персональные данные, учётные данные или регулируемую информацию в облачные AI-инструменты без Соглашения об обработке данных (DPA). Полные требования — в Standard Rule 10.12.
Правило 8. Фиксация знаний
Документируйте следующее во время или сразу после завершения задачи:
- Тупики — любой подход, на который ушло больше 15 минут и который был отвергнут. Запишите: что пробовали, почему не сработало, что выбрали вместо этого. (15 минут — отправная точка, адаптируйте под свою предметную область. На основе эмпирических наблюдений: после 15 минут затраты на документирование растут, а подход крайне редко приносит результат.)
- Решения — неочевидные выборы с обоснованием (например, «выбрали argon2 вместо bcrypt, потому что bcrypt не импортируется в Python 3.14»).
- Известные проблемы — ограничения, обходные решения или техдолг, внесённый задачей.
Храните знания там, где будущие AI-сессии смогут их найти — документация проекта, база знаний, комментарии в коде, что угодно рабочее. Знания, которые существуют только у вас в голове, для AI не существуют.
Зачем это нужно. У AI нет памяти между сессиями. Без зафиксированных знаний одни и те же тупики исследуются повторно, одни и те же решения обсуждаются заново, одни и те же обходные пути переоткрываются — с теми же затратами каждый раз.
Шлюзы качества
Два шлюза качества, через которые проходит каждая задача. Как их обеспечить — вручную, через инструментарий, на ревью — решайте сами. Метод не важен; важно, чтобы проверка состоялась.
ПРИМЕЧАНИЕ: Здесь используется термин «шлюзы» в соответствии с SENAR Standard (раздел 8), где Quality Gates — это точки принудительного контроля, а Checkpoints/Контрольные точки (раздел 3.12) — это действия по сохранению контекста внутри сессии. Эти понятия различны.
Шлюз качества «Старт»
(В полном стандарте SENAR — QG-0)
Перед тем как писать код, проверьте:
| # | Проверка | Правило |
|---|---|---|
| 1 | Цель определена (одно предложение) | Правило 1 |
| 2 | Критерии приёмки перечислены (нумерованные, проверяемые) | Правило 1 |
| 3 | Включён хотя бы один негативный сценарий | Правило 1 |
| 4 | Область изменений определена (что менять, чего не трогать) | Правило 2 |
| 5 | Для задач, связанных с безопасностью: поверхность угроз определена, критерии по безопасности включены | Правило 1 |
Если чего-то не хватает — дополните, прежде чем направить AI на работу. Пункт 5 относится к задачам, затрагивающим авторизацию, пользовательский ввод, хранение данных, платежи или внешние API.
Шлюз качества «Готово»
(В полном стандарте SENAR — QG-2)
Перед тем как объявить задачу завершённой, проверьте:
| # | Проверка | Правило |
|---|---|---|
| 1 | Все критерии приёмки имеют зафиксированное свидетельство верификации | Правила 3, 6 |
| 2 | Для тестируемых критериев есть автоматические тесты и они проходят; для нетестируемых — другое зафиксированное свидетельство | Правила 3, 4 |
| 3 | Чеклист верификации пройден на соответствующем уровне | Правило 5 |
| 4 | Корневая причина установлена для всех дефектов, найденных в ходе задачи | Правило 7 |
| 5 | Тупики, решения и известные проблемы задокументированы (если нет — укажите «нет») | Правило 8 |
Если что-то не выполнено — задача остаётся в работе.
Метрики
Два числа для отслеживания. Не задавайте целевые показатели сразу — измеряйте минимум 3 рабочих цикла, чтобы установить базовую линию.
FPSR — доля успеха с первой попытки
задачи_завершённые_без_переделок / всего_завершённых_задач * 100%
Процент задач, завершённых корректно с первой попытки — без дефектов после объявления «готово», без повторного открытия, без переделок. Главный индикатор того, работают ли шлюзы «Старт» и «Готово».
Команды, внедряющие Основы SENAR, обычно видят 50-65% в начале с ростом до 80-90% по мере выработки привычки. Это ориентировочные диапазоны — установите свои.
Показатель тупиков (Dead End Rate)
время_на_тупики / общее_время_задачи * 100%
Проще: количество_тупиков / всего_задач — среднее число тупиков на задачу.
Измеряет долю усилий, потраченных на отвергнутые подходы. Отражает эффективность фиксации знаний (правило 8). Снижение показателя — значит, база знаний работает.
Выше 30% — повод разобраться. Ниже 10% в зрелом проекте — эффективное переиспользование знаний.
Чеклист верификации
Этот чеклист реализует правило 5. Выбирайте уровень по степени риска задачи.
| Тип задачи | Уровень | Пунктов |
|---|---|---|
| Баг-фикс, конфиг, простой CRUD | Облегчённый | 4 (пункты 1, 3, 5, 7) |
| Обычная фича, рефакторинг | Standard | 10 |
| Auth, платежи, PII, внешние API | High | 18 |
| Прод-инцидент, регуляторика, сложная фича | Critical | 28 |
Стандартный уровень — каждая задача
Облегчённый режим для мелких задач: Для задач короче 15 минут (баг-фиксы, изменения конфигурации, простой CRUD) проверьте минимум пункты 1, 3, 5 и 7 — соответствие области, подмену тестов, валидацию ввода и секреты. Полный стандартный уровень применяйте для всего, что затрагивает авторизацию, платежи или пользовательские данные.
| # | Проверка | На что обращать внимание |
|---|---|---|
| 1 | Область изменений | AI модифицировал файлы за пределами определённой области задачи? |
| 2 | Удаления | AI молча удалил или заменил существующий работающий код? |
| 3 | Фантомные зависимости | Все подключаемые зависимости реально существуют и доступны? (пакеты в манифесте, API доступны, сервисы объявлены) |
| 4 | Качество тестов | Тесты проверяют поведение из критериев приёмки или просто отражают реализацию? |
| 5 | Подмена тестов | AI подправил существующие тесты, чтобы они проходили, вместо исправления кода? |
| 6 | Валидация входных данных | Все пользовательские данные валидируются по типу, длине и формату перед использованием в запросах, файловых операциях или командах. |
| 7 | Захардкоженные секреты | Нет API-ключей, паролей, токенов или учётных данных в исходном коде. |
| 8 | Устаревшие паттерны | Код использует deprecated API, удалённые функции или паттерны устаревших версий фреймворков? |
| 9 | Межфайловая согласованность | Если тип, интерфейс или контракт изменён — все потребители обновлены? |
| 10 | Качество кода | Функции длиннее 200 строк, дублирование логики, игнорирование существующих утилит, нечитаемая структура. AI-код часто работает, но архитектурно одноразовый. |
Высокий уровень — безопасность, авторизация, платежи, данные
Все пункты стандартного уровня, плюс:
| # | Проверка | На что обращать внимание |
|---|---|---|
| 11 | Обход null-проверок | Сравнения, где обе стороны могут быть null/None/nil — None == None истинно, что обходит проверки доступа. |
| 12 | Обход пустой конфигурации | Проверки безопасности пропускаются, когда конфигурационное значение — пустая строка (например, if secret and ... проваливается в открытое состояние). |
| 13 | Доверие заголовкам | HTTP-заголовки (X-Forwarded-For, X-Partner-ID) используются для решений безопасности без проверки от вышестоящего прокси. |
| 14 | IDOR | Доступ к ресурсам по ID без проверки авторизации запрашивающего пользователя на этот конкретный ресурс. |
| 15 | Шорткат return-True | Функции контроля доступа, которые возвращают True или предоставляют доступ без явной проверки принадлежности. |
| 16 | Покрытие авторизации | Каждый эндпоинт, обращающийся к пользовательским данным, имеет обязательную аутентификацию; авторизация проверяется на уровне ресурса. |
| 17 | Небезопасная десериализация | Десериализация недоверенных данных без валидации (pickle, yaml.load без SafeLoader, eval/exec на входных данных). |
| 18 | SSRF | Подделка серверных запросов (Server-Side Request Forgery): URL из пользовательского ввода валидируются по allowlist; нет нефильтрованных запросов к произвольным URL. |
Критический уровень — продакшен-инциденты, регуляторика, сложные фичи
Все пункты стандартного и высокого уровней, плюс:
| # | Проверка | На что обращать внимание |
|---|---|---|
| 19 | Версии зависимостей | Указанные версии пакетов реальны и опубликованы в официальном реестре? |
| 20 | Захардкоженные значения | Магические числа, URL, вшитые в код (секреты проверяются на стандартном уровне). |
| 21 | Переусложнение | Лишние абстракции, паттерны проектирования или обобщения сверх требований задачи. |
| 22 | Дублирование | Новый код, дублирующий функциональность, уже доступную в существующих утилитах проекта. |
| 23 | Граничные случаи | Счастливый путь работает — а что с null, пустыми значениями, границами, конкурентным и высоконагруженным вводом? |
| 24 | Именование | AI следует соглашениям об именовании проекта последовательно? |
| 25 | Область коммита | Коммит атомарен и сфокусирован на задаче, или содержит несвязанные изменения? |
| 26 | Инъекция через форматирование строк | Строковая интерполяция или форматирование с недоверенным вводом (Python str.format, JS template literals с eval, C printf). |
| 27 | Недостижимый защитный код | Ветки кода «на всякий случай», которые никогда не выполнятся, маскируя неполноту управления потоком. |
| 28 | Проглоченные исключения | Блоки catch/except, которые молча отбрасывают ошибки — except Exception: pass, пустые catch-блоки, логирование ошибок на уровне debug. |
Что дальше
Основы SENAR — это отправная точка. Когда команда растёт или нужно больше структуры, есть чёткая линия развития:
| Базовая | Начальная | Командная | Корпоративная | |
|---|---|---|---|---|
| Пар | 1 | 1–3 | 3–10 | 10+ |
| Правил | 8 | 11 | 15 | 15 |
| Шлюзов качества | 2 | 2 (QG-0, QG-2) | 5 (QG-0..QG-4) | 5 + комплаенс |
| Метрик | 2 | 4 | 10 | 10 + портфель |
| Ролей | 1 | 3 (совмещённые) | 5 (выделенные) | 5 + портфель |
| Церемоний | 0 | 3 | 7 | 7 + портфель |
| Инструментарий | Не требуется | Рекомендуется | Обязателен | Обязателен |
Примечание о «парах»: Пара — это один Супервайзер, работающий с одним или несколькими AI-агентами. Как правило, это один разработчик со своим AI-инструментом для кодирования.
Следующий шаг после Основ SENAR: SENAR Начальная (Foundation) — добавляет управление сессиями, 3 совмещённые роли, 4 метрики. Занимает 2–4 недели после того, как привычки Основ SENAR закрепились. Подробности в полном SENAR Standard.
Примечание: Управление сессиями (структурированный старт и завершение AI-рабочих сессий) вводится на Начальном уровне. Core фокусируется на дисциплине отдельной задачи.
Соответствие стандарту: Если вы соблюдаете все 8 правил и стабильно проходите оба шлюза, вы практикуете Основы SENAR. Никакого официального подтверждения не требуется — соответствие Core оценивается самостоятельно.
Правила Базовой конфигурации напрямую соответствуют правилам Standard — ничего не приходится переучивать:
| Правило Базовой конфигурации | Эквивалент в Standard |
|---|---|
| 1. Задача до кода | Rule 1 (S10.1) + QG-0 (S8.1) |
| 2. Границы области изменений | QG-0 criteria + Guide habit |
| 3. Верификация по критериям | QG-2 (S8.3) + Rule 15 L2 (S10.15) |
| 4. Тесты проверяют требования | QG-2 test criteria + QG-3 (S8.4) |
| 5. Проверка на скрытые дефекты | Rule 15 (S10.15) + AI Review Checklist |
| 6. Нулевая терпимость к незавершённой работе | QG-2 criteria (S8.3) |
| 7. Устраняй причины, а не симптомы | QG-2 criterion (S8.3) + Guide failure modes |
| 8. Фиксация знаний | Rule 4 (S10.4) + Rule 9 (S10.9) |
ПРИМЕЧАНИЕ: Правила Standard 10.2 Длительность сессии (Session Duration), 10.3 Каденция контрольных точек (Checkpoint Cadence), 10.5 Периодический аудит (Periodic Audit), 10.6 Контроль версий (Version Control), 10.7 Лимит параллельных агентов (Parallel Agent Limit), 10.8 Калибровка сложности и стоимости (Complexity-Cost Calibration), 10.10 Трассировка требований (Requirement Traceability), 10.11 Документирование кода (Code Documentation as Context), 10.12 Гигиена контекста (Context Hygiene), 10.13 Управление моделями AI (AI Model Governance), 10.14 Управление изменениями скриптов (Script Change Management) — это новые правила для конфигураций Начальная/Командная/Корпоративная, не имеющие эквивалента в Базовой.
Краткая справочная карта
Перед началом задачи (шлюз качества «Старт»):
- Сформулируйте цель (одно предложение).
- Перечислите критерии приёмки (нумерованные, каждый проверяется независимо).
- Добавьте хотя бы один негативный сценарий.
- Определите область: что менять, чего НЕ трогать.
Пока AI работает:
- Верифицируйте каждый критерий приёмки свидетельством (запустите, протестируйте, измерьте).
- Документируйте каждый тупик, который занял больше 15 минут.
Перед объявлением готовности (шлюз качества «Готово»):
- Пройдите чеклист верификации на соответствующем уровне.
- Подтвердите: все КП верифицированы, тесты проходят, чеклист пройден, знания зафиксированы.
После задачи:
- Зафиксируйте решения, известные проблемы и всё неочевидное.
- Спросите себя: сможет ли новый разработчик (или AI) продолжить эту работу, не задавая вопросов? Если нет — зафиксируйте недостающее.
Основы SENAR 1.3 — senar.tech Copyright (C) 2026 Andrey Yumashev, Vadim Soglaev. Лицензия CC BY-SA 4.0.