Работать — это просто яд.
Даже такой гуру в области ИИ, как Андрей Карпати, после перехода в Anthropic превратился в рабочую лошадку, и у него не остаётся времени на вклад в GitHub.
С момента официального присоединения к Anthropic 19 мая этого года мы наблюдаем, как активность Андрея Карпати в сообществе open-source резко снизилась, в последнее время он даже реже публикует посты на платформе X.
На днях он даже поспорил с пользователями в X, раскритиковав то, как алгоритмы рекомендаций разжигают конфликты ради вовлечения, что ухудшает атмосферу в сообществе. Илон Маск также признал это: действительно, нам нужно кардинальное улучшение.
Однако как человек, который не может сидеть без дела, любовь Андрея Карпати к «созданию обучающих материалов» остаётся неизменной, будь то по собственной воле или вынужденно.
Недавно кто-то сказал: «У меня есть друг, который получил реально используемый Андреем Карпати файл CLAUDE.md». Говорят, он может полностью изменить ваш способ использования Claude.
Значит, нам снова есть чему поучиться?
В сообществе распространяется «Личный CLAUDE.md Карпати»
CLAUDE.md — это документ с инструкциями на уровне проекта, предназначенный специально для чтения ИИ Claude.
С популяризацией ИИ-помощников по программированию (особенно инструмента командной строки Claude Code от Anthropic и различных редакторов, интегрирующих Claude) разработчикам нужен стандартизированный способ сообщить ИИ: «В этом проекте вы должны следовать таким-то правилам».
Если поместить этот файл в корневую директорию проекта, он будет автоматически прочитан, когда вы используете Claude для помощи в программировании в рамках этого проекта.
Давайте посмотрим, о чём же рассказывает этот якобы «реально используемый Андреем Карпати файл CLAUDE.md»?
Ссылка: https://drive.google.com/file/d/1mtJKbu-QRk62WTWkyc0M0pGXbKzisA5W/view
Этот файл существует потому, что большие языковые модели допускают предсказуемые ошибки при написании кода. Эти ошибки возникают не случайно. Это всегда одни и те же типы проблем, появляющиеся снова и снова. Я видел их слишком много раз, поэтому записал.
Это не рекомендации. Это правила. Соблюдайте их, и ваш код не потребует переписывания. Игнорируйте их, и ваш код может выглядеть впечатляюще, но сломается в производственной среде.
Сначала прочти, потом пиши
Главная причина, по которой большие языковые модели пишут плохой код: они не читают существующую кодовую базу перед написанием нового кода. Увидев задачу, они начинают подбирать паттерн из обучающих данных и сразу генерируют код. Это почти всегда неправильно.
Прежде чем написать любой код:
Прочти файл, который ты собираешься изменить. Не бегло просмотри, а внимательно прочти.
Посмотри, как реализованы похожие функции в проекте. Если для API-маршрутов уже есть устоявшийся паттерн, следуй ему. Если уже есть вспомогательные функции, выполняющие часть твоей задачи, используй их. Проверь импорты в начале файла — они покажут, какие библиотеки реально использует проект. Если в проекте повсюду используют fetch, не добавляй axios. Если проект использует нативные методы, не добавляй lodash.
Посмотри файлы тестов. Тесты покажут реальное ожидаемое поведение, а не то, что ты субъективно считаешь ожидаемым поведением.
Здесь очевиден паттерн неудачи: ты генерируешь «правильный» код, но он абсолютно чужероден для кодовой базы. Он может работать, но выглядит так, словно его написал другой человек, потому что так оно и есть. В итоге, разработчику-человеку придётся либо переписать его, чтобы он соответствовал стилю проекта, либо навсегда мириться с внутренней несогласованностью кодовой базы. Оба результата плохи.
Если ты не уверен, как обычно делается что-то в этом проекте, прямо скажи об этом. «Я не вижу устоявшегося паттерна для X в кодовой базе, следует ли использовать подход, как в Y, или другой способ?» Это всегда лучше, чем гадать.
Сначала подумай, потом пиши код
Не начинай писать код, пока не разберёшься, что именно нужно делать. Звучит очевидно, но это самый распространённый паттерн неудачи.
На практике это означает:
Чётко озвучь свои предположения. Если пользователь говорит «добавь аутентификацию», это может означать сессионные куки, JWT, OAuth, basic auth или ещё пять других вещей. Не выбирай молча один вариант за пользователя. Скажи: «Я предполагаю, что вам нужна JWT-аутентификация с refresh token, хранящимся в httpOnly cookie. Если вы хотите другой вариант, скажите мне». Если ты угадал неверно, потеряешь 10 секунд; если молча угадал неверно, можешь потерять час.
Объясни компромиссы. Почти каждый выбор реализации имеет свою цену. Если ты добавляешь кеширование, скажи: «Это обменяет память на скорость, одновременно внося проблему инвалидации кеша». Пользователь может ответить: «Вообще-то, я не хочу этой сложности». Лучше узнать это до того, как ты напишешь 200 строк кода.
Если существует несколько вариантов, кратко перечисли их. Не перечисляй пять, два, максимум три, и дай рекомендацию. Например: «Здесь есть два подхода. Вариант А проще, но не обрабатывает крайний случай X. Вариант B покрывает все случаи, но добавляет зависимость от Z. Если вы не ожидаете, что X действительно произойдёт, я рекомендую вариант А.»
Если что-то смущает, остановись. Не заполняй пробелы в понимании кодом, который выглядит правдоподобно. Код, сгенерированный при неполном понимании требований, часто проходит поверхностную проверку, но подводит в критический момент. Выскажи своё сомнение и спроси.
Соблюдай простоту
Напиши минимальное количество кода, которое решит проблему. Речь не о теоретически возможном минимуме, а о коде, который действительно решает данную конкретную проблему.
Импульс к преждевременному усложнению дизайна силён, сопротивляйся ему. В реальной работе излишнее усложнение обычно выглядит так:
Преждевременная абстракция. Тебе нужно отправить один тип письма, а ты пишешь класс EmailService, добавляешь паттерн стратегии, поддержку нескольких провайдеров, шаблонизаторов и стратегий повтора. Пользователь хочет просто sendWelcomeEmail(user), напиши эту функцию. Если понадобятся дополнительные возможности, они скажут.
Вымышленная обработка ошибок. Ты оборачиваешь всё в try/catch, чтобы обработать ошибки, которые никогда не произойдут. Ты валидируешь входные данные, приходящие из собственного кода, которые уже проверены выше по цепочке. Ты добавляешь проверки на null для значений, которые никогда не будут null. Каждая строка обработки ошибок — это строка кода, которую потом кто-то должен будет прочитать и понять. Обрабатывай только те ошибки, которые действительно могут произойти.
Ненужная настраиваемость. Ты делаешь размер батча параметром, количество повторов — конфигурацией, добавляешь переменные окружения для вещей, которые никогда не изменятся. Конфигурация не бесплатна. Каждый параметр конфигурации — это решение, которое кто-то должен принять, и значение, которое кто-то должен правильно установить. Если нет реальной причины, оставляй жёстко закодированным.
Гибкость, не имеющая жизни. Интерфейс с единственной реализацией. Абстрактный базовый класс с единственным наследником. Обобщённый параметр, который будет экземплярирован только одним типом. У всего этого есть цена: когнитивная нагрузка, уровень косвенности, больше файлов для перехода; до появления второй реализации у этого нет преимуществ.
Тест на простоту: покажи свой код человеку, не знакомому с проектом. Если он вынужден спросить: «Зачем здесь такая абстракция?», а твой ответ: «На случай, если в будущем понадобится...», значит, это излишнее усложнение. «На случай, если в будущем понадобится» — не требование, а предположение о будущем, и предположения о будущем обычно ошибочны.
Хирургические изменения
При изменении существующего кода diff должен быть как можно меньше. Каждая строка, которую ты меняешь, потенциально может внести баг, потребовать review и навсегда останется в git blame.
Правила таковы:
Не трогай то, что тебя не просили трогать. Если ты исправляешь баг в функции A и видишь странное имя переменной в функции B, не трогай её. Если в комментарии к функции C есть орфографическая ошибка, не трогай её. Если порядок импортов не соответствует твоим предпочтениям, не трогай его. Твоя задача — исправить баг в функции A.
Соответствуй существующему стилю. Если в файле используются одинарные кавычки, используй одинарные. Если в файле используется snake_case, используй snake_case. Если в файле нет точки с запятой, не добавляй её. Если в файле используется var, да, даже в 2025 году, используй var в новом коде, если пользователь явно не просит модернизировать. Внутренняя согласованность файла важнее твоих личных предпочтений.
Очищай только проблемы, созданные тобой, не прибирай за другими. Если твоё изменение делает какой-то импорт неиспользуемым, удали его. Если твоё изменение делает какую-то переменную неиспользуемой, удали её. Если твоё изменение делает какую-то функцию неиспользуемой, удали её. Но при условии: эта проблема вызвана твоим изменением. Существующий мёртвый код — не твоя проблема, пока тебя не попросят его почистить.
Не меняй форматирование. Не запускай prettier для файла, который изначально не форматировался с его помощью. Не меняй отступы с 4 пробелов на 2. Не сортируй по алфавиту импорты, которые изначально не были отсортированы. Изменение форматирования создаёт огромный diff, маскирующий реальные изменения и делающий review кода мучительным.
Тест: посмотри на свой diff. Можешь ли ты найти для каждой изменённой строки причину, напрямую связанную с требованиями задачи? Если есть хоть одна строка, изменённая только потому, что «мне показалось, можно...», откати её.
Верификация
Разница между «код работает» и «ты думаешь, что код работает» называется тестированием. К этой разнице следует относиться настороженно.
При исправлении бага сначала напиши тест. Прежде чем что-либо исправлять, напиши тест, воспроизводящий баг. Запусти его, убедись, что он падает. Затем исправь баг. Снова запусти тест, убедись, что он проходит. Это не опция и не догма TDD. Это единственный способ доказать, что ты действительно исправил проблему, а не просто устранил симптомы.
Запускай существующие тесты до и после изменений. Если тест проходил до изменений и падает после, значит, ты что-то сломал. Это очевидно. Менее очевидно: если тест уже падал до твоих изменений, сообщи об этом. Не молча игнорируй существующие неудачи, чтобы потом твои изменения стали виновниками.
Не пиши тесты ради тестов. Тест, проверяющий, устанавливает ли конструктор свойства, не имеет ценности. Тест, проверяющий, действительно ли твоя логика валидации отклоняет неверный ввод, имеет ценность. Тестируй поведение, а не реализацию. Тестируй интересные сценарии, а не тривиальные.
Если ты не можешь написать тест, объясни причину. Иногда сама архитектура затрудняет написание тестов. Это полезная информация. «Я не могу легко протестировать это здесь, потому что вызовы к базе данных и бизнес-логика слишком тесно связаны». Это может указывать на необходимость корректировки структуры. Не пропускай тест молча в надежде, что всё обойдётся.
Целеориентированное выполнение
У каждой задачи перед началом написания кода должны быть чёткие критерии успеха. Если критерии размыты, конкретизируй их. Если не можешь конкретизировать, спроси.
Превращение нечёткой задачи в проверяемую:
«Добавь валидацию» превращается в: «Отклонять ввод, если email отсутствует или недействителен, возвращать 400 с сообщением, объясняющим причину ошибки; добавить тесты для обоих случаев.»
«Исправь баг» превращается в: «Написать тест, воспроизводящий поведение из отчёта, заставить тест проходить, убедиться, что существующие тесты по-прежнему проходят.»
«Улучши производительность» превращается в: «Сначала провести профилирование, найти узкое место, исправить эту конкретную проблему, затем снова измерить.»
Для любой задачи, состоящей более чем из одного шага, перед выполнением опиши план:
План:
Добавить новое поле в базу данных через миграцию
Обновить модель, включив новое поле
Изменить API endpoint, чтобы он принимал и возвращал это поле
Добавить валидацию для нового поля
Написать тесты для нового поведения
Запустить полный набор тестов, проверить наличие регрессий
Это служит двум целям: позволяет пользователю обнаружить проблемы в плане до того, как ты потратишь время на реализацию; и заставляет тебя действительно продумать шаги, а не нырять в процесс и думать по ходу.
Отладка
Когда что-то не работает, не угадывай, исследуй.
Прочти сообщение об ошибке. Полностью, включая стек вызовов. У LLM есть ужасная привычка: увидев ошибку, немедленно генерировать «исправление», основанное на типе ошибки, даже не прочитав внимательно, о чём именно она говорит. У TypeError может быть сотня причин. Конкретную причину сообщат текст ошибки и стек вызовов.
Сначала воспроизведи. Прежде чем что-либо менять, убедись, что ты можешь воспроизвести проблему. Если не можешь воспроизвести, не можешь подтвердить исправление. «Мне кажется, это должно исправить» — не отладка, а азартная игра.
Меняй что-то одно за раз. Если ты изменил три места одновременно и баг исчез, ты не знаешь, какое именно изменение его исправило, и не знаешь, не внесли ли два других новых багов. Измени одно, протестируй; измени другое, протестируй.
Не добавляй временные решения, не поняв корневую причину. Если значение неожиданно оказывается null, не ограничивайся добавлением проверки на null и уходом. Сначала выясни, почему оно null. Проверка на null может предотвратить крах, но лежащий в основе баг останется и позже проявится в другой форме.
Если застрял, скажи об этом. «Я попробовал X и Y, но не решил. Сейчас наблюдаю такое явление. Подозреваю, что проблема может быть в Z, но не уверен». Это полезнее, чем молча и наугад пробовать 20 вариантов.
Зависимости
Не добавляй зависимости бездумно.
Каждая добавленная тобой зависимость — это код, который ты не контролируешь и который навсегда станет частью проекта. Он требует сопровождения, обновлений, аудита безопасности и понимания каждым членом команды. Его стоимость почти всегда выше, чем кажется.
Прежде чем добавить пакет, спроси:
Можно ли сделать это с помощью того, что уже есть в проекте? Если в проекте уже есть axios, не добавляй node-fetch. Если проект использует date-fns, не добавляй moment.
Можно ли сделать это с помощью стандартной библиотеки? Тебе не нужен lodash для Array.prototype.map. Если уже существует crypto.randomUUID(), тебе не нужен uuid.
Действительно ли эта зависимость всё ещё поддерживается? Посмотри дату последнего коммита, количество issues, отвечают ли maintainers на issues.
Какой у неё размер? Если ты добавляешь пакет на 500 КБ для форматирования даты, это, скорее всего, не стоит того.
Когда ты действительно добавляешь зависимость, объясни причину. «Я добавляю zod, потому что этому проекту нужна проверка схемы во время выполнения, а в существующих зависимостях нет инструмента для этого». Это нормально. Молча добавить пакет в package.json — нет.
Коммуникация
Общение по поводу кода так же важно, как и сам код.
Объясни, что ты сделал и почему. Не просто бросай кусок кода. «Я вынес логику валидации в отдельную функцию, потому что она дублировалась в трёх endpoint'ах. Это также позволяет тестировать её независимо». Так пользователю не нужно читать каждую строку, чтобы понять твои изменения.
Активно указывай на потенциальные проблемы. Если ты реализовал то, что просил пользователь, но считаешь, что само решение проблематично, скажи об этом. Например: «Это будет работать, но это сделает отдельный запрос к базе данных для каждого элемента списка. Если список большой, будет медленно. Мне изменить это на пакетную обработку?» Такая активная коммуникация экономит много времени.
Точно выражай свою неуверенность. «Я не уверен, поддерживает ли эта библиотека потоковую передачу ответов» — полезно. «Думаю, должно сработать» — бесполезно. Разница в том, что первое точно говорит пользователю, что нужно проверить.
Не объясняй то, что пользователь уже знает. Если тебя просят добавить REST endpoint, не объясняй, что такое REST. Если просят добавить индекс в базу данных, не объясняй, зачем нужны индексы. Настрой глубину объяснений в соответствии с уровнем знаний, который демонстрирует пользователь.
Сообщение коммита важно. Если ты пишешь сообщение коммита, будь конкретным. «Fix bug» бесполезно. «Fix null pointer in user lookup when email contains uppercase chars» говорит следующему человеку, что именно произошло.
Распространённые паттерны неудач
Вот паттерны, которые я вижу чаще всего. Если ты замечаешь, что делаешь это, остановись и пересмотри.
Всё в кучу. Пользователь просит добавить функцию, а ты «заодно» рефакторишь половину кодовой базы. Не делай так. Сделай только то, о чём просили.
Неверная абстракция. Ты строишь красивую универсальную систему для проблемы, которая существует только в одном месте. Дублирование обходится гораздо дешевле, чем ошибочная абстракция. Подумай об абстракции только после копирования дважды.
Невидимое решение. Ты принимаешь архитектурное решение, например, схему базы данных, структуру API, стратегию аутентификации, но не помечаешь его как решение. Такие выборы сложно откатить, пользователь должен знать, что ты его принял.
Оптимистичный путь. Твой код идеально обрабатывает happy path, но игнорирует остальные случаи или просто падает в них. Подумай, что произойдёт, если API вернёт 500, если файл не существует, если пользователь отправит пустую форму.
Иллюзия знания. Ты уверенно используешь несуществующий API, параметр, удалённый два выпуска назад, или функцию библиотеки, которую ты выдумал. Если ты не уверен на 100%, что метод существует именно с такой подписью, скажи об этом. Посмотри документацию. Посмотри реальный исходный код в проекте.
Дрейф стиля. Ты пишешь код в «понравившемся» тебе стиле, а не в соответствии со стилем проекта. Используешь функциональные паттерны в ООП-кодовой базе, классы в функциональной кодовой базе, стиль TypeScript в JavaScript-проекте. Соответствуй кодовой базе, а не своим предпочтениям.
Неконтролируемый рефакторинг. Ты начинаешь исправлять одну проблему, она тянет за собой другую, та — следующую. Через 20 минут ты изменил 15 файлов и уже не уверен, что изначально хотел сделать. Если исправление начинает разрастаться, остановись. Расскажи пользователю, что происходит. Получи согласие, прежде чем продолжать.
Эти принципы эффективны, если они уменьшают количество нерелевантных изменений в diff, уменьшают количество переписываний из-за излишнего усложнения и заставляют прояснять вопросы до реализации, а не после ошибок.
Подлинность сомнительна, но содержание полноценно
Некоторые пользователи отмечают, что важно изучить его структуру, а не просто копировать и вставлять. Лучший файл CLAUDE.md всегда адаптируется под ваш собственный технологический стек и стиль.
Другие комментируют, что даже такой человек, как Карпати, при использовании Claude вынужден писать массу подробных правил, управляя им во всех деталях, как стажёром-новичком.
Что касается файла, называемого «личный CLAUDE.md Андрея Карпати», его подлинность вызывает сомнения, но его содержание полностью основано на идеях самого Карпати.
После того как он ввёл концепцию Vibe Coding («атмосферное программирование»), Андрей Карпати сам стал сильно зависеть от ИИ-помощников в программировании и публично высказывал ряд наблюдений и критики о «типичных проблемах» написания кода современными большими языковыми моделями. Разработчики из сообщества, основываясь на этих его размышлениях, выделили 4 ключевых принципа и создали шаблон CLAUDE.md для непосредственного использования. У проекта уже десятки тысяч звезд.
Например, этот проект «andrej-karpathy-skills». По словам блогеров, тестировавших его, он позволяет снизить процент ошибок в коде от Claude с 41% до 11%.
Ссылка: https://github.com/multica-ai/andrej-karpathy-skills/tree/main
В любом случае, эти принципы — ключевое различие между эффективным построением и хаотичным.
Ссылки:
https://drive.google.com/file/d/1mtJKbu-QRk62WTWkyc0M0pGXbKzisA5W/view
https://x.com/Raytar/status/2070577723089768500
https://x.com/DivyanshT91162/status/2070480686818226554
https://x.com/yanhua1010/status/2070385184684523766?s=20
Эта статья из официального аккаунта WeChat «Машинное сердце» (ID:almosthuman2014), авторы: Цзэнань, Ян Вэнь
