Топ-советы по Claude Code от Бориса Черни и не только: гайд на 56k звёзд — что реально работает, а что мимо

• Главный вывод про поиск: «Claude Code выкинул RAG» и «я внедряю Graphify» — не спор, а две половины одного гибрида. Для кода побеждает связка grep + структурный индекс (tree-sitter/AST), а не чистый grep и не чистый вектор.

• Вектор проиграл коду по делу, а не вообще: точность (символ есть или нет), свежесть (индекс устаревает), чанкинг (кусок ≠ логическая единица). А слабость grep — расход токенов — чинится специализированными search-моделями, не переходом на вектор.

• Сам создатель Claude Code выбрал agentic search «по ощущениям» — его признание на Latent Space. И это, как ни странно, нормально: в поле, где модели обновляются каждые 6 недель, «лучшая практика» живёт месяца три. Вывод — свои замеры и живое обсуждение дороже любого чужого списка.

• Что из репо реально работает (проверял сам): plan mode в начале каждой задачи; «дай модели способ проверить свой результат» (совет самого Черни); просить по 3-4 варианта, особенно на UI/UX; помнить про гниение контекста к ~40% (в 1M Claude Code за этим следишь руками, в Codex/ChatGPT окно компактится само).

• Сам репозиторий — shanraisshan/claude-code-best-practice, под 56 тысяч звёзд (на момент написания, июнь 2026), #1 в GitHub Trending: курс-карта по всей экосистеме Claude Code, 13 методологий, 83 совета. Внутри — в том числе датированные советы Бориса Черни.

• Навигатор по репо на русском, с приоритизацией советов по реальной пользе, выложу архивом в Telegram.

---

Мне скинули ссылку на репозиторий claude-code-best-practice. Под 56 тысяч звёзд, первое место в GitHub Trending, внутри — разложенные субагенты, команды, скиллы, хуки, MCP, 13 методологий оркестрации и 83 совета по работе с Claude Code. Часть советов — прямые цитаты Бориса Черни, того самого человека, который Claude Code и сделал.

И вот тут меня накрыло неприятным узнаванием. Я весь последний год писал статьи. Про оркестрацию агентов через контракты. Про индексацию кода. Про память агентов. Про выбор модели под продакшен. По одной теме за раз, по кусочкам. А парень из Пакистана взял и собрал всё это в один атлас — и получил 56 тысяч звёзд за полгода.

Что это вообще за штука

Сразу расставлю точки. Автор репозитория — shanraisshan, не Anthropic и не создатель Claude Code. Это куратор: он собрал и разложил чужие наработки, в том числе советы создателя. А создатель — Борис Черни (@bcherny), и его твиты-советы лежат в репо отдельными датированными файлами: claude-boris-15-tips-30-mar-26.md и подобными. Так что формула: куратор собрал, создатель — один из источников.

Репозиторий сам про себя говорит: «читай как курс, а не как workflow». Внутри нет одной правильной системы, которую можно распаковать и поставить. Есть структурированная подборка: вот примитивы (субагенты, команды, скиллы, хуки, MCP, память), вот «горячее» (Dynamic Workflows, Agent Teams, Computer Use), вот 13 методологий от Superpowers до Spec Kit, вот cross-model подходы, вот 83 совета по категориям.

Интересная деталь: все 13 методологий, при всей их разности, сходятся к одному скелету — Research → Plan → Execute → Review → Ship. Это, пожалуй, главный вывод раздела: рынок методологий большой, а паттерн под ним один.

Это карта территории, по которой я ходил

Дальше — то, ради чего я вообще сел писать. Открываешь оглавление репозитория, и каждый раздел отзывается собственной статьёй.

Раздел про оркестрацию и workflows — это ровно то, про что я писал в разборе своего оркестратора для Codex: контракты вместо умного промпта, Parallel Decomposition Matrix, worker-контракт на каждого субагента. Репо перечисляет методологии — я показывал, как одна такая система собирается и где она протекает.

Раздел про автономных агентов и самопроверку (там, где Dynamic Workflows и Agent Teams) — это моя статья про честность Opus 4.8. Тезис был: сотня параллельных субагентов бесполезна, если они врут друг другу. И, кстати, в репо лежит совет самого Черни, который бьёт ровно в эту точку — но к нему вернусь чуть ниже, он заслуживает отдельного абзаца.

Раздел про навигацию агента по коду — это «CodeGraph vs Graphify». И вот здесь карта со мной спорит. До спора дойду, он — гвоздь статьи.

Плюс боковая связка. Выбор модели — боевой тест на русском контенте, где средняя модель с правильной обвязкой била топовую с мусорным контекстом.

Получается забавная штука. Репозиторий — это карта, на которой подписаны узлы. А мои статьи — это что происходит, когда в каждый узел реально спускаешься с лопатой.

Совет создателя, который стоит всех остальных

В подборке советов Черни есть один, который я бы вынес на первую страницу и подчеркнул маркером. Дословно мысль такая: самое важное в работе с Claude Code — дать модели способ проверить собственный результат. Как только дал — она будет итерировать, пока не станет хорошо.

Это не «ещё один совет из 83». Это фундамент. Я целую статью построил вокруг разницы между «агент сказал, что тесты зелёные» и «агент показал вывод тестов». Completion event — не то же самое, что acceptance. И когда создатель инструмента независимо формулирует ту же мысль через короткий твит — это приятная валидация: значит, копал в правильную сторону.

Там же, в советах Черни, ещё пара точных наблюдений. Его собственный сетап «на удивление ванильный» — он почти не кастомизирует Claude Code, потому что тот хорошо работает из коробки. Начинает почти каждую сессию в plan mode (shift+tab дважды), гоняет план туда-сюда, и только потом переключается в авто-режим. И статистика, которую он показал скриншотом: 141 PR, всегда squash, медиана — 118 строк на PR. Мелкие частые PR против больших редких. С этим спорить трудно.

Что из остального действительно работает — по моему опыту

Раз уж зашла речь про советы…

Гниение контекстного окна — безоговорочно в золото. Совет звучит так: умнеть модель перестаёт сильно раньше, чем заполнит окно, на практике где-то к 40%. Это стопроцентно мой опыт. И к нему — личное раздражение: в Claude Code с его миллионным контекстом за этим приходится следить руками, чтобы не проскочить порог, после которого ответы плывут. Я уже ворчал, что не верю заявкам про длинный контекст, пока не прогоню сам. А в Codex и ChatGPT этой головной боли нет: окно меньше, зато компактится автоматически — и ты просто не думаешь о пороге. Вот вам и парадокс: миллион токенов оказался не подарком, а ещё одной вещью, за которой надо следить.

Plan mode — работает ровно как обещано. Начать в режиме плана, погонять туда-сюда, согласиться — и только потом пускать в авто. У меня почти каждая нетривиальная задача так и идёт.

«Билд дешёвый — делай не ТЗ, а 20-30 вариантов» — мой любимый. Я сам постоянно прошу не один результат, а три-четыре на выбор. Особенно на UI и UX: дешевле посмотреть четыре живых варианта и ткнуть в лучший, чем расписывать словами, чего я хочу. Тут совет попадает в точку.

А про вредные советы — честно, прямо вредных я не вижу. Есть ловушки применения. Тот же миллионный контекст: совет «следи за гниением» правильный, но сама необходимость следить руками — это уже не достоинство инструмента, а его цена, про которую в восторженных тредах забывают.

И обратная честность: в репо разрекламирован /sandbox — срежет запросы на подтверждение действий процентов на восемьдесят. Я его не пробовал и необходимости не почувствовал — мне проще аккуратно использовать claude --dangerously-skip-permissions.

Гвоздь: «glob+grep бьёт RAG» против моего Graphify

Теперь главное. Репозиторий держит жёсткую позицию, и эта позиция — Anthropic’овская, не выдуманная куратором: Claude Code не индексирует ваш код. Никаких эмбеддингов, никаких векторных БД. Только agentic search — glob и grep (точнее, ripgrep), как ищет живой человек.

А я последние недели внедряю Graphify во все свои проекты. Граф знаний по коду. И он работает: быстро поднимается, точно отвечает, заметно срезает расход токенов. Так кто из нас неправ — я, который ставит индекс везде, или репозиторий с 56 тысячами звёзд, за которым стоит сам Anthropic?

Борис Черни на подкасте Latent Space (май 2025) и потом на Hacker News рассказал: ранний Claude Code использовал RAG с локальной векторной базой. Они его попробовали по-настоящему. А потом выкинули, потому что agentic search «обогнал всё, причём сильно — и это было неожиданно». И тут же честно добавил: оценивали «в основном по ощущениям, внутренним vibes; были и внутренние бенчмарки, но в основном — vibes. Просто ощущалось лучше».

Создатель — сторона заинтересованная, он хвалит свой продукт. Но это признание скорее против себя: «мы вложились в RAG и выбросили его по ощущениям».

Вдумайтесь: флагманский инструмент Anthropic, на котором половина индустрии теперь строит разработку, выбрал архитектуру поиска не по бенчмаркам, а потому что «так ощущалось лучше». Я перечитал дважды — нет, не показалось. System cards на сорок страниц, alignment-исследования, а ключевое решение про retrieval принято на «нам зашло». С одной стороны, несолидно для проекта. С другой — а кто из нас в 2026-м выбирает поведение агентов иначе? Я свои решения по агентам половину времени принимаю ровно так же, по ощущениям. Просто за мной не стоит 56 тысяч звёзд и подкаст Latent Space, поэтому мне можно.

Дальше я собрал реальные аргументы — почему grep для кода и правда обыгрывает векторный поиск:

• Точность. Символ createD1HttpClient либо есть в файле, либо нет. Никаких «концептуально близких» совпадений. А векторный поиск как раз вытаскивает близкое по смыслу — и для кода эта «смысловая близость без текстового совпадения» обычно шум, а не сигнал.

• Свежесть. Предсобранный индекс устаревает с каждым редактированием файла. Эмбеддинги надо непрерывно пересчитывать — дорого и с задержкой. А чтение файла всегда актуально.

• Простота. Нет модели эмбеддингов, нет векторной БД, нет пайплайна реиндексации, нет стратегии чанкинга. ripgrep просто работает. И find работает. И cat.

• Приватность. Локальный поиск — данные не покидают машину. Для enterprise это весомо.

Звучит убедительно. Но не согласен — потому что есть контраргумент, и он ровно про мой случай.

Команда Milvus (это как раз векторная БД) возражает: grep-only расточителен по токенам. Каждый поиск — буквальное совпадение строк, и разработчик в итоге просеивает стог нерелевантных совпадений, прежде чем найдёт нужное. Они заявляют, что их векторное решение режет расход токенов на 40% с лишним. И вот это уже похоже на то, что я наблюдаю с Graphify: меньше токенов, быстрее ответ.

Anthropic выбросил не «индексацию вообще». Они выбросили векторный RAG поверх кусков кода — эмбеддинги, семантическую близость, чанкинг. И для навигации по коду (найти символ, найти использование) grep их честно обыгрывает по всем четырём пунктам выше.

Но Graphify и CodeGraph — это не векторный RAG. Это структурный граф: символы, импорты, вызовы, типы — детерминированно, через разбор синтаксиса (tree-sitter), без всякой «смысловой близости». И здесь всплывает то, что обычно и топит вектор именно на коде, — чанкинг. Векторный поиск возвращает куски фиксированного размера, и этот кусок почти никогда не совпадает с логической единицей: половина функции, обрывок класса. Структурный граф отдаёт цельный узел. То есть Graphify даёт ту самую точность, которую ценит лагерь grep, и закрывает его единственную реальную слабость — расход токенов.

А возражение про устаревание индекса? Я его уже закрыл в статье про CodeGraph: индекс — это регенерируемый кэш, а не коммитимый артефакт. Source of truth — код в git, индекс производный, лежит в .gitignore и пересобирается по file watcher. Свежесть перестаёт быть проблемой, если не делать вид, что индекс — это истина.

Дальше я полез за измеримым — не люблю верить на слово, даже когда вывод мне приятен. Нашлось вот что. Появилась работа с честным заголовком «Is Grep All You Need?»: grep гоняли против векторного поиска на нескольких агентских обвязках, включая Claude Code, Codex и Gemini CLI. Вывод аккуратный: grep чаще даёт более высокую точность, но результат сильно зависит от самой обвязки — один и тот же grep в слабом и в сильном агенте ведёт себя по-разному. Augment на SWE-bench отдельно показывает, что grep-методы обходят эмбеддинги по корректности. А аргумент про токены, которым размахивала Milvus, переворачивают специализированные search-модели: те же результаты они выдают примерно втрое меньшим числом обращений к модели. Значит, grep можно сделать токеноэффективным, не уходя в вектор.

И вот тут — главное. Тут я поправлю сам себя. Выше по тексту я красиво обозвал структурный граф «третьим углом треугольника». Нет. Данные говорят проще: побеждает не угол, а гибрид. Cursor идёт путём «маленький векторный слой плюс куча инструментов». Cline собирает поиск в три яруса: ripgrep + fzf + tree-sitter. А в одном публичном разборе инженер показал: добавление к вектору обычного BM25 подняло точность поиска примерно с 60% до 85%. Прав не grep и не вектор, права их связка. А для кода эта связка — не «вектор + grep», а grep + структура (tree-sitter/AST). То есть ровно grep + Graphify.

Так что «выкиньте RAG» и «внедряю Graphify» — это не спор двух лагерей. Это две половины одного гибрида.

Согласен ли я с таким примирением полностью? Отчасти. Мне не хватает того же, чего не хватало и в признании Черни, — измеримых цифр на моих задачах, а не общих бенчмарков. Публичные замеры именно этого треугольника (grep против вектора против структурного графа на коде) пока тонкие, и почти каждый упирается в ту самую оговорку: результат зависит от обвязки агента. Плюс честная граница сверху: на по-настоящему больших репозиториях — ядро Linux, Chromium, крупные монорепо — даже миллион токенов контекста не вмещает всё, там без умного retrieval никак, и каким он должен быть (вектор, AST, смесь) — открытый вопрос. Поэтому финальный вердикт я выношу не из статьи, а из практики: соберу собственный замер на своих репозиториях и вернусь с числами. И очень хочу сверить — если вы гоняли grep против индекса или графа на реальном коде и считали токены, расскажите, что вышло.

Чего в карте не хватает

Во-первых, советы местами противоречат друг другу, и репо это не разруливает. «Пиши подробные спеки, чтобы убрать неоднозначность» соседствует с «не пиши ТЗ, построй 20-30 прототипов, стоимость билда низкая». Оба совета разумны — но в разных ситуациях, а карта не говорит, в каких.

Во-вторых, 13 методологий без подсказки, какую брать — это паралич выбора. Для новичка «вот тебе Superpowers, Spec Kit, gstack, BMAD, HumanLayer и ещё восемь» — не помощь, а перегрузка.

В-третьих — и это, по-моему, главное — это агрегатор опыта, которого пока ни у кого толком и нет. Звучит резко, но смотрите. Claude Code, агентной разработке, скиллам, субагентам — всему этому от силы год-два. Модели обновляются каждые шесть недель (а то и каждые четыре), поведение плывёт от версии к версии. В таком поле «лучшая практика» живёт месяца три, а потом половина советов протухает: фича, под которую совет писался, переехала, подешевела или просто исчезла. И вывод из неё ровно один: в области, где чужой опыт устаревает за квартал, дороже всего стоят собственные эксперименты, собственные замеры и живое обсуждение. Ради последнего я, собственно, и пишу — чтобы спорить и сверяться. В комментариях здесь и в канале — велкам.

Вот из этих дыр и родился артефакт.

Навигатор по репозиторию — на русском, с приоритетами

Сразу оговорюсь, чтобы не было ложных ожиданий: ценность тут не в переводе. Сообщество Хабра английский знает, а кому надо — современный переводчик решит вопрос за секунду. Русский и удобная вёрстка — приятный бонус, не суть. Суть — приоритизация по субъективной полезности, та самая прожитая оценка, которую агрегатор по определению дать не может.

Разложу советы и инструменты по группам — от «ультраполезное, ставь сегодня» через «полезное» и «ситуативное» до «переоценено» и «честно, мимо». К каждому пометка: использую сам / связано с такой-то моей статьёй / не зашло и почему. Плюс карта 13 методологий в один экран: когда какую брать, а не «вот вам тринадцать, разбирайтесь». Как всегда, признаю, что это всё ультра-субъективно.

Формат — PDF и HTML, как у моего гида по бенчмаркам LLM: и с экрана читать, и распечатать. Выложу архивом в Telegram-канал.

Зачем я вообще это написал

Если честно — чтобы самому разобраться. Я наткнулся на карту того, по чему ходил год, и захотел сверить её с собственными ногами. Не потому что не доверяю автору или Черни. А потому что не хочу верить на слово — каким бы известным ни был человек. Что-то из этой карты я и так делаю каждый день: начинаю в plan mode, прошу по три-четыре варианта на UI, держу в голове порог гниения контекста. Что-то возьму в работу, что-то нет. Но решать это я хочу, сверившись с практикой — своей и вашей, — а не по чужому списку.

По спору про поиск я уже сместился: «выкиньте RAG» и мой Graphify — не противоречие, а две половины одного гибрида. Но окончательный вердикт — после того, как прогоню репозиторий по своим проектам и вернусь с цифрами.

---

Навигатор по репозиторию (на русском, с приоритетами) выложу архивом в Telegram-канал — там же мои заметки по ежедневной работе с агентами. Если хотите поспорить про grep и индексацию или поделиться своим опытом с этим репо — пишите в личку. Мои инструменты оркестрации лежат на GitHub.

Мои разборы по узлам этой карты:

• Оркестрация через контракты — «Собрал оркестратор для Codex».

• Автономия и честность агентов — «Сотня субагентов бесполезна, если они врут».

• Индексация кода — «CodeGraph vs Graphify».

• Выбор модели под продакшен — боевой тест на русском.