Защитные ограничения в коде для агентов

Комментарии как управление контекстом: критические секции для агентов​

Продвинутый приём — используй умеренно. В параллельном программировании критические секции защищают общие ресурсы взаимным исключением. Комментарии могут выполнять похожую роль для ИИ-агентов: создавать «критические для агента секции», защищающие чувствительный код от случайного изменения. Применяй это только к действительно рискованному коду: аутентификации и авторизации, криптографическим операциям, обработке платежей, миграциям базы данных, журналам аудита, работе с персональными данными. Не применяй к обычной бизнес-логике, CRUD-операциям и часто меняющемуся коду. Компромисс: защита затрудняет работу. Если каждая функция помечена «КРИТИЧНО», сигнал превращается в шум, а полезная работа агента замедляется.

Исследуя кодовую базу, агенты читают файлы и загружают все комментарии в контекстное окно. Поэтому комментарии становятся промптами. Пиши их как промпты, используя приёмы из главы Основы промптинга: повелительные указания (NEVER, MUST, ALWAYS), явные запреты («Не делай X. Вместо этого всегда делай Y»), нумерованные шаги для сложных операций и конкретные последствия. Когда агент генерирует код обработки паролей и читает «НИКОГДА не хранить пароли открытым текстом» вместе с допустимыми альтернативами, нарушение становится гораздо менее вероятным. Ты используешь инъекцию промпта в полезных целях.

// Standard comment
// Validates password before storing
function createUser(password: string) {
  return db.users.insert({ password });
}

// Critical section (agent barrier)
// === CRITICAL SECURITY SECTION ===
// C-001: NEVER store passwords in plain text or weak hashing (MD5, SHA1)
// MUST hash with bcrypt (10+ rounds) BEFORE persistence
// Do NOT modify hashing algorithm without security review
// Violations create CVE-level vulnerabilities
function createUser(password: string) {
  if (password.length < 12) {
    throw new Error('Password must be at least 12 characters');
  }
  const hashed = bcrypt.hashSync(password, 10);
  return db.users.insert({ password: hashed });
}

Так создаётся намеренное затруднение. Агент с задачей «добавить вход через OAuth» будет осторожнее и медленнее работать рядом с хешированием паролей, потому что ему нужно учесть все указания NEVER/MUST. В этом и заключается защита: вынужденная осторожность на критических путях. Но чрезмерное использование вредит. Пометь слишком много функций как CRITICAL — и агенту станет трудно выполнять обычную работу; безопасные изменения замедлятся так же, как опасные. Оставляй этот приём для кода, где цена случайного изменения действительно выше замедления разработки.

Идентификаторы ограничений (C-001, I-001) появляются в таблицах ограничений спецификации и при реализации переносятся в код. После этого код несёт ограничение — не только реализацию, но и правило, которое она обеспечивает. Поэтому после реализации спецификацию можно безопасно удалить: объяснение «почему» переместилось в кодовую базу.

Главное​

• Комментарии как критические секции для агентов (используй умеренно): в действительно рискованном коде — аутентификации, криптографии, платежах, персональных данных — пиши комментарии как промпты с обязательными указаниями NEVER, MUST, ALWAYS. Так возникает полезная осторожность; чрезмерное использование мешает.
• Идентификаторы ограничений переходят из спецификации в код: если спецификация использует C-001 или I-001, при реализации агент встраивает их в комментарии кода. Тогда код несёт само правило, и спецификацию можно удалить.