Редакторская заметка: В январе 2026 года жалобы Андрея Карпати на написание кода Claude привлекли внимание к файлу, который на первый взгляд кажется незначительным, но играет чрезвычайно важную роль в рабочем процессе программирования с ИИ: CLAUDE.md. Форрест Чанг затем систематизировал эти проблемы в четыре поведенческих правила, направленных на ограничение типичных ошибок Claude при написании кода: молчаливые допущения, чрезмерное усложнение, повреждение несвязанного кода и отсутствие четких критериев успеха.

Но спустя несколько месяцев сценарии использования Claude Code уже не ограничиваются просто «заставлением модели написать фрагмент кода». По мере того как многошаговые агенты, цепочки триггеров по хукам, загрузка навыков и совместная работа с несколькими репозиториями стали нормой, начали появляться новые модели сбоев: модель теряет контроль при выполнении длинных задач, тесты проходят, но реальная логика не проверяется, миграция завершена, но ошибки пропускаются молча, стили кода из разных источников неправильно смешиваются.

Автор статьи протестировал 30 репозиториев за 6 недель и добавил 8 новых правил к исходным четырем правилам Карпати, чтобы охватить новые проблемы, возникающие при переходе от однократного дополнения кода к агентной коллаборации в AI-программировании.

Следует оригинальный текст:

В конце января 2026 года Андрей Карпати опубликовал серию твитов, в которых критиковал способ, которым Клод пишет код. Он выделил три типичные проблемы: сделанные без пояснений неверные предположения, чрезмерная сложность и ненужные разрушения в коде, который не должен был изменяться.

Форрест Чан увидел эту цепочку твитов, систематизировал жалобы в четыре правила поведения, записал их в отдельный файл CLAUDE.md и опубликовал на GitHub. В первый день запуска проект получил 5 828 звезд, за две недели был сохранен 60 000 раз, а сейчас насчитывает 120 000 звезд и стал самым быстро растущим одиночным файловым репозиторием 2026 года.

Затем я протестировал его на 30 репозиториях в течение 6 недель.

Эти четыре правила действительно работают. Ошибки, которые ранее возникали с вероятностью около 40%, в задачах, подходящих для применения этих правил, снизились до менее чем 3%. Однако проблема в том, что этот шаблон изначально был создан для устранения ошибок, возникавших у Claude при написании кода в январе.

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

Таким образом, я добавил еще 8 правил. Ниже — полная версия из 12 правил CLAUDE.md: почему каждое из них стоит включить, и где оригинальный шаблон Karpathy тайно перестает работать в 4 местах.

Если вы хотите пропустить объяснение и сразу скопировать и использовать, полный файл находится в конце.

Почему это важно

Файл CLAUDE.md от Claude Code — это самый недооцененный файл во всей стеке AI-программирования. Большинство разработчиков обычно допускают три типа ошибок:

Во-первых, превратите его в мусорную корзину предпочтений, заполнив его всеми своими привычками, пока он не раздулся до более чем 4000 токенов, и уровень соблюдения правил не упал до 30%.

Во-вторых, полностью не использовать его и каждый раз заново запрашивать. Это приведет к пятикратной трате токенов и отсутствию согласованности между сессиями.

В-третьих, скопировав шаблон, вы больше не обращаете на него внимания. Он может работать две недели, но с изменением кодовой базы перестанет работать, несмотря на то, что вы этого не замечаете.

Официальная документация Anthropic четко указывает: CLAUDE.md носит рекомендательный характер. Claude следует ему примерно 80% времени. После превышения 200 строк уровень соблюдения значительно снижается, поскольку важные правила затеряны среди шума.

Шаблон Карпати решает эту проблему: один файл, 65 строк, 4 правила. Это минимальный порог.

Но лимит может быть еще выше. После добавления этих восьми правил он охватывает не только проблемы с написанием кода, о которых Карпати жаловался в январе 2026 года, но и проблемы с оркестрацией агентов, которые появились только в мае 2026 года — проблемы, которых еще не существовало при создании исходного шаблона.

Исходные 4 правила

Если вы еще не смотрели репозиторий Форреста Чанга, сначала ознакомьтесь с этой базовой версией:

Правило 1: Подумайте перед кодированием.

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

Правило 2: Простота превыше всего.
Используйте минимальный код, необходимый для решения проблемы. Не добавляйте функции, которых нет в требованиях. Не создавайте абстракции для одноразового кода. Если опытный инженер сочтёт его излишне сложным — упростите.

Правило 3: Хирургические изменения.
Изменяйте только то, что обязательно нужно изменить. Не «оптимизируйте» соседний код, комментарии или форматирование. Не рефакторьте то, что не сломано. Сохраняйте согласованность с существующим стилем.

Правило 4: Действуйте с ориентацией на цель.
Сначала определите критерии успеха, затем итеративно повторяйте, пока не будет завершена проверка. Не говорите Claude, как выполнять каждый шаг, а укажите, каким должен быть успешный результат, и дайте ему возможность итерировать самостоятельно.

Эти 4 правила позволяют устранить примерно 40% сбоев, которые я наблюдаю в сессиях Claude Code без наблюдения. Оставшиеся около 60% проблем скрыты в этих пустотах.

Я добавил 8 новых правил и почему

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

Правила Карпати не охватывают этот момент. В результате модель начала принимать решения по вопросам, которые должны были обрабатываться детерминированным кодом: повторять ли вызов API, как маршрутизировать сообщение, когда обновлять обработку. В итоге еженедельные решения были разными. Вы получаете нестабильный if-else, оплачиваемый по цене 0,003 доллара за токен.

В тот момент существовал код, который вызывал Claude, чтобы «определить, следует ли повторять запрос при возникновении 503». Сначала он работал отлично в течение двух недель, но затем внезапно стал нестабильным, потому что модель начала включать тело запроса в контекст для принятия решения. Стратегия повторных попыток стала случайной, поскольку сам промпт был случайным.

CLAUDE.md без ограничений по бюджету равен пустому чеку. Каждый цикл может выйти из-под контроля и превратиться в сброс контекста объемом 50 000 токенов. Модель не остановится сама.

В тот момент сеанс отладки длился 90 минут. Модель постоянно повторяла итерации над одним и тем же фрагментом ошибки объемом 8 КБ и постепенно забывала, какие решения уже пробовала. В конце она начала предлагать варианты, которые я уже отвергал за 40 сообщений до этого. При наличии бюджета токенов этот процесс должен был быть остановлен уже на 12-й минуте.

Когда две части кодовой базы противоречат друг другу, Claude пытается угодить обеим сторонам, в результате получается непоследовательный код.

В тот момент в кодовой базе существовали две модели обработки ошибок: одна — с использованием async/await и явных блоков try/catch, другая — глобальные границы ошибок. Новый код, написанный Claude, использовал обе модели. В результате обработка ошибок выполнялась дважды. Мне потребовалось 30 минут, чтобы понять, почему ошибки дважды подавлялись.

«Хирургическая модификация» Карпати говорит Claude не изменять соседний код. Но она не говорит Claude: сначала понять соседний код. Без этого Claude будет писать новый код, конфликтующий с существующим кодом, расположенным в 30 строках отдалении.

В тот момент Клод добавил новую функцию, полностью идентичную существующей, потому что не прочитал исходную функцию. Обе функции выполняют одну и ту же задачу. Однако из-за порядка импорта новая функция перекрыла старую, которая уже в течение шести месяцев была единственным фактическим стандартом.

«Целевая ориентация» Карпати подразумевает, что тесты могут служить критерием успеха. Однако на практике Клауд воспринимает «прохождение тестов» как единственную цель и пишет код, который проходит поверхностные тесты, но нарушает другие компоненты.

В тот момент Клод написал 12 тестов для функции аутентификации, и все они прошли. Но логика аутентификации в продакшене сломалась. Эти тесты просто проверяли, что функция «возвращает что-то», а не то, возвращает ли она правильное значение. Функция проходила тесты, потому что возвращала константу.

Шаблон Карпати по умолчанию предполагает одноразовое взаимодействие. Однако реальная работа с Claude Code часто многоэтапна: рефакторинг через 20 файлов, создание функциональности в рамках одного сеанса, отладка через несколько коммитов. Без точек сохранения одна ошибка может привести к потере всего предыдущего прогресса.

В тот момент произошло следующее: при выполнении задачи по реконструкции из 6 шагов ошибка возникла на 4-м шаге. Когда я обнаружил её, Claude уже продолжил выполнение 5-го и 6-го шагов, основываясь на ошибочном состоянии. На устранение проблемы ушло больше времени, чем на выполнение всей задачи заново. Если бы были контрольные точки, ошибку можно было бы выявить уже на 4-м шаге.

В кодовой базе с уже сложившейся моделью Claude предпочитает вводить свой собственный стиль. Даже если его стиль «лучше», введение второй модели само по себе хуже, чем любая одна модель.

В тот момент Клод внедрил хуки в кодовую базу React, основанную на классовых компонентах. Код действительно работал, но он нарушил существующую модель тестирования, так как тесты зависели от componentDidMount. В итоге на удаление и переписывание ушло полдня.

Самые дорогие неудачи Клода — это те, которые выглядят как успехи. Функция «работает», но возвращает неверные данные; миграция «завершена», но пропустила 30 записей; тест «прошел», но только потому, что утверждение само по себе неверно.

В тот момент Клод заявил, что миграция базы данных «успешно завершена». На самом деле она тихо пропустила 14% записей, вызвавших конфликт с триггерными ограничениями. Это поведение было зафиксировано в журнале, но не было явно указано. Только через 11 дней, когда данные отчетов начали проявлять аномалии, мы обнаружили проблему.

В течение 6 недель я отслеживал одну и ту же группу из 50代表性 задач, охватывающих 30 репозиториев, и тестировал три конфигурации.

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

Соблюдение — это вероятность, с которой Claude явно применяет правило, когда оно применимо.

Интересный результат заключается не только в снижении ошибок с 41% до 3%. Более важно то, что при расширении с 4 правил до 12 правил нагрузка на соблюдение практически не увеличилась: уровень соблюдения снизился лишь с 78% до 76%, но уровень ошибок упал еще на 8 процентных пунктов. Новые правила охватывают модели сбоев, которые не покрывались первыми четырьмя правилами, и они не конкурируют за один и тот же бюджет внимания.

Где шепотом перестанет работать шаблон Карпати

Даже без добавления новых правил, исходные 4 шаблона правил недостаточны как минимум в 4 местах.

Во-первых, длительные задачи агента.
Правила Карпати в основном направлены на момент, когда Клод пишет код. Но что происходит, когда Клод выполняет многоэтапный конвейер? В исходном шаблоне отсутствуют правила бюджета, правила контрольных точек и правило «громкого сбоя». В результате конвейер постепенно отклоняется.

Во-вторых, согласованность нескольких репозиториев.
По умолчанию «соответствие существующему стилю» подразумевает только один стиль. Но в монорепозитории с 12 сервисами Claude должен выбрать, какому именно стилю соответствовать. Исходные правила не объясняют ему, как делать выбор. В результате он либо выбирает случайным образом, либо равномерно смешивает несколько стилей.

Третье, качество тестирования.
«Исполнение с ориентацией на цель» рассматривает «прохождение теста» как успех, но не указывает, что сам тест должен быть значимым. В результате Claude пишет тесты, которые почти ничего не проверяют, но заставляют его ошибочно считать, что он уверен в себе.

Четвертое, различия между производственной средой и этапом прототипирования.
Те же четыре правила могут предотвратить чрезмерную сложность производственного кода, но также могут замедлить разработку прототипов, поскольку на этапе прототипирования иногда действительно необходимы 100 строк экспериментального каркаса для определения направления. Принцип «простота прежде всего» Карпацки легко чрезмерно срабатывает в раннем коде.

Эти восемь новых правил не заменяют исходные четыре правила Карпати, а дополняют их недостатки: исходный шаблон был разработан для сценариев написания кода с автозаполнением, характерных для января 2026 года; к маю 2026 года Claude Code перешел в среду, управляемую агентами, с многошаговым взаимодействием и сотрудничеством между несколькими репозиториями кода — проблемы, с которыми они сталкиваются, различны.

Какие методы не сработали?

Перед окончательным утверждением этих 12 правил я также пробовал другие варианты.

Присоединяйтесь к правилам, которые я увидел на Reddit / X.
Большинство из них либо просто повторяли оригинальные четыре правила Карпати другими словами, либо были специфичными для области правилами, которые нельзя обобщить, например, «всегда используйте классы Tailwind». В конце концов, все они были удалены.

Более 12 правил.
Я протестировал максимум 18 пунктов. После 14 пунктов соблюдаемость упала с 76% до 52%. Ограничение в 200 строк — реальное. После этого длины Claude начинает применять шаблонное сопоставление «здесь есть правила», а не читать правила построчно.

Rules that depend on the existence of certain tools.
Например, «всегда используйте eslint» — если в проекте не установлен eslint, это правило перестаёт работать, причём тихо. Позже я изменил его на формулировку, не зависящую от конкретного инструмента: вместо «используйте eslint» я написал «следуйте стилю, уже принятому в кодовой базе».

Приведите примеры в CLAUDE.md, а не правила.
Примеры занимают больше контекста, чем правила. Три примера потребляют примерно столько же контекста, сколько десять правил, и Claude легко переобучается на примерах. Правила являются абстрактными, а примеры — конкретными. Поэтому следует использовать правила.

Будьте осторожны. Подумайте внимательно. Сосредоточьтесь.
Это весь шум. Уровень соблюдения таких инструкций упал примерно до 30%, поскольку их невозможно проверить. Позже я заменил их на более конкретные императивные правила, например: «Четко указывайте предположения».

Скажите Клауду, чтобы он вел себя как «опытный инженер».
Это не помогает. Claude и так считает себя опытным инженером. Проблема не в том, считает ли он себя таковым, а в том, выполняет ли он так. Императивные правила могут сократить этот разрыв, а идентичностные подсказки — нет.

Полная версия CLAUDE.md из 12 правил

Вот полная версия, которую можно сразу скопировать и вставить.

Этот контент не может быть отображен вне документа Feishu

Сохраните его как CLAUDE.md в корне репозитория. Под этими 12 правилами добавьте правила, специфичные для проекта, такие как стек технологий, команды тестирования, шаблоны ошибок и т.д. Общий объем не должен превышать 200 строк — после этого соблюдение правил значительно снижается.

Как установить

Два шага:

1. Добавьте четыре базовых правила Карпати в ваш файл CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. Вставьте правила 5–12 из этой статьи ниже

Сохраните файл в корне репозитория. Знак >> здесь очень важен — он добавляет содержимое в существующий файл CLAUDE.md, а не перезаписывает уже написанные вами правила проекта.

CLAUDE.md — это не список желаний, а договор о поведении, предназначенный для устранения конкретных моделей неудач, которые вы уже наблюдали.

Каждое правило должно отвечать на вопрос: оно предотвращает какую ошибку?

Четыре правила Карпати — это защита от моделей неудач, которые он увидел в январе 2026 года: молчаливые допущения, чрезмерное усложнение, несвязанное разрушение, слабые критерии успеха. Это основы, не пропускайте их.

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

Конечно, конкретный эффект индивидуален. Если вы не используете многошаговый пайплайн, правило 10 для вас менее важно. Если ваш кодбаза имеет единый стиль, который уже принудительно соблюдается линтером, правило 11 избыточно. Прочитав эти 12 правил, оставьте только те, которые действительно соответствуют ошибкам, которые вы действительно допускали, и удалите остальные.

Версия CLAUDE.md с 6 правилами, адаптированными под реальные модели сбоев, лучше, чем версия с 12 правилами, из которых 6 вы никогда не используете.

Заключение

Твит Карпати от января 2026 года по сути был жалобой. Форрест Чанг превратил его в 4 правила. В итоге 120 000 разработчиков поставили звездочку этому результату. И большинство из них до сих пор используют только эти 4 правила.

Модели продвинулись, экосистема изменилась. Многошаговые агенты, цепочки активации hook, загрузка навыков, совместная работа с несколькими репозиториями кода — всего этого не существовало на момент публикации того твита Карпати. Исходные четыре правила не решают эти проблемы. Они не ошибочны, они просто неполны.

Добавлено 8 новых правил. 6 недель, охватывающих тестирование 30 репозиториев. Ошибка снизилась с 41% до 3%.

Сохраните эту статью на tonight и скопируйте эти 12 правил в ваш CLAUDE.md. Если они помогут вам сэкономить неделю экспериментов с Claude, поделитесь.