TL;DR
Реплей правил — способ проверить, нужно ли правило в AGENTS.md / CLAUDE.md на текущей модели. Берёте две копии репозитория: в одной правило есть, в другой нет. Запускаете одну и ту же задачу несколько раз и смотрите, повторится ли сбой. Второй приём из исследования — ежемесячный аудит документации. Агент в режиме «только чтение» сверяет текст документов с файлами и историей git и ищет устаревшие утверждения.
Главная находка: правила переживают сбои, ради которых их написали. Новые модели часто не делают ошибку, из-за которой вы добавили правило. В репозитории автора из пяти воспроизведённых сбоев в трёх ошибка не повторилась ни с правилом, ни без него. Правила при этом только копятся: инструменты и люди добавляют «уроки» быстрее, чем убирают. Файл пухнет, токены тратятся, а часть правил уже ничего не делает. При этом устаревшая документация (в тексте «11 скилов», а их уже 14) возвращалась снова и снова. Каждая новая проверка гасила одну форму устаревания, а через 1–9 дней всплывала другая. Один проход LLM-аудита находил примерно половину известных устаревших мест. Зато находки были почти всегда верными.
Вывод для практики: поведенческие правила периодически перепроверяйте и удаляйте лишнее, а устаревание документации ловите механическими проверками и регулярным аудитом. Проверка, написанная кодом (например, скрипт, который сверяет число скилов), остановила повторный сбой во всех прогонах. Текстовое правило про оценку времени не изменило поведения даже старой модели.
Схема метода
ШАГ 1: Журнал сбоев → строка на каждый повторяющийся сбой:
дата, категория, как нашли, фикс, ТИП фикса (правило / проверка кодом), повторился ли
ШАГ 2: Выбор типа фикса → «агент читает» (текстовое правило) или «код блокирует» (проверка/хук)
ШАГ 3: Раз в месяц → аудит: агент read-only сверяет документы с деревом файлов и git
ШАГ 4: Реплей правила → 2 копии репо (с правилом / без), одна задача, по 3 прогона на каждую
ШАГ 5: Сбоя нет и без правила → правило кандидат на удаление; сбой есть → оставить, лучше превратить в проверку
Шаги 1–3 и 5 делаются обычными чатами и агентом. Шаг 4 делается вручную: две папки, один и тот же запрос, без кода.
Пример применения
Задача: Вы делаете Telegram-бота записи для сети барбершопов «Борода» в Казани. В репозитории лежит CLAUDE.md на 400 строк, накопленный за полгода. Часть правил появилась после ошибок старой модели: «не называй цену без сверки с price.md», «всегда проверяй последнюю запись в CHANGELOG, а не первую», «оценка задачи — 1–5 минут». Вы перешли на новую модель и хотите понять, какие правила можно выбросить.
Промпт (запускается в двух копиях репозитория, где в B правило «проверяй последнюю запись в CHANGELOG» удалено):
Задача: добавь в бота ответ на вопрос «сколько стоит стрижка с бородой».
Ориентируйся на документацию репозитория. Если в документах есть
противоречия, сообщи о них отдельным пунктом в конце.
Запустите по 3 раза на копию A (правило есть) и копию B (правила нет). В обеих копиях используйте одинаковое сообщение коммита, чтобы по git log было не угадать условие.
Результат: Вы получите 6 ответов и сравните их по одному признаку: взял ли агент цену из устаревшей записи CHANGELOG. Если во всех 6 ответах цена верная, правило на этой модели, вероятно, лишнее, и его можно убрать. Если в копии B ошибка появилась, правило оставьте и подумайте, нельзя ли заменить его проверкой, например скриптом, который сверяет price.md с текстом бота.
Почему это работает
Слабость. Текстовое правило — просто совет. Модель читает его и может проигнорировать, а при обновлении модели оно может стать ненужным. Никто об этом не узнаёт: в файле правило всё ещё висит, и выглядит оно так, будто защищает вас. Документация к тому же устаревает не из-за модели, а из-за того, что вы меняете проект. Текстовое «обновляй счётчики» этого не останавливает.
Сильная сторона. Сравнение «с правилом и без» превращает вопрос «наверное, нужно» в простой эксперимент. LLM хорошо читает много файлов и сверяет утверждения между собой. Поэтому аудит находит устаревшие места с высокой точностью. Код хорош в одном: он проверяет без упоминаний «пожалуйста» и срабатывает каждый раз.
Как метод их сочетает. Для устаревания вы ставите код-проверку (узкую, но надёжную) и добавляете LLM-аудит (широкий, но находит примерно половину). Для поведенческих правил делаете реплей и убираете то, что ничего не меняет.
Рычаги управления: - Число прогонов (в исследовании 3) → увеличьте для важных правил, чтобы не принять случайность за закономерность. - Модель → повторите реплей на старой и новой модели. Так видно, что именно обновление сделало правило ненужным. - Тип фикса → если правило важное, замените текст проверкой, которую выполняет код. - Состав аудита → добавьте «независимую» проверку (другую модель или повторный прогон): один проход ловит примерно половину.
Шаблон промпта
Дословного промпта в статье нет: аудит шёл по «фиксированному промпту», его текст не приведён. Ниже шаблоны, собранные по описанной механике.
Шаблон 1. Ежемесячный аудит документации (агент только читает):
Роль: аудитор документации. Ты работаешь только на чтение: ничего не правь.
Задача: найди в документах {папки_или_файлы} утверждения,
которые устарели относительно текущего состояния репозитория.
Проверяй сверкой с реальностью:
- пути к файлам: существуют ли они в дереве файлов
- числа и счётчики ({что_считаем}): совпадают ли с фактическим количеством
- расписания и даты: совпадают ли с {где_лежит_источник_правды}
- имена скриптов, функций, идентификаторов: не переименованы ли они (смотри git log)
- описание поведения скриптов: соответствует ли коду
Для каждой находки выдай строку:
[файл:строка] → цитата утверждения → что на самом деле → чем подтверждено (файл или коммит)
Не включай находки, которые не можешь подтвердить файлом или историей git.
В конце: сколько файлов проверил и что НЕ проверял.
Шаблон 2. Реплей правила (запускается в двух копиях репозитория):
Копия A: репозиторий с правилом {правило}.
Копия B: тот же репозиторий, правило удалено.
Задача, которая раньше приводила к сбою: {задача}.
Признак сбоя: {что_считаем_ошибкой}.
Запусти задачу по 3 раза в каждой копии, в чистом сеансе.
Фиксируй для каждого прогона: сбой был / не было, что именно сделал агент.
Что подставлять: {папки_или_файлы} — документы, за которые вы отвечаете. {что_считаем} — число скилов, команд, тарифов. {правило} — конкретное правило из файла инструкций. {что_считаем_ошибкой} — измеримый признак вроде «цена не из price.md» или «использовано длинное тире».
🚀 Быстрый старт — вставь в чат агента (Claude Code, Cursor):
Вот шаблон аудита документации. Адаптируй под мой репозиторий: [опиши проект].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
Агент спросит, где лежит документация, что в ней можно сверить с реальностью (числа, пути, даты) и где источник правды. Это нужно, чтобы аудит сравнивал документы с проверяемыми фактами, а не «оценивал качество текста».
Ограничения
⚠️ Один репозиторий, один автор: все результаты из одного личного репозитория с тремя прогонами на условие. Автор сам называет работу предварительной. Это сигнал, а не доказательство.
⚠️ «Не повторилось» ≠ «не нужно»: три прогона без сбоя не гарантируют, что сбоя не будет на других задачах. Удаляйте правило осторожно: оно может защищать редкий случай.
⚠️ Аудит ловит только половину: один проход LLM-аудита находил примерно половину известных устаревших мест. Не принимайте «аудит чист» за «документация актуальна».
⚠️ Проверки кодом тоже ломаются: хук блокировал безобидную правку, если в ней была цитата опасной команды. Регулярка пропускала
git -C путь reset --hard. Сканер секретов не смотрел в changelog, куда агент записал идентификатор. Фоновая синхронизация конфликтовала с работой агента.
⚠️ Текстовое правило не всегда меняет поведение: правило про оценку времени не изменило завышенные оценки Sonnet 4.5. Если нужна гарантия, нужна проверка, а не просьба.
⚠️ Лимит размера не лечит разрастание: когда автор ограничил размер главного файла, правила просто переехали в скилы, и общий объём вырос.
⚠️ Неполный текст: в доступной версии статьи часть результатов (рисунок 4 и далее) обрезана. Цифры по аудиту и реплею взяты из аннотации и раздела методов.
Как исследовали
Идея была простой: вместо снимка чужих репозиториев автор шесть недель наблюдал за одним своим, где три агентных инструмента ежедневно правили общий набор правил. Каждый сбой агента обязательно записывался вместе с причиной и фиксом. Получился журнал из 118 сбоев. Его размечали двумя проходами LLM (Sonnet, затем «слепо» Opus), а расхождения автор разбирал сам.
Крупнейший класс — устаревшая документация (48 из 118), хотя 35 из них нашли за один день аудитов. Для проверки аудита автор взял 47 реальных устаревших утверждений и подложил 20 искусственных ошибок. Он спрятал следы правок от git, чтобы агент не «читал» ответы из diff. Аудит запускали по три раза на Haiku, Sonnet и Opus.
Затем реплей: пять прошлых сбоев воспроизводили в двух одноразовых клонах (с фиксом и без). Результат удивил: на текущей модели в трёх из четырёх завершённых задач сбой не случился ни с фиксом, ни без. Вернулся только сбой «забыл обновить счётчик», и проверка кодом остановила его в каждом прогоне. На старых моделях длинное тире один раз проскочило, и проверка его отклонила. Вывод для практики: код-проверки работают предсказуемо, текстовые правила могут стать мёртвым грузом, а вот отсутствие повторного сбоя ещё надо проверять.
Адаптации и экстраполяции
🔧 Техника: добавить метку к каждому правилу → ревизия становится дешёвой
В статье каждый урок записывался с причиной. Можно пойти дальше и ставить метку прямо в файл инструкций, чтобы потом знать, что проверять:
- Не называй цену без сверки с price.md.
[причина: бот назвал старый тариф 12.03 | модель: Sonnet 4.5 | проверить после смены модели]
При смене модели вы просите агента составить список правил с такой пометкой и запускаете для них реплей.
Экстраполяция: правило → проверка кодом, которую пишет сам агент
Если сбой повторяется, а правило не помогает, замените его скриптом (идея из related work статьи: перевод инструкций в проверки поднял соблюдение с 67% до 88%):
Правило в AGENTS.md не помогает: агент всё равно {описание_сбоя}.
Напиши небольшой скрипт-проверку для pre-commit, который
ловит этот сбой по признаку {признак}, и покажи на двух
примерах: когда он срабатывает и когда нет.
Предложи, что удалить из AGENTS.md после установки проверки.
Ресурсы
- Lessons Outlive Their Failures: A Case Study of Rules for AI Coding Agents — Hassan Hassanzadeh Aliabadi, независимый исследователь, октябрь 2026
- Упомянутые работы: Chakrabarti (рост файлов инструкций в 1867 репозиториях), Cai et al. (опрос 99 практиков), Gloaguen et al. и Lulla et al. (влияние AGENTS.md на результат), Zhang et al. (явные запреты как единственные полезные правила), ContextCov, AgentSpec, Kang et al. (harness-level forgetting), Vasilopoulos (codified context)