В быстро меняющемся мире AI-разработки один репозиторий на GitHub стал самым популярным набором правил поведения для AI-агентов: forrestchang/andrej-karpathy-skills. Созданный разработчиком Форрест Чанг, он обобщает виральные наблюдения Андрея Карпати о ловушках кодинга с помощью LLM в единый, применимый на практике CLAUDE.md файл. Мы изучили его на основе GitHub, Twitter/X, Reddit, веб-статей и самого исходного кода — вот исчерпывающее руководство.
Get the latest on AI, LLMs & developer tools
New MCP servers, model updates, and guides like this one — delivered weekly.
🎬 Посмотрите видеоразбор
Предпочитаете читать? Листайте дальше, чтобы ознакомиться с полным текстовым руководством и примерами кода.
1. Почему это стало виральным
Начнем с того, почему этот репозиторий важен. Он стал одним из самых быстрорастущих на GitHub — десятки тысяч звезд за первые недели — для репозитория, который по сути содержит один файл.
Не фреймворк. Не библиотека. Не приложение. Единый набор правил поведения для AI-агентов программирования. Создан 27 января 2026 года, выпущен под лицензией MIT, и продолжает расти. Это говорит о чем-то важном в векторе развития индустрии.
Почему это важно
У многих популярных open-source инструментов с тысячами контрибьюторов и годами разработки меньше звёзд. Этот репозиторий стал вирусным благодаря всего нескольким коммитам и отсутствию runtime-зависимостей. Ценность не в коде — она в идеях.
2. История появления
Репозиторий напрямую связан с вирусным твитом Андрея Карпати — сооснователя OpenAI, бывшего руководителя отдела ИИ в Tesla и человека, который ввёл термин “vibe coding.” В своём посте Карпати поделился не инструментом или репозиторием, а наблюдениями — списком претензий к тому, как LLM ведут себя при написании кода.
Несколько случайных заметок по итогам активного кодинга с Claude за последние несколько недель.
— Андрей Карпати (@karpathy) 26 января 2026 г.
Процесс разработки. Учитывая недавний скачок возможностей LLM в написании кода, я, как и многие другие, быстро перешёл от примерно 80% ручного написания с автодополнением и 20% агентов в ноябре к 80% агентного кодинга и 20% правок и доработок в…
Разработчик Форрест Чанг прочитал эти наблюдения и сделал кое-что практичное: он преобразовал их в структурированный, машиночитаемый CLAUDE.md файл. Не расплывчатый пост в блоге. Не тред в Twitter. А конфигурационный файл который ИИ-агенты действительно читают и соблюдают.
Ключевая идея была в следующем: Карпати выявил проблемы. Форрест Чанг воплотил решения в коде. Сообщество подтвердило и то, и другое — сделав его одним из самых популярных репозиториев для AI-workflow на GitHub.
3. Проблемы, выявленные Карпати
Наблюдения Карпати не были расплывчатыми жалобами. Это были конкретные, воспроизводимые паттерны, с которыми сталкивался каждый разработчик, использующий ИИ-агентов для написания кода. Вот его точные слова:
Проблема 1: Скрытые предположения
“Модели делают неверные предположения от вашего имени и просто следуют им без проверки. Они не умеют работать с собственной неопределенностью, не запрашивают уточнений, не подсвечивают несоответствия, не предлагают компромиссы и не возражают там, где это необходимо.”
Проблема 2: Овер-инжиниринг
“Они очень любят усложнять код и API, раздувать абстракции, не удаляют мертвый код... создают громоздкую конструкцию на 1000 строк там, где хватило бы 100.”
Проблема 3: Непреднамеренные побочные эффекты
“Они все еще иногда меняют или удаляют комментарии и код, который недостаточно понимают, в качестве побочного эффекта, даже если это никак не относится к задаче.”
Если вы использовали Claude Code, Copilot, Cursor или любого другого ИИ-агента для кодинга, вы это чувствовали. Вы просите агента исправить баг, а он переписывает половину файла. Вы просите добавить фичу, а он выстраивает целый слой абстракции. Вы просите о помощи, и он уверенно несется вперед, основываясь на неверных предположениях.
У сообщества Reddit (особенно r/ClaudeAI и r/ClaudeCode) есть широко используемый термин для такого поведения: “уверенный в себе джун.” ИИ быстр, много знает и склонен совершать наивные ошибки, если оставить его без присмотра. Он гениален, но ненадежен — именно тот тип инженера, которому нужны четкие рамки.
4. Четыре принципа
Форрест Чанг сформулировал наблюдения Карпати в виде четырех принципов. Каждый из них напрямую направлен на решение определенного класса ошибок LLM:
| Принцип | Решает |
|---|---|
| Думай перед написанием кода | Ошибочные предположения, скрытая неопределенность, упущенные компромиссы |
| Простота превыше всего | Излишнее усложнение, раздутые абстракции, спекулятивные функции |
| Хирургические изменения | Ортогональные правки, затрагивание кода, который не следует трогать, отклонение от стиля |
| Выполнение, ориентированное на цель | Расплывчатая реализация, отсутствие проверки, слабые критерии успеха |
Давайте разберем каждый из них.
Принцип 1: Думай перед написанием кода
“Не предполагай. Не скрывай неопределенность. Выявляй компромиссы.”
Это самый фундаментальный принцип. LLM склонны молча выбирать одну интерпретацию и следовать ей. Этот принцип заставляет рассуждать явно:
- Формулируй предположения явно — Если есть сомнения, спрашивай, а не угадывай
- Предлагай несколько вариантов интерпретации — Не выбирай молча при наличии двусмысленности
- Возражай, когда это оправдано — Если есть более простой подход, скажи об этом
- Остановись, если что-то непонятно — Назови то, что неясно, и попроси уточнений
Пример: Ловушка скрытых предположений
Запрос пользователя: “Add a feature to export user data”
def export_users(format='json'):
users = User.query.all()
# Предположили ВСЕХ пользователей, расположение файла, поля,
# названия полей CSV — ничего не уточняя
Перед реализацией мне нужно уточнить:
1. Область действия: Экспортировать всех пользователей или отфильтрованную выборку?
(последствия для конфиденциальности)
2. Формат: Скачивание файла? Фоновая задача?
API endpoint?
3. Поля: Какие поля пользователя?
(некоторые могут быть конфиденциальными)
4. Объем: Сколько обычно пользователей?
Самый простой подход: добавить API endpoint, который
возвращает JSON с пагинацией. Что предпочтете?
Принцип 2: Простота прежде всего
“Минимум кода, решающего задачу. Ничего лишнего.”
Это помогает бороться со склонностью LLM к избыточному проектированию. Правила строгие:
- Никаких функций сверх того, что было запрошено
- Никаких абстракций для одноразового кода
- Никакой “гибкости” или “настраиваемости”, о которой не просили
- Никакой обработки ошибок для невозможных сценариев
- Если 200 строк можно превратить в 50 — перепишите их
Тест: Скажет ли senior-инженер, что это переусложнено? Если да — упрощайте.
Пример: Ловушка избыточной абстракции
Запрос пользователя: “Добавь функцию для расчета скидки”
class DiscountStrategy(ABC):
@abstractmethod
def calculate(self, amount): ...
class PercentageDiscount(DiscountStrategy): ...
class FixedDiscount(DiscountStrategy): ...
class DiscountConfig: ...
class DiscountCalculator: ...
# 50+ строк для одного вычисления
# Использование требует 30+ строк настройки
def calculate_discount(amount, percent):
"""Рассчитать скидку. percent от 0 до 100."""
return amount * (percent / 100)
# Использование
discount = calculate_discount(100.0, 10.0) # скидка $10
Ключевой инсайт из репозитория
“‘Переусложненные’ примеры не выглядят явно ошибочными — они следуют паттернам проектирования и лучшим практикам. Проблема в том, что своевременность: они добавляют сложность раньше, чем она необходима.” Хороший код просто решает сегодняшнюю проблему, а не завтрашнюю преждевременно.
Принцип 3: Хирургические изменения
“Трогайте только то, что необходимо. Убирайте только за собой.”
Этот принцип напрямую касается недовольства Karpathy тем, что LLM вносят ортогональные изменения. При редактировании существующего кода:
- Не “улучшайте” соседний код, комментарии или форматирование
- Не делайте рефакторинг того, что не сломано
- Придерживайтесь существующего стиля, даже если вы бы сделали иначе
- Если вы заметили несвязанный мертвый код, упомяните об этом — не удаляйте его
Когда ваши изменения оставляют неиспользуемый код:
- Удаляйте импорты/переменные/функции, которые ВАШИ изменения сделали ненужными
- Не удаляйте ранее существовавший мертвый код, если об этом не просили
Проверка: Каждая измененная строка должна напрямую соответствовать запросу пользователя.
Пример: Ловушка «попутного» рефакторинга
Запрос пользователя: “Исправьте баг, из-за которого пустые email вызывают сбой валидатора”
Изменено 15 строк:
- Добавлен docstring (не запрашивалось)
- Добавлена валидация имени пользователя (не запрашивалось)
- Изменены комментарии (не запрашивалось)
- “Улучшена” логика валидации email (не запрашивалось)
- Добавлены вызовы .strip() повсюду (не запрашивалось)
Изменено 3 строки:
- Добавлена проверка на пустую строку для email
- Изменена ссылка на переменную во избежание сбоя
- Больше ничего не затронуто.
Пример: Ловушка «дрейфа стиля»
Запрос пользователя: “Добавь логирование в функцию загрузки”
The LLM adds logging — but also changes single quotes to double quotes, adds type hints nobody asked for, adds a docstring, reformats whitespace, and restructures the boolean return logic. The correct approach: add только строки логирования, используя существующий стиль (single quotes, no type hints, same spacing).
Принцип 4: Исполнение, ориентированное на цель
“Определите критерии успеха. Повторяйте цикл до подтверждения.”
Этот принцип отражает то, что Карпати считает самым ценным инсайтом в работе с LLM:
Ключевой инсайт Карпати
“LLM исключительно хороши в циклическом выполнении задач до достижения конкретных целей... Не говорите модели, что делать, задайте критерии успеха и наблюдайте за процессом.”
Этот принцип превращает императивные задачи в декларативные цели:
| Вместо... | Превратите в... |
|---|---|
| “Добавь валидацию” | “Напиши тесты для некорректных входных данных, а затем добейся их прохождения” |
| “Исправь баг” | “Напиши тест, воспроизводящий ошибку, а затем добейся его прохождения” |
| “Проведи рефакторинг X” | “Убедись, что тесты проходят до и после изменений” |
Для многоэтапных задач модель должна составить краткий план:
1. [Шаг] → verify: [проверка]
2. [Шаг] → verify: [проверка]
3. [Шаг] → verify: [проверка]
Strong success criteria let the LLM loop
независимо. Слабые критерии (“сделай, чтобы работало”)
требуют постоянных уточнений.
5. Сам файл CLAUDE.md
Вот полный, несокрaщенный CLAUDE.md файл из репозитория. Он намеренно короткий — менее 70 строк. Эта краткость — преимущество, а не ограничение:
Рекомендации по поведению для уменьшения типичных ошибок LLM
при написании кода. Объединяйте с инструкциями конкретного проекта
по мере необходимости.
Компромисс: Эти рекомендации отдают приоритет осторожности,
а не скорости. Для тривиальных задач полагайтесь на здравый смысл.
## 1. Сначала подумайте, потом пишите код
Не делайте предположений. Не скрывайте неясности. Озвучивайте компромиссы.
Перед реализацией:
- Явно формулируйте свои предположения. Если не уверены — спрашивайте.
- Если существует несколько интерпретаций, представьте их.
- Если есть более простой подход, сообщите об этом.
- Если что-то непонятно, остановитесь. Укажите, что именно вызывает вопросы.
## 2. Простота превыше всего
Минимум кода для решения задачи. Никаких догадок.
- Никаких функций сверх того, что было запрошено.
- Никаких абстракций для одноразового кода.
- Никакой “гибкости”, о которой не просили.
- Никакой обработки ошибок для невозможных сценариев.
- Если 200 строк можно сократить до 50 — перепишите их.
## 3. Хирургические изменения
Изменяйте только то, что необходимо. Убирайте только за собой.
- Не “улучшайте” соседний код или форматирование.
- Не делайте рефакторинг того, что не сломано.
- Придерживайтесь существующего стиля, даже если вы сделали бы иначе.
- Если заметили мертвый код, упомяните об этом — не удаляйте его.
## 4. Исполнение, ориентированное на цель
Определите критерии успеха. Повторяйте цикл до подтверждения.
Превращайте задачи в проверяемые цели:
- “Добавить валидацию” → “Написать тесты, затем добиться их прохождения”
- “Исправить баг” → “Воспроизвести его в тесте, затем исправить”
- “Рефакторинг X” → “Убедиться, что тесты проходят до и после”
Вот и всё. Весь файл. Его сила в лаконичности — он достаточно короткий, чтобы уместиться в контекстное окно агента, не вытесняя инструкции конкретного проекта, и достаточно длинный, чтобы закрепить критические поведенческие ограничения.
6. Примеры из реальной практики
Репозиторий включает EXAMPLES.md файл с подробным сравнением «до» и «после». Вот основная “сводка антипаттернов” из файла:
| Принцип | Антипаттерн | Исправление |
|---|---|---|
| Сначала подумай, потом пиши код | Молчаливое допущение формата файла, полей, области видимости | Явно перечисляйте допущения, запрашивайте уточнения |
| Простота превыше всего | Паттерн «Стратегия» для расчета одной скидки | Одна функция, пока действительно не понадобится усложнение |
| Точечные изменения | Reformats quotes, adds type hints while fixing a bug | Изменяйте только те строки, которые исправляют заявленную проблему |
| Ориентированность на цель | “Я проанализирую и улучшу код” | “Написать тест для бага X → добиться его прохождения → убедиться в отсутствии регрессий” |
7. Как установить
Репозиторий предлагает два способа установки:
Вариант А: Плагин Claude Code (рекомендуется)
Это устанавливает рекомендации как плагин Claude Code, делая навык доступным во всех ваших проектах:
/plugin marketplace add forrestchang/andrej-karpathy-skills
# Затем установите плагин
/plugin install andrej-karpathy-skills@karpathy-skills
Вариант Б: CLAUDE.md (для конкретного проекта)
Для отдельного проекта:
curl -o CLAUDE.md https://raw.githubusercontent.com/
forrestchang/andrej-karpathy-skills/main/CLAUDE.md
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/
andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
Настройка
Эти рекомендации предназначены для объединения с инструкциями конкретного проекта. Добавьте свои разделы для конфигурации TypeScript, стандартов API, соглашений о тестировании или любых других нужд вашего проекта. Четыре принципа задают базовый уровень поведения; правила вашего проекта строятся поверх них.
8. Что такое CLAUDE.md?
Для тех, кто не знаком с этой концепцией: CLAUDE.md — это Карта памяти проекта для ИИ-агентов программирования. Claude Code автоматически считывает её в начале каждой сессии, обеспечивая постоянный контекст, который сохраняется между диалогами.
Считайте это ИИ-эквивалентом документации по онбордингу для нового разработчика — с той лишь разницей, что ИИ читает её абсолютно каждый раз, когда начинает работу над вашим проектом.
Лучшие практики для CLAUDE.md (2026)
| Раздел | Содержание |
|---|---|
| Обзор проекта | Краткое описание сути проекта в 2-3 предложениях |
| Стек технологий | Языки, фреймворки, ключевые библиотеки |
| Архитектура | Карта кодовой базы (source, компоненты, конфиги) |
| Команды | команды dev, build, test, lint |
| Стандарты кодирования | Соглашения об именовании, паттерны, правила стиля |
| Правила безопасности | “Никогда не хардкодьте API-ключи,” “Не редактируйте /config” |
Иерархия
CLAUDE.md(корень проекта) — Общий контекст, фиксируется в GitCLAUDE.local.md(корень проекта) — Личные заметки разработчика (добавьте в .gitignore)~/.claude/CLAUDE.md— Глобальные настройки для всех проектов- Подкаталог
CLAUDE.mdфайлы — Контекст подтягивается только при работе в этой директории
Основное правило: Если вам приходится повторять инструкцию в чате более двух раз, перенесите её в ваш CLAUDE.md.
9. Реакция сообщества
Мы изучили обсуждения на Reddit (r/ClaudeAI, r/ClaudeCode), Twitter/X и в технических блогах. Вот что думает сообщество:
Консенсус “Уверенный Junior-разработчик”
Сообщество Reddit часто описывает Claude Code как блестящего, но иногда ненадежного “junior developer.” Он работает быстро и обладает обширными знаниями, но склонен выбирать опасные обходные пути, галлюцинировать или совершать наивные ошибки, если оставить его без присмотра. Файл навыков Karpathy напрямую решает эту проблему, добавляя guardrails, необходимые junior dev.
Аргумент о “Skill Issue”
На Reddit преобладает мнение: качество кода, созданного ИИ, напрямую пропорционально инженерному суждению самого пользователя и навыкам “context engineering”. Опытные пользователи, освоившие структуру промптов, управление контекстом и циклы проверки, сообщают о значительно более высоких показателях успеха. Файл навыков Karpathy — один из самых популярных инструментов “context engineering”.
Дискуссия об “AI Psychosis”
Описание Karpathy “perpetual AI psychosis” — постоянного состояния гиперпродуктивного, но изматывающего управления агентами — вызвало глубокий резонанс. Некоторые видят в ИИ-агентах конкурентное преимущество, которое нельзя игнорировать. Другие называют это “productivity theater” — ощущением скорости при создании неподдерживаемого кода. Файл навыков занимает промежуточную позицию: он признает мощь ИИ-агентов, но утверждает, что им необходимы дисциплинированные ограничения.
Смещение «человеческого» узкого места
Консенсус сообщества: ИИ снизил порог вхождения в написание кода. Но реальное «узкое место» сместилось с реализации на архитектуру и оценку. Теперь вопрос не в том, “как мне это написать?”, а в том, “достаточно ли хорошо я понимаю то, что только что создал агент, чтобы это поддерживать?”
10. Общая картина
От “Vibe Coding” к “Agentic Engineering”
Когда Karpathy ввел термин “vibe coding” в начале 2025 года, он описывал свободный, разговорный способ взаимодействия с ИИ. К 2026 году сообщество развило это в “agentic engineering” — дисциплина, в которой разработчики относятся к AI как к партнеру, требующему четких целей, определенных границ и тщательного тестирования.
Репозиторий andrej-karpathy-skills отражает эту эволюцию. Речь не об ограничении возможностей AI, а о направлении его потенциала через принципы, которые приносят лучшие результаты.
Паттерн “Idea File”
Этот репозиторий также иллюстрирует то, что Карпати называет “idea file” паттерном — обмен идеями, а не реализациями. Файл CLAUDE.md не является библиотекой, которую кто-либо импортирует. Это набор принципов, которые каждый может адаптировать. Агент получателя настраивает его под свои конкретные нужды. Это новый вид open source: не открытый код, а открытые идеи.
Как понять, что это работает
Согласно README репозитория, эти рекомендации работают, если вы видите:
- Меньше лишних изменений в diffs — Появляются только запрошенные изменения
- Меньше переписываний из-за излишнего усложнения — Код получается простым с первого раза
- Уточняющие вопросы предшествуют реализации — А не следуют за ошибками
- Чистые, минимальные PR — Без попутного рефакторинга или “улучшений”
Примечание о компромиссах
Репозиторий честно говорит о своих компромиссах: “Эти рекомендации отдают приоритет осторожности, а не скорости.” Для тривиальных задач (простые исправления опечаток, очевидные однострочники) полагайтесь на здравый смысл — не каждое изменение требует максимальной строгости. Цель — сократить число дорогостоящих ошибок в нетривиальной работе, а не замедлять выполнение простых задач.
11. Все источники & ссылки
При подготовке статьи использовалось исследование по нескольким источникам включая GitHub, Twitter/X, Reddit, веб-статьи и сам исходный код. Вот все основные источники:
Основные источники
- GitHub: forrestchang/andrej-karpathy-skills — Сам репозиторий
- CLAUDE.md — Непосредственно файл с рекомендациями
- EXAMPLES.md — Реальные примеры до/после
- Оригинальный твит Karpathy's — Вирусный пост о подводных камнях кодинга с использованием LLM
Обсуждения в сообществе
- Reddit r/ClaudeAI — Обсуждения в сообществе рабочих процессов Claude Code и консенсуса о “confident junior dev”
- Reddit r/ClaudeCode — Треды о лучших практиках CLAUDE.md и системах спецификаций
- Twitter/X — Реакции разработчиков, обмен рабочими процессами и отчеты о внедрении
Веб-источники
- Medium — Технические обзоры и руководства по реализации
- dev.to — Туториалы от сообщества разработчиков
- Forbes — Освещение эволюции от “vibe coding” к “agentic engineering”
- VentureBeat — Анализ аналогии Karpathy о “compiler” для управления контекстом
- Analytics Vidhya — Технический анализ подхода с использованием skills file
Документация
- Документация Claude Code — Официальный справочник по CLAUDE.md
- HumanLayer.dev — Лучшие практики конфигурации CLAUDE.md
Статьи по теме на этом сайте
- Базы знаний LLM от Карпати: разбор оригинального твита
- LLM Wiki Карпати: полное руководство по его файлу идей
- Как настроить навыки в вашей AI IDE
- Полное руководство по системным промптам для AI-агентов
Get the Ultimate Antigravity Cheat Sheet
Join 5,000+ developers and get our exclusive PDF guide to mastering Gemini 3 shortcuts and agent workflows.