Claude

Karpathy skills для Claude Code: 4 правила против мусора

Forrest Chang собрал в один CLAUDE.md файл 4 принципа Карпатого против переусложнения, додумывания и drive-by-правок. 48к звёзд за пару месяцев.

Pavel Matveev

Pavel Matveev

— 5 min read
Karpathy skills для Claude Code: 4 правила против мусора
TL;DR: Forrest Chang собрал один CLAUDE.md с 4 принципами, которые лечат типичные болячки LLM в кодинге: додумывание допущений, раздувание кода и бесконтрольные drive-by-правки. Основано на наблюдениях Андрея Карпатого о том, где агенты стабильно тупят.

Когда Карпатый постит что-то про LLM, это обычно превращается в методику через неделю. Его заметка про проблемы AI-кодинга — додумывание, переусложнение, правки не по теме — превратилась в GitHub-репозиторий andrej-karpathy-skills с 48к звёзд и 3.9к форков. Внутри один CLAUDE.md файл. Разбираю, что там и почему это работает лучше, чем длинный промпт в начале чата.

Что сломано в поведении Claude Code

Карпатый описал это на редкость точно в серии цитат. Пересказываю своими словами, потому что любой, кто долго работал с Claude Code или Cursor, через это проходил.

  • Модели делают неверные допущения и не проверяют их. Задача неоднозначная, модель тихо выбирает интерпретацию и идёт делать. В итоге получается не то, что ты имел в виду.
  • Модели не управляют своей путаницей. Не просят уточнений, не выносят противоречия на поверхность, не предлагают альтернатив, не пушат, когда видят более простой путь.
  • Любят переусложнять код и API. Раздувают абстракции, не чистят мёртвый код, пишут решение на 1000 строк, когда хватит 100.
  • Меняют или удаляют код, которого не понимают. Как побочный эффект. Даже если это ортогонально твоей задаче.

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

Четыре принципа CLAUDE.md

Каждый принцип лечит одну группу проблем. Распишу с примерами.

1. Думать до кода

Явно проговаривать допущения, показывать альтернативные интерпретации, пушить назад при сомнениях, останавливаться при путанице.

На практике выглядит так: ты даёшь размытый запрос «улучши этот handler», а Claude вместо тихого рефакторинга отвечает «что именно улучшить — производительность, читаемость или добавить логирование?». Для ленивых промптов это ценно.

2. Простота вперёд

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

  • Только то, что попросили
  • Никаких абстракций для одноразового кода
  • Никакой «гибкости», которая не была запрошена
  • Никакой обработки невозможных сценариев
  • Если 200 строк можно сократить до 50, стоит переписать

Тест: сказал бы сеньор, что это переусложнено? Если да, упрощаем.

3. Хирургические правки

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

  • Не улучшать соседний код, комментарии, форматирование
  • Не рефакторить то, что не сломано
  • Следовать существующему стилю, даже если ты бы сделал иначе
  • Заметил dead code не по теме, упомяни его, но не удаляй

Когда твои правки оставили сироты (неиспользуемые импорты, переменные), их чистить можно. Существующий dead code чистить только если попросили. Каждая изменённая строка должна напрямую относиться к запросу пользователя.

4. Goal-driven execution

Самый интересный принцип. Вместо императивных инструкций ставим декларативные цели с проверкой:

Вместо Делать
«Добавь валидацию» «Напиши тесты для невалидных входов, потом заставь их пройти»
«Почини баг» «Напиши тест, который его воспроизводит, потом заставь пройти»
«Отрефактори X» «Убедись, что тесты проходят до и после»

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

Для многошаговых задач автор предлагает шаблон плана:

1. [Шаг] → проверка: [что проверить]
2. [Шаг] → проверка: [что проверить]
3. [Шаг] → проверка: [что проверить]

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

Залетай в телеграм-канал — пишу про AI и опыт агентского коддинга

Как поставить у себя

Два способа.

Способ 1: плагин Claude Code (рекомендуется). Внутри Claude Code:

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

Это добавит гайдлайны как плагин Claude Code, доступный во всех твоих проектах без копирования файлов.

Способ 2: CLAUDE.md в проект. Для нового проекта:

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

Для существующего проекта дописать в конец:

curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

Файл задизайнен так, чтобы мерджиться с твоими правилами. Добавляешь свои секции типа «используй TypeScript strict mode», «все API эндпоинты должны иметь тесты», «следуй паттернам в src/utils/errors.ts».

forrestchang/andrej-karpathy-skills
A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.
GitHub · MIT · 48.2k stars

Что реально меняется в работе

По отзывам в Reddit и Medium от людей, которые пожили с этими правилами пару недель:

  • Диффы становятся короче. Меньше «заодно поправил import order».
  • Claude чаще задаёт уточняющий вопрос до первой правки, а не после того, как сделал не то.
  • Меньше переписываний из-за переусложнения.
  • Чистые PR без drive-by рефакторинга.

Сам автор пишет, что успех виден именно в диффах: меньше лишних строк, вопросы приходят перед имплементацией, а не после ошибок.

Отдельно стоит подчеркнуть четвёртый принцип. Если ты научишься формулировать задачу как цель с проверкой («напиши тест, сделай его зелёным»), Claude начнёт работать в цикле без твоего постоянного контроля. Это и есть тот самый агентный режим, за которым все гонятся.

Когда это перебор

Сам автор пишет в readme: гайдлайны сдвигают модель в сторону осторожности, а не скорости. Для тривиальных задач (typo, очевидный one-liner) это перебор. Не каждому изменению нужен полный ригор.

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

А свежий Opus 4.7 это не делает сам?

В анонсе Claude Opus 4.7 Anthropic писала, что модель теперь сама проверяет свою работу, честнее о своих ограничениях и следует инструкциям буквально. Часть того, на что целятся эти принципы, уже зашито в модель.

Но модель слушает именно то, что ты написал в промпте. Если в твоём CLAUDE.md нет явного правила «спроси, если непонятно», модель и не спросит, даже если подозревает неоднозначность. Karpathy-guidelines именно это и прописывают: явные правила для поведения, которые модель соблюдает, потому что видит их в системном контексте.

Вывод

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

Что ещё почитать