Как научить Клода писать код без лишнего мусора
Знакомая история: просишь нейронку поправить пару строк в функции, а она в ответ выкатывает простыню на триста строк с кучей новых абстракций, попутно стирая важные комментарии. В итоге тратишь больше времени на ревью и чистку «помощи», чем на само написание кода. Андрей Карпати, бывший директор по ИИ в Tesla, тоже заметил, что большие языковые модели (LLM) часто грешат оверинжинирингом и тягой к неоправданным усложнениям.
В репозитории andrej-karpathy-skills собрали опыт Карпати и упаковали его в один компактный файл CLAUDE.md. Это набор инструкций, который меняет поведение Claude Code или Cursor, заставляя их вести себя как толковый Senior-разработчик, а не как восторженный джун-переросток.
Что не так с обычными нейронками
Карпати выделил несколько проблем, с которыми сталкивается каждый, кто пытался автоматизировать написание кода. LLM обожают делать предположения за вас. Если что-то непонятно, они не переспрашивают, а просто выбирают один вариант и фигачат до победного.
Часто это выливается в архитектурный ад. Там, где хватило бы десяти строк чистого кода, модель может накрутить монстра на тысячу строк. Еще они регулярно «забывают» чистить мертвый код, который сами же и создали в процессе правок, или неожиданно рефакторят те куски программы, которые вы просили вообще не трогать.
Четыре столпа адекватного кодинга
Проект предлагает решение через внедрение четырех принципов. Они прописаны прямо в конфигурационном файле, который нейронка считывает перед началом работы.
Сначала думаем, потом пишем Вместо того чтобы сразу прыгать в реализацию, Claude должен проговорить свои допущения. Если в задаче есть неочевидные моменты, модель обязана предложить варианты и спросить: «Мы пойдем путем А или Б?». Это экономит кучу времени, потому что ошибка отсекается еще до того, как был написан первый символ кода.
Простота во главе угла Это мой любимый пункт. Инструкция запрещает модели добавлять фичи «на будущее», вводить сложную конфигурацию, которую не просили, или создавать абстракции для кода, который используется всего один раз. Если задачу можно решить без привлечения новых библиотек — она должна быть решена без них.
Хирургическая точность Знаете это чувство, когда при проверке диффа видишь изменения в соседних файлах, которые вообще не относятся к делу? Этот принцип жестко ограничивает зону ответственности ИИ. Трогать разрешено только то, что напрямую касается задачи. Никаких «попутных» рефакторингов, улучшений форматирования в чужих модулях или удаления старых комментариев.
Работа на результат через тесты Вместо размытых просьб «сделай, чтобы работало», проект продвигает подход, ориентированный на цели. Сначала пишем тест, который воспроизводит баг или проверяет новую логику, и только потом пишем код, пока эти тесты не пройдут. Это превращает процесс из гадания на кофейной гуще в проверяемый цикл.
Как это закинуть в свой проект
Есть два простых способа. Если вы пользуетесь инструментом Claude Code, можно поставить официальный плагин через маркетплейс:
/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
Если же вы предпочитаете работать по старинке или используете Cursor, достаточно просто положить файл CLAUDE.md в корень своего проекта. Можно сделать это одной командой в терминале:
curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md
Кстати, для Cursor в репозитории есть готовый файл правил в папке .cursor/rules. Это удобно, если вы хотите, чтобы эти гайдлайны применялись автоматически ко всем чатам внутри этого IDE.
Почему это работает
Главный инсайт, который заложил Карпати: LLM феноменально хороши в циклах, пока у них есть четкие критерии успеха. Если сказать модели «сделай хорошо», она сделает «как-нибудь». Если дать ей план из трех пунктов и заставить проверять результат после каждого шага — качество кода вырастает в разы.
Я попробовал этот подход на небольшом скрипте для обработки данных. Claude действительно стал чаще задавать уточняющие вопросы и перестал переписывать мои функции обработки ошибок на свой лад. Код стал выглядеть суше и скучнее, но в этом и есть вся прелесть — он просто делает то, что от него ждут, без лишней магии.
Стоит ли пробовать
Если вы активно используете ИИ-ассистентов для кодинга, то этот конфиг — мастхэв. Он особенно пригодится тем, кто работает в больших проектах с устоявшимся стилем, где любая лишняя правка превращается в головную боль на код-ревью.
Конечно, для мелких задач или когда вы просто прототипируете идею «на коленке», такая строгость может показаться излишней и даже замедлить процесс. Но как только дело доходит до серьезного продакшн-кода, эти правила окупаются мгновенно. Главное помнить, что эти инструкции — не догма. Их можно и нужно дополнять своими правилами, специфичными для вашего стека.
