Примечание редактора: В январе 2026 года жалоба Андрея Карпати на код, генерируемый Claude, привела к появлению, казалось бы, небольшого, но критически важного для рабочего процесса программирования с ИИ файла: CLAUDE.md. Форрест Чанг затем свел эти проблемы к 4 правилам поведения, пытаясь ограничить типичные ошибки Claude при написании кода: молчаливые допущения, чрезмерное усложнение, порча несвязанного кода и отсутствие четких критериев успеха.
Но спустя несколько месяцев сценарии использования Claude Code перестали ограничиваться просто «заставить модель написать фрагмент кода». По мере того, как многозадачные агенты, цепочки триггеров хуков, конфликты загрузки навыков и межрепозиторное взаимодействие стали нормой, начали появляться и новые шаблоны ошибок: модель теряет контроль в длительных задачах, тесты проходят, но логика не проверяется, миграция завершается, но ошибки игнорируются, смешиваются несовместимые стили кода.
Автор этой статьи в течение 6 недель протестировал 30 репозиториев и добавил 8 новых правил к исходным 4 правилам Карпати, пытаясь охватить новые проблемы, возникшие при переходе от единичных компиляций к агент-ориентированному сотрудничеству в ИИ-программировании.
Ниже представлен оригинал статьи:
В конце января 2026 года Андрей Карпати опубликовал серию твитов, критикуя способ написания кода Claude. Он выделил три типичные проблемы: молчаливые ложные допущения, излишнее усложнение и внесение несвязанных изменений в код, который не должен был меняться.
Форрест Чанг увидел эту ветку и сформулировал жалобы в виде 4 правил поведения, записав их в отдельный файл CLAUDE.md и опубликовав на GitHub. В первый же день проект набрал 5,828 звезд, за две недели был добавлен в закладки 60,000 раз, а сегодня у него уже 120,000 звезд, что делает его самым быстрорастущим однодокументным репозиторием 2026 года.
Затем я в течение 6 недель тестировал его на 30 репозиториях.
Эти 4 правила действительно работают. Ошибки, которые раньше возникали с вероятностью около 40%, в задачах, подходящих для этих правил, снизились до уровня менее 3%. Проблема в том, что этот шаблон изначально был создан для решения ошибок, которые Claude допускал при написании кода в январе.
К маю 2026 года экосистема Claude Code столкнулась с другими проблемами: конфликты между агентами, цепочки вызовов хуков, конфликты загрузки навыков и сбои в многоэтапных рабочих процессах, распределенных между сессиями.
Поэтому я добавил еще 8 правил. Ниже представлена полная версия CLAUDE.md с 12 правилами: объяснение, почему каждое из них стоит добавить, и в каких 4 случаях исходный шаблон Карпати незаметно дает сбой.
Если хотите пропустить объяснения и сразу скопировать файл для использования, полная версия находится в конце статьи.
Почему это важно
CLAUDE.md для Claude Code — самый недооцененный файл во всем стеке технологий ИИ-программирования. Большинство разработчиков обычно допускают три типа ошибок:
Во-первых, превращают его в свалку предпочтений, засовывая туда все свои привычки, пока он не раздуется до 4000+ токенов, а процент соблюдения правил не упадет до 30%.
Во-вторых, вообще не используют его, каждый раз создавая промпт заново. Это приводит к 5-кратной трате токенов и отсутствию согласованности между сессиями.
В-третьих, копируют шаблон и больше к нему не возвращаются. Он может работать пару недель, но по мере изменения кодовой базы он перестает работать незаметно для вас.
Официальная документация Anthropic четко говорит: CLAUDE.md по сути носит рекомендательный характер. Claude следует ему примерно в 80% случаев. После превышения 200 строк процент соблюдения заметно падает, потому что важные правила тонут в шуме.
Шаблон Карпати решает эту проблему: один файл, 65 строк, 4 правила. Это минимальный базис.
Но потолок можно поднять. Добавив следующие 8 правил, вы покрываете не только проблемы написания кода, на которые жаловался Карпати в январе 2026, но и проблемы координации агентов, появившиеся к маю 2026 — те, которых еще не существовало, когда создавался оригинальный шаблон.
Исходные 4 правила
Если вы еще не видели репозиторий Форреста Чанга, вот базовая версия:
Правило 1: Подумай перед кодированием.
Не делай молчаливых допущений. Озвучивай свои предположения, раскрывай компромиссы. Спрашивай, прежде чем догадываться. Если есть более простое решение, высказывайся против сложного.
Правило 2: Простота прежде всего.
Используй минимальный код, решающий задачу. Не добавляй воображаемые функции. Не проектируй слои абстракции для одноразового кода. Если опытный инженер сочтет это излишне сложным — упрощай.
Правило 3: Хирургические правки.
Меняй только то, что необходимо. Не «оптимизируй» соседний код, комментарии или форматирование просто так. Не рефактори то, что не сломано. Соблюдай существующий стиль.
Правило 4: Выполняй, ориентируясь на цель.
Сначала определи критерии успеха, затем итеративно работай, пока не завершишь проверку. Не говори Claude, что делать на каждом шаге, скажи, каким должен быть успешный результат, и позволь ему итерировать самостоятельно.
Эти 4 правила решают примерно 40% шаблонов сбоев, которые я видел в сессиях Claude Code без присмотра. Остальные ~60% проблем скрываются на следующих белых пятнах.
Мои 8 новых правил и их причины
Каждое правило родилось из реального момента, когда исходных 4 правил Карпати стало недостаточно. Я опишу ситуацию, а затем дам соответствующее правило.
Правило 5: Не заставляй модель выполнять неязыковую работу
В правилах Карпати этого нет. В результате модель начала принимать решения, которые должны были обрабатываться детерминированным кодом: повторять ли вызов API, как маршрутизировать сообщение, когда эскалировать обработку. Итог: решение менялось каждую неделю. Вы получаете нестабильный if-else, тарифицируемый по $0.003 за токен.
Момент был таков: код вызывал Claude, чтобы «решить, стоит ли повторять попытку при получении 503 ошибки». Сначала все работало хорошо, две недели подряд, потом внезапно стало нестабильно, потому что модель начала использовать тело запроса как контекст для решения. Стратегия повторов стала случайной, потому что промпт сам по себе был случайным.
Правило 6: Установи жесткий бюджет токенов, без исключений
CLAUDE.md без бюджетных ограничений — это чистый чек. Каждая итерация может выйти из-под контроля и превратиться в сброс контекста на 50,000 токенов. Модель сама не остановится.
Момент был таков: сессия отладки длилась 90 минут. Модель постоянно итеративно работала над одним и тем же 8КБ сообщением об ошибке, постепенно забывая, какие исправления уже пробовала. В конце концов, она начала предлагать решения, которые я отверг 40 сообщений назад. Если бы был бюджет токенов, процесс должен был быть остановлен на 12-й минуте.
Правило 7: Обнажай конфликты, не усредняй их
Когда две части кодовой базы противоречат друг другу, Claude пытается угодить обеим, и в итоге пишет несвязный код.
Момент был таков: в репозитории существовало две парадигмы обработки ошибок — одна с явным async/await + try/catch, другая с глобальными границами ошибок. Новый код от Claude использовал обе. Обработка ошибок выполнялась дважды. Потребовалось 30 минут, чтобы понять, почему ошибка проглатывалась дважды.
Правило 8: Сначала прочти, потом пиши
Правило Карпати «Хирургические правки» говорит Claude не трогать соседний код. Но оно не говорит Claude: сначала пойми соседний код. Без этого Claude напишет новый код, который конфликтует с существующим кодом в 30 строках от него.
Момент был таков: Claude добавил новую функцию прямо рядом с существующей, которая делала то же самое, потому что не прочитал исходную функцию. Обе функции выполняли одну задачу. Но из-за порядка импорта новая перезаписала старую, которая была де-факто стандартом уже 6 месяцев.
Правило 9: Тесты не опциональны, но тестирование не цель
Правило Карпати «Выполняй, ориентируясь на цель» подразумевает, что тесты могут быть критерием успеха. Но на практике Claude воспринимает «прохождение тестов» как единственную цель и пишет код, который проходит поверхностные тесты, но ломает что-то еще.
Момент был таков: Claude написал 12 тестов для функции аутентификации — все прошли. Но логика аутентификации в продакшене сломалась. Тесты проверяли только, что функция «что-то возвращает», а не то, что она возвращает правильное. Функция проходила тесты, потому что возвращала константу.
Правило 10: Долгоиграющие операции требуют контрольных точек
Шаблон Карпати предполагает одноразовое взаимодействие. Но реальная работа с Claude Code часто многоэтапна: рефакторинг 20 файлов, построение фичи в одной сессии, отладка через несколько коммитов. Без контрольных точек один неверный шаг — и весь предыдущий прогресс может быть потерян.
Момент был таков: 6-шаговая задача рефакторинга дала сбой на шаге 4. Когда я это обнаружил, Claude уже завершил шаги 5 и 6 поверх ошибочного состояния. Разбор и исправление заняли больше времени, чем переделка всей задачи с нуля. С контрольной точкой проблема была бы обнаружена на шаге 4.
Правило 11: Соглашения важнее новизны
В репозитории с устоявшимися шаблонами Claude любит привносить свои. Даже если его вариант «лучше», внедрение второго подхода само по себе хуже любого единого подхода.
Момент был таков: Claude внедрил хуки в React-репозиторий, основанный на class components. Код действительно работал. Но он сломал существующую модель тестирования в репозитории, потому что тесты зависели от componentDidMount. В итоге потребовалось полдня, чтобы удалить и переписать его.
Правило 12: Явные сбои, а не тихие
Самые дорогие сбои Claude — те, что выглядят как успех. Функция «работает», но возвращает неверные данные; миграция «завершена», но пропустила 30 записей; тест «пройден», но только потому что само утверждение было неверным.
Момент был таков: Claude сообщил, что миграция базы данных «успешно завершена». На самом деле, она тихо пропустила 14% записей, вызвавших конфликт ограничений. Пропуск был записан в лог, но явно не отражен в отчете. Через 11 дней, когда данные отчетов стали аномальными, мы обнаружили проблему.
Результаты данных
В течение 6 недель я отслеживал один и тот же набор из 50 репрезентативных задач в 30 репозиториях, тестируя три конфигурации.
Процент ошибок означает: задачу необходимо было скорректировать или переписать, чтобы она соответствовала исходному замыслу. Учитываемые ошибки включают: тихие ложные допущения, излишнее усложнение, несвязанные повреждения, тихие сбои, нарушение соглашений, усреднение конфликтов, пропуск контрольных точек.
Процент соблюдения означает: когда правило применимо, с какой вероятностью Claude явно его применит.
По-настоящему интересный результат не только в том, что процент ошибок упал с 41% до 3%. Важнее, что расширение с 4 до 12 правил практически не увеличило нагрузку на соблюдение — процент упал всего с 78% до 76%, но процент ошибок снизился еще на 8 пунктов. Новые правила покрывают шаблоны сбоев, которые не обрабатывались исходными 4 правилами, они не конкурируют за один и тот же бюджет внимания.
Где шаблон Карпати незаметно дает сбой
Даже без добавления новых правил исходный шаблон из 4 правил недостаточен по меньшей мере в 4 аспектах.
Во-первых, долгие задачи агентов.
Правила Карпати ориентированы на момент, когда Claude пишет код. Но что происходит, когда Claude выполняет многоэтапный пайплайн? Исходный шаблон не содержит правил о бюджете, контрольных точках или «громких сбоях». В результате пайплайн постепенно дрейфует.
Во-вторых, согласованность между несколькими репозиториями.
«Соответствуй существующему стилю» предполагает один стиль. Но в монорепозитории с 12 сервисами Claude должен выбрать, какому именно стилю соответствовать. Исходные правила не говорят ему, как выбирать. В итоге он либо выбирает случайно, либо усредняет несколько стилей.
В-третьих, качество тестов.
«Выполняй, ориентируясь на цель» воспринимает «прохождение тестов» как успех, но не уточняет, что сами тесты должны быть содержательными. В итоге Claude пишет тесты, которые почти ничего не проверяют, но создают у него ложное чувство уверенности.
В-четвертых, разница между продакшеном и прототипированием.
Те же 4 правила могут предотвратить излишнее усложнение продакшен-кода, но также могут замедлить разработку прототипов. Потому что на этапе прототипа иногда действительно нужны 100 строк исследовательского кода, чтобы разобраться в направлении. Правило Карпати «Простота прежде всего» в раннем коде срабатывает слишком часто.
Эти 8 новых правил не заменяют исходные 4 правила Карпати, а дополняют их пробелы: исходный шаблон соответствует сценарию написания кода в стиле автодополнения, характерному для января 2026; к маю 2026 Claude Code уже вошел в среду, управляемую агентами, многоэтапную, с межрепозиторным взаимодействием, и проблемы в этих средах разные.
Что не сработало
Прежде чем окончательно утвердить эти 12 правил, я пробовал и другие подходы.
Добавление правил, увиденных на Reddit / X.
Большинство из них либо повторяли исходные 4 правила Карпати другими словами, либо были специфичными правилами для конкретных областей, которые не обобщались, например, «всегда используй классы Tailwind». В итоге все удалил.
Более 12 правил.
Я тестировал до 18. После 14 соблюдение упало с 76% до 52%. Лимит в 200 строк реален. После этой длины Claude начинает воспринимать это как «здесь есть правила», а не читать их по отдельности.
Правила, зависящие от наличия определенных инструментов.
Например, «всегда используй eslint». Как только проект не имеет установленного eslint, правило молча перестает работать. Позже я изменил его на формулировку, не зависящую от конкретного инструмента, например, заменил «используй eslint» на «следуй стилю, уже применяемому в репозитории».
Размещение примеров, а не правил, в CLAUDE.md.
Примеры съедают больше контекста, чем правила. Три примера потребляют примерно столько же контекста, сколько 10 правил, и Claude легко переобучается на примерах. Правила абстрактны, примеры конкретны. Поэтому следует использовать правила.
«Будь осторожен», «Подумай хорошенько», «Сосредоточься».
Это шум. Соблюдение таких инструкций упало примерно до 30%, потому что их нельзя проверить. Позже я заменил их на более конкретные императивные правила, например, «явно озвучивай допущения».
Говорить Claude, чтобы он вел себя как «опытный инженер».
Не работает. Claude и так считает себя опытным инженером. Настоящая проблема не в том, считает ли он так, а в том, действует ли он соответственно. Императивные правила сокращают этот разрыв, подсказки-идентичности — нет.
Полная версия CLAUDE.md с 12 правилами
Ниже представлена полная версия, готовая для копирования.
Временно не могу отобразить этот контент вне документа Lark
Сохраните его как CLAUDE.md в корне репозитория. Под этими 12 правилами добавьте специфичные для проекта правила, например, стек технологий, команды тестирования, шаблоны ошибок и т.д. Общий объем не должен превышать 200 строк, после этого процент соблюдения правил заметно падает.
Как установить
Всего два шага:
1. Добавьте 4 базовых правила Карпати в ваш CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
2. Вставьте правила 5–12 из этой статьи ниже
Сохраните файл в корне репозитория. Здесь >> очень важно — оно добавляет в существующий CLAUDE.md, а не перезаписывает уже написанные вами специфичные для проекта правила.
Ментальная модель
CLAUDE.md — не список пожеланий, а поведенческий контракт, призванный блокировать конкретные шаблоны сбоев, которые вы уже наблюдали.
Каждое правило должно отвечать на вопрос: от какой ошибки оно защищает?
4 правила Карпати защищают от шаблонов сбоев, которые он видел в январе 2026: молчаливые допущения, излишнее усложнение, несвязанные повреждения, слабые критерии успеха. Это основа, не пропускайте ее.
Мои 8 новых правил защищают от новых шаблонов сбоев, появившихся после мая 2026: агентские циклы без бюджетных ограничений, многоэтапные задачи без контрольных точек, тесты, которые кажутся проверяющими, но не проверяют ключевую логику, и проблема упаковки тихих сбоев в тихие успехи. Это инкрементальные патчи.
Конечно, результаты варьируются. Если вы не запускаете многоэтапные пайплайны, правило 10 для вас не так важно. Если ваш репозиторий имеет единый стиль, уже применяемый через линтеры, правило 11 избыточно. Прочитав эти 12 правил, оставьте те, что действительно соответствуют ошибкам, которые вы совершали, удалите остальные.
CLAUDE.md с 6 правилами, настроенными под реальные шаблоны ваших сбоев, лучше, чем версия с 12 правилами, 6 из которых вам никогда не понадобятся.
Заключение
Твит Карпати в январе 2026 года по сути был жалобой. Форрест Чанг превратил ее в 4 правила. В итоге 120,000 разработчиков поставили звезду этому результату. И большинство из них до сих пор используют только те 4 правила.
Модели эволюционировали, экосистема изменилась. Многоэтапные агенты, цепочки хуков, загрузка навыков, межрепозиторное взаимодействие — всего этого не существовало, когда Карпати писал тот твит. Исходные 4 правила не решают эти проблемы. Они не ошибочны, они неполны.
Добавьте 8 новых правил. 6 недель тестирования, 30 репозиториев. Процент ошибок упал с 41% до 3%.
Сохраните эту статью сегодня же, вставьте эти 12 правил в ваш CLAUDE.md. Если это сэкономит вам неделю борьбы с Claude, поделитесь статьей.
