4 правила Karpathy в CLAUDE.md: разбор файла с 179K звёзд (2026)

Один файл CLAUDE.md на 70 строк собрал 179K звёзд на GitHub и попал в топ-35 всех репозиториев. Внутри ноль кода и всего 4 поведенческих правила, выведенных из наблюдений Андрея Карпаты. Кладёшь файл в корень проекта, и Claude Code подгружает эти правила в каждый запрос, снимая четыре типовых провала ИИ-агента: тихие догадки, переусложнение, лишние правки и работу без проверки.

Разберём каждое правило по отдельности: что оно значит, как выглядит запрос до и после, что копировать дословно, а что переписать под себя. Заодно честно про то, где эти правила мешают, и как за пять минут проверить, помог ли файл именно твоему Claude Code. Это узкий разбор конкретного файла. Если сначала хочешь понять, как вообще устроен CLAUDE.md и как собрать свой с нуля, база лежит в гайде как настроить CLAUDE.md, а тут мы копаем один популярный пример.

Что за файл и откуда 179K звёзд

Это один CLAUDE.md на 70 строк в репозитории multica-ai/andrej-karpathy-skills. Ноль кода, ноль зависимостей, лицензия MIT. Кладёшь файл в корень своего проекта, и Claude Code подгружает 4 поведенческих правила в каждый запрос.

По состоянию на 19 июня 2026 репозиторий набрал около 179K звёзд и 18.3K форков. Чистый рост от нуля до топ-35 GitHub за пять месяцев.

Внутри буквально четыре файла: сам CLAUDE.md на 70 строк, CURSOR.md с тем же текстом под формат .cursorrules, EXAMPLES.md с восемью сценариями до и после, и README.md плюс китайский перевод. Установка простая: скопировать CLAUDE.md в корень проекта или поставить через Claude Code как плагин.

Звёзды росли так. Репозиторий запущен 27 января 2026. К маю на зеркальном аккаунте multica-ai плюс личном репозитории автора суммарно набралось около 220K звёзд (это цифра TechTimes от 18 мая 2026). К 19 июня только на multica-ai уже 179K, в рейтинге Star History это примерно 35-е место среди всех репозиториев GitHub. Рост оказался быстрее, чем у официальных Anthropic Skills в тот же период.

Кто реально написал этот файл: Karpathy или Forrest Chang

Важная деталь для точности. Файл написал не Карпаты. Автор это разработчик Forrest Chang, он распаковал в правила то, что Карпаты опубликовал в X. Сам Карпаты репозиторий публично не одобрял и не комментировал. Правила выведены из наблюдений признанного эксперта, но по сути это интерпретация одного человека, а собственного авторского фреймворка Карпаты тут нет.

26 января 2026 Карпаты опубликовал пост в X о том, как за пару недель перевернулась пропорция его работы:

В ноябре я писал 80% кода руками с автокомплитом и 20% через агентов. За пару недель эта пропорция перевернулась: теперь 80% кода пишут агенты, а я делаю 20% правок и доводки.

- Andrej Karpathy, пост в X

В том же треде Карпаты перечислил, что больше всего бесит в работе с агентами: тихие предположения, переусложнение архитектуры на ровном месте, попутный рефакторинг в задачах про багфикс, размытые формулировки задачи. На следующий день, 27 января, Forrest Chang выписал эти жалобы в один файл из 4 правил и опубликовал репозиторий. В README автор формулирует прямо: файл выведен из публичных наблюдений Карпаты, он не автор репозитория и не подтверждал его как свой.

Дальше по тексту я называю правила «4 правила Karpathy» для краткости. Но держи в голове атрибуцию: формулировки принадлежат Forrest Chang, наблюдения Карпаты.

Правило 1. Думай до того, как пишешь код

Слоган правила короткий:

Не догадывайся. Не скрывай непонимание. Покажи компромиссы.

- CLAUDE.md, репозиторий multica-ai

Раскрывается оно четырьмя подпунктами. Явно проговорить предположения и спросить, если не уверен. Показать несколько вариантов интерпретации задачи вслух вместо того, чтобы молча выбрать один. Назвать более простой путь и защитить его, если он есть. Остановиться и сказать «не понимаю», когда формулировка размыта. Это про честность до начала кода.

Возьмём пример из EXAMPLES.md. Запрос: «Добавь функцию экспорта пользователей». Без правила Claude молча генерит код, который выгружает всех юзеров в захардкоженный путь. Что за формат, CSV или JSON, какие поля включать, что делать с персональными данными, что с пагинацией на 100 тысяч записей, агент не спрашивает. С правилом первый ответ выглядит иначе. Сначала идут вопросы: какой объём выгрузки, куда отдавать, какие поля чувствительные, нужны ли фильтры. И только когда ответы получены, агент пишет одну простую функцию под конкретный сценарий.

Второй пример. Запрос: «Сделай поиск быстрее». Без правила Claude молча выбирает один из трёх путей: ставит кэширование, добавляет индекс или переводит в async. Через час оказывается, что нужен был другой. Например, проблема в пропускной способности на пиках, а кэширование ускоряет отклик на одиночный запрос и эту проблему не закрывает. С правилом агент спрашивает: «Что именно ускорить, задержку, пропускную способность или ощущение скорости? Для каждого варианта прикину объём работы». И без этого вопроса дальше не идёт.

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

Правило 2. Сначала простота, без запаса на «вдруг»

Оригинальный слоган:

Минимум кода, который решает задачу. Ничего на запас.

- CLAUDE.md, репозиторий multica-ai

Запреты под ним такие. Не добавлять фичи, которых не просили. Не строить абстракции для кода, который используется один раз. Не закладывать «гибкость на будущее» и конфигурируемость, которая не нужна сейчас. Не писать обработку ошибок для сценариев, которые физически не могут случиться. А финальный тест простой: senior-разработчик сказал бы, что тут переусложнено? Если да, переписать.

Канонический пример это запрос «Добавь функцию расчёта скидки». Без правила Claude собирает паттерн Strategy с базовым классом, тремя реализациями, перечислением для типов скидок, отдельной структурой для конфига и фабрикой. Тридцать с лишним строк обвязки, прежде чем появится первая логика. С правилом это одна функция: принимает товар и купон, возвращает сумму. Четыре строки. Когда появится второй тип скидки, тогда и появится Strategy.

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

Это правило ловит главную болезнь ИИ-агентов: они накладывают выученные паттерны на всё подряд. Видит «настройки», значит, точно нужен кэш. Видит «расчёт», значит, Strategy. А по факту 90% бизнес-кода живёт одной функцией, и Strategy там никогда не появится.

Правило 3. Хирургические правки: только то, что просили

Слоган:

Трогай только то, что нужно. Убирай только свой мусор.

- CLAUDE.md, репозиторий multica-ai

Правила правки такие. Не улучшать соседний код, комментарии, форматирование. Не рефакторить то, что и так работает. Сохранять текущий стиль: кавычки, отступы, типы. Не удалять мёртвый код, который ты не создал, только упомянуть его в выводе. Из удалений можно только то, что осиротело именно из-за твоих правок: импорт, переменная или функция стали не нужны после твоего изменения. Это про дисциплину «один pull request, одна задача».

Первый пример. Запрос: «Почини баг, когда пустой email ломает валидатор». Без правила Claude чинит баг, попутно усиливает валидацию для других кейсов, добавляет проверку username, переписывает описание функции. С правилом меняет ровно те строки, где обрабатывается пустой email. Всё остальное не трогает.

Второй пример. Запрос: «Добавь логирование в функцию загрузки». Без правила Claude меняет одинарные кавычки на двойные, потому что так «правильнее», добавляет подсказки типов везде по дороге, переформатирует пробелы. Получается diff на 80 строк там, где нужно было 3. С правилом это только три строки логирования, а кавычки и стиль остаются как у автора файла.

Правило особенно полезно, когда работаешь в большом репозитории, который писали разные люди. Стиль внутри файла это договор предыдущего автора со своим прошлым «я». Агент, который случайно переписывает кавычки, ломает git blame, добавляет мёртвые конфликты в историю и заставляет тратить время на review.

Правило 4. Цель и проверка вместо «сейчас сделаю»

Слоган:

Определи критерий успеха. Зацикливай, пока не подтвердил.

- CLAUDE.md, репозиторий multica-ai

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

Первый пример. Запрос: «Почини авторизацию». Без правила Claude отвечает «сейчас посмотрю код, найду проблемы, улучшу, протестирую». Это описание процесса, в нём нет проверяемой цели. С правилом первый ответ это вопрос: «Что именно не работает? Например, после смены пароля юзер остаётся залогинен, хотя должен разлогиниваться. Подтверди, и я напишу тест, который ловит этот сценарий, потом починю».

Второй пример. Запрос: «Добавь ограничение частоты запросов на API». Без правила Claude пишет полную систему: Redis, несколько стратегий, конфиг на каждый endpoint, триста строк за один коммит. С правилом это инкременты с проверкой. Шаг первый: лимит в памяти на один endpoint, проверка через curl. Шаг второй: вынести в middleware, прогнать тесты. Шаг третий: добавить бэкенд на Redis, замерить задержку. Шаг четвёртый: конфиг на каждый endpoint. Каждый шаг проверяется до перехода к следующему.

Третий пример. Запрос: «Почини сортировку, ломается на дубликатах». Без правила Claude меняет логику сортировки сразу. С правилом сначала пишет тест, который воспроизводит баг (две записи с одинаковым счётом меняются местами при пересортировке), потом переводит на устойчивую сортировку с вторичным ключом по имени, и проверяет, что тест проходит стабильно.

Это самое полезное правило для длинных задач. Claude любит «исправить всё разом» и приносит 300 строк, в которых половина рабочая, четверть ломает соседнее, четверть не имеет отношения к задаче. С правилом 4 он по своей воле дробит работу на проверяемые куски. По сути это ручной контекст-инжиниринг внутри одного правила, а полную картину этой дисциплины разбирает гайд контекст-инжиниринг: что это.

Чем правила Karpathy отличаются от Skills и SKILL.md от Anthropic

Тут путаница возникает часто, поэтому разведём аккуратно. Skills это формат от Anthropic: папка с SKILL.md плюс инструментами и скриптами, которую Claude подгружает в контекст только по триггеру из поля description. Правила Karpathy это один CLAUDE.md, который висит в каждом запросе. Skills про предметные области: PDF, Excel, документация. Правила Karpathy про базовое поведение модели. Это разные слои, и они не заменяют друг друга.

Главные отличия удобно смотреть в таблице.

Параметр	Правила Karpathy	Skills от Anthropic
Формат	один CLAUDE.md	папка .claude/skills/[имя]/ с SKILL.md плюс скрипты
Загрузка	в каждом запросе	только по триггеру из description
Сложность	70 строк, ноль кода	от 200 строк, можно с Python или Bash
Что регулирует	базовое поведение модели	конкретные предметные навыки
Сколько на проект	один	десятки
Источник	community, multica-ai/andrej-karpathy-skills	официальный, anthropics/skills

Параллельно есть формат AGENTS.md, попытка сделать единый файл инструкций для нескольких инструментов сразу: Claude Code, Codex, Cursor. Правила Karpathy заложили в свой репозиторий файл CURSOR.md рядом с CLAUDE.md именно поэтому: чтобы один и тот же текст работал в нескольких редакторах.

Если коротко: правила Karpathy и Skills не конкурируют. Первое это фундамент. Второе это комнаты, которые на этом фундаменте строишь. На живом проекте оба слоя работают одновременно.

Что копировать в свой CLAUDE.md как есть, а что переписать под себя

Готовая рекомендация без воды. Слоганы четырёх правил копируй дословно, переводом: они короткие, точные, работают. Подпункты под каждым правилом (по три-четыре строки) тоже работают как есть. Финальный senior-тест «спроси у себя, переусложнено или нет» бери целиком.

А вот все восемь сценариев из EXAMPLES.md не копируй. Они написаны под абстрактные API и валидаторы и не отражают твою предметную область. Возьми две-три ситуации из своих последних коммитов, где Claude переусложнил или сделал лишнее, и опиши их в формате «было и как должно было быть». Это даёт модели конкретный материал из твоей собственной практики вместо абстрактных чужих кейсов.

Раздел про критерии успеха тоже стоит переписать. Karpathy предлагает связку «падающий тест, потом фикс, потом проверка». Это отлично работает для библиотек. Для бизнес-логики (письма, оплата, рассылки) ты, скорее всего, проверяешь по другим критериям: «письмо приходит на тестовый адрес», «webhook возвращает 200», «в базе появилась запись». Пропиши в файле именно свои критерии проверки.

И добавь поверх пару вещей, которых у Karpathy нет. Первое: список инструментов, которые в твоём проекте уже стоят. Claude должен знать, что платёжка у тебя, например, Yandex Pay, а хостинг через Coolify. Без этого модель по умолчанию потянет из тренировочных данных Stripe и Vercel и напишет код под чужой набор инструментов. Второе: запреты на конкретные библиотеки. Строка вроде «не использовать moment.js, у нас date-fns» снимает несколько повторных правок в неделю. Как правильно раскладывать такие правила и папки по проекту, разбирает гайд каркас проекта для вайбкодинга.

Где правила Karpathy перестают работать

Честно про границы: не во всех ситуациях правила полезны. Есть три случая, когда CLAUDE.md с правилами Karpathy стоит отключить.

Первый это быстрые одноразовые скрипты. Когда нужно за десять минут выгрузить данные из прод-базы и нарисовать график, диалог «уточни предположения» только мешает. Тут нужен один запрос к базе и один короткий скрипт, без трёх итераций уточнений. Для таких задач держи отдельную папку без CLAUDE.md в ней.

Второй это прототипы для проверки гипотез. Иногда правило «никаких абстракций впрок» мешает. Если заранее знаешь, что через неделю прототип превратится в реальный продукт, лёгкая обобщённость бывает полезной: вынести модели в отдельный файл, поставить базовый ORM. С правилом Karpathy всё это придётся каждый раз обосновывать по логике «докажи, что структура нужна уже сейчас», и это превращается в лишний спор с агентом.

Третий это сложные дискуссии «как лучше архитектурно». Правило 1 требует либо задать уточняющий вопрос, либо предложить варианты. В обсуждении архитектуры это даёт зацикливание: агент задаёт вопрос, ты отвечаешь, он задаёт ещё один. Для таких задач удобнее переключиться в Plan Mode и работать без этого файла. И на код-ревью чужого кода правила не работают вообще: они заточены под написание кода, а разбор готового живёт по другим законам.

Какие правила добавить поверх Karpathy для своих проектов

Karpathy дал базовые правила про поведение модели. Поверх них имеет смысл положить свои, про твой собственный контекст работы. Несколько примеров, которые снимают повторяющиеся правки.

«Никогда не использовать длинное тире, только дефис» это текстовое правило для контентных задач. Длинное тире один из главных маркеров «писано ИИ», и агент ставит его по привычке. «Не хардкодить даты и цены, всегда брать из базы» это предметное правило: если у тебя даты и цены меняются по два раза в месяц, любой хардкод протухает через неделю. «При любой работе с прод-базой сначала бэкап, потом операции, не делать UPDATE без LIMIT» это инфраструктурная страховка от случайного сноса данных. «Не использовать Stripe в примерах, проект на другом платёжном сервисе» это правило, которое убирает неверные параллели из тренировочных данных модели.

В этом и есть смысл живого файла: CLAUDE.md превращается из набора чужих правил в твой собственный документ, который накапливает каждую ошибку Claude как новую строку. Через месяц активной работы файл вырастает с 70 строк до 200-300, и при этом каждая строка это конкретный провал, который ты больше не хочешь видеть. Про сам приём «ошибка агента становится строкой» и про то, как держать файл коротким, подробно в базовом гайде как настроить CLAUDE.md.

5 минут проверки: помог ли этот CLAUDE.md твоему Claude Code

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

1. Создай чистую папку для эксперимента и скопируй в неё реальный код, на котором Claude недавно ошибался.
2. Запусти Claude Code без файла Karpathy. Дай ту же задачу. Сохрани вывод.
3. Положи в корень CLAUDE.md из репозитория multica-ai. Запусти Claude Code заново на той же задаче.
4. Сравни оба ответа по четырём пунктам.

Пункты для сравнения такие. В первой реплике появился вопрос до кода (правило 1)? Решение стало короче и проще (правило 2)? Меньше попутных правок в соседнем коде (правило 3)? Есть критерий проверки результата (правило 4)? Если хотя бы по двум критериям второй вариант лучше, копируй файл в основной проект. Если нет, значит, у твоего Claude Code другой узкий участок, который этот файл не закрывает.

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

Где живёт CLAUDE.md в большой системе

Частый вопрос звучит так: «У меня настроен CLAUDE.md, но Claude всё равно галлюцинирует». Ответ почти всегда один. Правила Karpathy закрывают только базовое поведение модели, а стабильность собирается из нескольких слоёв сразу: правила поведения в CLAUDE.md, память проекта и бизнес-контекст рядом с ним, дисциплина подготовки контекста через Plan Mode и сжатие истории. Один файл без остальных слоёв работает процентов на тридцать своей мощности.

Поэтому дальше есть два пути. Либо копируй CLAUDE.md Karpathy в свой проект прямо сейчас и прогони пятиминутный протокол, чтобы увидеть эффект своими глазами. Либо иди собирать систему целиком: карту того, что вообще умеет инструмент, удобно смотреть по гайду 7 уровней Claude Code, а сам файл правил это один кирпич из уровня про память и контекст.

Чек-лист: что у тебя теперь есть

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

• Понимаешь, что файл собрал Forrest Chang по публичным наблюдениям Карпаты, и сам Карпаты его не писал.
• Знаешь все 4 правила и что каждое из них лечит в поведении агента.
• Скопировал в свой CLAUDE.md четыре слогана и подпункты дословно, переводом.
• Выкинул восемь чужих примеров и заменил их двумя-тремя своими провалами прошлой недели.
• Переписал критерии успеха под свою нишу: тестовый адрес, webhook, запись в базе вместо стандартного падающего теста.
• Добавил поверх список своих инструментов и запреты на конкретные библиотеки.
• Помнишь три случая, где файл стоит отключить: одноразовые скрипты, прототипы, архитектурные обсуждения.
• Прогнал пятиминутный протокол проверки на реальной задаче и решил, оставлять файл или нет.
• Не положил в файл ни одного секрета, ключа или пароля.

Дальше правило одно: слоганы Karpathy это готовый фундамент, а всё, что делает файл по-настоящему твоим, ты дописываешь сам, по одной строке после каждой ошибки агента. Через пару недель чужой популярный файл превращается в твой собственный документ, к которому Claude реально обращается в начале каждой сессии.