Технический контекст
Я бы не делал из этого мифологию, но совет здравый: после выхода новой модели Claude я почти всегда перечитываю CLAUDE.md. В реальной AI automation это такой же рабочий артефакт, как системный промпт, роутинг или набор tool calls. Если модель стала умнее, часть старых костылей начинает только мешать.
И вот тут я обычно торможу и режу без жалости. Если в файле накопились длинные запреты, повторяющиеся правила и микроинструкции на все случаи жизни, модель тратит контекст не на задачу, а на обслуживание старых страхов команды.
Важная оговорка: я не нашел официальной документации Anthropic, где было бы прямо сказано, что после каждого релиза нужно переписывать именно CLAUDE.md. И тем более нет подтвержденной публичной линии про какие-то “Fable models”. Похоже, это либо внутреннее название, либо чья-то локальная терминология.
Но практический вывод от этого не меняется. Я вижу одно и то же в проектах: новая модель иначе интерпретирует старые инструкции, а раздутый CLAUDE.md начинает провоцировать лишние круги, уточнения и перепроверки. Это уже не теория, а чистая механика контекстного окна.
Что я обычно проверяю: какие правила реально предотвращают ошибки, а какие просто дублируют здравый смысл модели. Если строку можно удалить без последствий, я ее удаляю. Подробности по архитектуре, тестам и доменным кейсам я выношу в отдельные файлы, а в CLAUDE.md оставляю короткий каркас.
Еще один полезный тест: я гоняю 2-3 типовые задачи после смены модели и смотрю, где она спотыкается. Только после реального сбоя я добавляю новую инструкцию. Не раньше.
Влияние на бизнес и автоматизацию
Для бизнеса тут не философия, а очень приземленные эффекты. Первый: меньше токенов на пустом месте, особенно если команда часто дергает Claude в IDE, CI или внутренних ассистентах. Второй: меньше странных отклонений в поведении после апдейта модели.
Выигрывают команды, у которых много повторяемых инженерных сценариев: код, ревью, саппорт, внутренние knowledge agents. Проигрывают те, кто превращает CLAUDE.md в свалку корпоративных пожеланий.
В AI solution development я бы вообще относился к таким файлам как к живой части системы, а не как к заметке “один раз написали и забыли”. Мы в Nahornyi AI Lab как раз такие узкие места и разбираем: где нужен короткий каркас, где skill, где отдельная AI architecture, а где инструкция только раздувает стоимость. Если чувствуете, что Claude у вас начал ходить кругами и сжигать контекст, можно быстро разобрать workflow и собрать более чистую AI automation под ваш реальный процесс.