Откуда это
Репо forrestchang/andrej-karpathy-skills — адаптация советов Карпатого в формате CLAUDE.md. 11.5k форков, 115k звёзд. По сути — набор behavioral guidelines для AI-ассистентов, чтобы они перестали делать типичные ошибки при написании кода.
Четыре принципа. Разберём по порядку.
1. Think Before Coding — Не assum'ить
Суть: Явно формулировать допущения до того, как писать код. Если непонятно — спрашивать, а не выбирать молча.
Типичная ошибка LLM:
Запрос: «Добавить экспорт данных пользователей» → LLM делает User.query.all(), сохраняет в users.json, поля id, email, name.
Что не так:
А если пользователей 10 миллионов? (пагинация?)
Куда сохранять? (download в браузере? background job? API?)
Какие именно поля? (email чувствительный?)
Вместо этого — сначала вопросы:
1. Scope: всех пользователей или фильтрованный subset?
2. Формат: download файл или API endpoint?
3. Поля: какие именно поля экспортировать?
4. Объём: примерно сколько записей?Карпатый называет это «surface tradeoffs» — не скрывать неоднозначности, а выносить их на обсуждение.
2. Simplicity First — Минимум, ничего спекулятивного
Суть: Код, который решает задачу, и ничего сверх. Не добавлять «гибкость», абстракции и «а вдруг пригодится» до того, как это реально нужно.
Типичная ошибка LLM:
Запрос: «Функция расчёта скидки» → LLM пишет DiscountStrategy с ABC, PercentageDiscount, FixedDiscount, DiscountCalculator, DiscountConfig — 150 строк.
Альтернатива:
def calculate_discount(amount: float, percent: float) -> float:
return amount * (percent / 100)Ключевой вопрос: «Это решит проблему сегодня?» Если да — достаточно. Сложность добавляется только когда она реально нужна, не преждевременно.
3. Surgical Changes — Трогать только нужное
Суть: Редактируешь существующий код — меняй только то, что относится к задаче. Соседние файлы, комменты, форматирование, стиль — не трогай.
Типичная ошибка LLM:
Запрос: «Пофиксить баг с пустым email» → LLM заодно добавляет валидацию username, меняет кавычки с одинарных на двойные, добавляет type hints, реформатирует всё вокруг.
Проверка: Каждая изменённая строка должна напрямую вести к запросу пользователя. Если нет — не надо.
Свои орфаны (неиспользуемые импорты/функции от твоих же изменений) — убирать. Чужие — не трогай.
4. Goal-Driven Execution — Цель до кода
Суть: Любую задачу превращать в проверяемый результат. Не «сделаю хорошо», а «сделаю так, чтобы можно было проверить, что именно этот критерий выполнен».
Шаблон:
"Добавить валидацию" →
1. Написать тесты для невалидных данных
2. Сделать чтобы тесты проходили
3. Проверить что остальное не сломалосьТипичная ошибка LLM:
«Фикс бага с сортировкой» → Меняет sort logic без воспроизведения бага.
Правильный подход:
Написать тест, который падает (воспроизводит баг)
Пофиксить
Тест проходит
Регрессия — все остальные тесты тоже зелёные
Главный инсайт
The "overcomplicated" examples aren't obviously wrong — they follow design patterns and best practices. The problem is timing: they add complexity before it's needed.
Хороший код решает сегодняшнюю проблему просто, а не завтрашнюю — преждевременно.
Ссылки
EXAMPLES.md — разбор реальных кейсов
Обсуждение
Комментариев пока нет — начните тему.