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

Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, кейсы, ошибки. Подпишись, чтобы быть в курсе.

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

Репозиторий называется multica-ai/andrej-karpathy-skills. Внутри буквально 4 файла: CLAUDE.md (главный, 70 строк), CURSOR.md (то же самое под .cursorrules), EXAMPLES.md (8 сценариев до и после), README.md плюс китайский перевод. Установка - скопировать CLAUDE.md в корень проекта или поставить через Claude Code как плагин.

Звёзды росли так: запущен 27 января 2026, к маю на mirror-аккаунте multica-ai плюс личном репо Forrest Chang суммарно набралось 220K (это писал TechTimes 18 мая). К 19 июня только на multica-ai уже 179K, в Star History рейтинг №35 среди всех GitHub-репозиториев. Это быстрее, чем выстреливали Anthropic Skills (149K) и awesome-claude-code-toolkit.

Я узнал про этот файл из ленты GitHub, посмотрел, что внутри, и сразу записал короткий ролик - 14 июня, 163K просмотров за пять дней на двух площадках. Дальше копаю в этой статье уже спокойно, без хайпа: что реально работает, что нет, что я бы переписал под себя.

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

26 января 2026 Karpathy опубликовал пост в X:

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

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

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

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

В оригинале правило в CLAUDE.md звучит коротко:

Раскрывается оно 4 пунктами:

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

Два примера из EXAMPLES.md.

Запрос: «Добавь функцию экспорта пользователей.»

Без правила Claude молча генерит код, который выгружает ВСЕХ юзеров в захардкоженный путь. Что за формат - CSV или JSON, какие поля включать, что с PII, что с пагинацией на 100K записей - агент не спрашивает.

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

Запрос: «Сделай поиск быстрее.»

Без правила Claude молча выбирает один из трёх путей: ставит кэширование, добавляет индекс или переводит в async. Через час оказывается, что нужен был другой. Скажем, у тебя проблема в throughput на пиках, а кэширование latency на одиночный запрос её не закрывает.

С правилом агент пишет: «Что именно ускорить - latency, throughput или perceived speed? Для каждого варианта прикину объём работы.» Без этого вопроса дальше не идёт.

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

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

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

Запреты:

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

Финальный тест:

Канонический пример - запрос «Добавь функцию расчёта скидки». Без правила Claude собирает Strategy pattern с базовым классом, тремя реализациями, enum для типов скидок, dataclass для конфига, фабрикой. 30+ строк setup, прежде чем появится первая логика. С правилом - одна функция, принимает товар и купон, возвращает сумму. 4 строки. Когда появится второй тип скидки, тогда и появится Strategy.

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

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

⭐ Полная схема CLAUDE.md, а не один файл

Правила Karpathy - это первый кирпич Второго мозга Claude Code. Файл хороший, но без остальной инфраструктуры он работает на 30% мощности. На практикуме за 3 эфира собираешь все три кита: ИИ-клон (твоя личная методология в Skills), Второй мозг (CLAUDE.md + папка business/) и контекст-инжиниринг (Plan Mode, /compact, git+rewind). Связка, которая превращает Claude из «иногда работает» в надёжный инструмент.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 23–25 июня  ·  2 000 ₽

Записаться →

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

Слоган:

Правила правки:

• Не улучшать соседний код, комментарии, форматирование.
• Не рефакторить то, что и так работает.
• Сохранять текущий стиль (кавычки, отступы, типы).
• Не удалять мёртвый код, который ты не создал, только упомянуть его в выводе.

Из удалений можно только то, что осиротело именно из-за твоих правок: импорт, переменная, функция стали не нужны после твоего изменения.

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

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

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

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

Слоган:

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

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

Запрос: «Добавь rate limit на API.» Без правила Claude пишет полную систему: Redis, несколько стратегий, конфиг на каждый endpoint - 300 строк за один коммит. С правилом - инкременты с проверкой. Шаг 1: in-memory лимит на один endpoint, проверка через curl. Шаг 2: вынести в middleware, прогнать тесты. Шаг 3: добавить Redis backend, замерить latency. Шаг 4: конфиг per-endpoint. Каждый шаг проверяется до следующего.

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

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

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

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

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

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

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

Готовая рекомендация без воды.

Копируй дословно (переводом):

• 4 слогана: «Не догадывайся, не скрывай непонимание, покажи компромиссы», «Минимум кода, ничего на запас», «Трогай только то, что нужно», «Определи критерий успеха, зацикливай пока не подтвердил».
• Sub-directives под каждым правилом (по 3-4 строки). Они тоже работают как есть.
• Финальный «senior-test»: спроси у себя, переусложнено или нет.

Перепиши под себя:

• Все 8 сценариев из EXAMPLES.md. Они про абстрактные API и валидаторы. Возьми 2-3 ситуации из своих последних коммитов, где Claude переусложнил или сделал лишнее. Опиши формат «было vs должно было быть» - это даст модели конкретный материал.
• Раздел про критерии успеха. Karpathy предлагает «failing test → fix → verify». Это работает для библиотек. Для бизнес-логики (письма, оплата, рассылки) ты, скорее всего, проверяешь по другим критериям: «письмо приходит на тестовый адрес», «webhook возвращает 200», «в БД появилась запись».

Добавь поверх:

• Список инструментов, которые в твоём проекте уже стоят. Claude должен знать, что у тебя Yandex Pay, а не Stripe, что хостинг через Coolify, а не Vercel. Иначе он начнёт писать код под чужой набор инструментов.
• Запреты на конкретные библиотеки. У меня в CLAUDE.md написано «не использовать moment.js, у нас date-fns» - это снимает 4-5 повторных правок в неделю.

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

Я отключаю CLAUDE.md с правилами Karpathy в трёх случаях.

Первый - быстрые одноразовые скрипты. Когда мне нужно за 10 минут выгрузить данные из прод-БД и нарисовать график, я не хочу диалога «уточни предположения». Я хочу один INSERT, один Python-скрипт. В этих случаях я просто работаю без CLAUDE.md в папке /tmp/scripts/.

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

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

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

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

Несколько примеров из моего реального CLAUDE.md в проекте smyslokod.ru:

• «Никогда не использовать длинные тире, только дефисы» - текстовое правило для контентных задач. Длинное тире - один из главных маркеров «писано ИИ».
• «Не хардкодить даты и цены когорт - всегда из БД» - предметное. У меня даты и цены меняются по два раза в месяц, любой хардкод протухает.
• «При любой работе с прод-БД сначала проверять через prod-psql, не делать UPDATE без LIMIT 1» - инфраструктурное.
• «Не использовать Stripe в примерах - проект на Yandex Pay» - правило, которое снимает неверные параллели из тренировочных данных модели.

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

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

Готовый протокол на 5 минут:

1. Создай чистую папку для эксперимента, скопируй в неё реальный код, на котором Claude недавно ошибался.
2. Запусти Claude Code БЕЗ CLAUDE.md Karpathy. Дай ту же задачу. Сохрани вывод.
3. Положи в корень CLAUDE.md из репозитория multica-ai. Запусти Claude Code заново на той же задаче.
4. Сравни оба ответа по 4 пунктам:
   • В первой реплике появился вопрос до кода? (Правило 1)
   • Решение короче и проще? (Правило 2)
   • Меньше «попутных» правок в соседнем коде? (Правило 3)
   • Есть критерий проверки результата? (Правило 4)
5. Если по 2+ критериям второй вариант лучше - копируй файл в основной проект. Если нет - значит, у твоего Claude Code другой узкий бутылочный участок, который этот файл не закрывает.

У меня на текстовых задачах файл даёт прирост по правилу 3 (меньше переписывает), а на code-review дает прирост по правилу 1 (задаёт вопросы до правки). На быстрых скриптах файл бесполезен. Так и держу: в основных проектах включен, в /tmp/scripts/ - выключен.

Что дальше: где живёт CLAUDE.md в большой системе?

Я часто получаю один и тот же вопрос: «У меня настроен CLAUDE.md, но Claude всё равно галлюцинирует». Ответ почти всегда один: CLAUDE.md - это один из слоёв, и без двух других он работает на треть мощности. Если интересно собрать всю систему, моя страница про память Claude разбирает, как CLAUDE.md соотносится с Claude Memory, а гайд Что выбрать в Claude Code: Skills, Subagents, MCP или Plugins показывает остальные слои.

Дальше делай так, как удобно: либо копируй CLAUDE.md Karpathy в свой проект прямо сейчас и проверь 5-минутным протоколом, либо иди читать про связки.

Это первый кирпич Второго мозга Claude Code. Полная связка - ИИ-клон + Второй мозг + контекст-инжиниринг - в практикуме за 3 эфира.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 23–25 июня  ·  2 000 ₽

Записаться →

Новые материалы - дайджестом, без спама

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

Подписаться в Telegramили на email