Борис Черни больше не отправляет промпты Claude.
Это не пересказ, разошедшийся по сети. Это его собственное, публично зафиксированное заявление: «Я больше не отправляю промпты Claude. У меня работают циклы, которые отправляют промпты Claude и решают, что делать. Моя работа — писать циклы». Он повторял это в нескольких публичных выступлениях — в докладе в Sequoia, в интервью подкасту Acquired, в Startup School от Y Combinator, — и паттерн, лежащий в основе этих слов, и есть настоящая тема этой статьи. Не советы. Не список функций. Конкретный способ, которым человек, создавший Claude Code, реально использует его изо дня в день, подтверждённый его собственными публичными высказываниями, а не пересказом из вторых рук.
Это полный разбор, основанный на том, что Черни действительно говорил, плюс на официальной задокументированной практике Anthropic для инструмента, который он создал.
Claude Code никогда не должен был стать продуктом
Чтобы понять, как Черни использует инструмент, нужно понять, откуда он взялся, потому что происхождение объясняет философию. И эта история интереснее, чем думает большинство тех, кто пользуется инструментом сегодня.
Claude Code начинался в 2021 году как исследовательский проект по выравниванию ИИ, а не как продукт. Сначала грубое расширение для VS Code, затем внутренний CLI-инструмент под названием clide, использовавшийся внутри Anthropic годами, задолго до того, как о нём узнал кто-то за пределами компании. Черни присоединился к проекту в сентябре 2024 года и переписал ядро за двухнедельный спринт в декабре того же года. Публичный запуск в феврале 2025 года прошёл тихо, без особой помпы: его встретили скорее пожиманием плеч, чем восторгом. А потом вышел Claude 4, и популярность взорвалась почти за одну ночь.
Его собственная оценка того, где инструмент находится сейчас, высказанная напрямую: «Мы готовы только на 1%».
Эта формулировка важна для того, как вам стоит подходить к использованию инструмента. Черни описывает не готовый продукт с фиксированным «правильным» способом использования. Он описывает то, что до сих пор активно перестраивается командой, которая использует инструмент для создания самого инструмента. Claude Code неоднократно переписывался с помощью самого Claude Code — цикл самоулучшения, который появился задолго до того, как термин «loop engineering» вошёл в публичный обиход. На этом стоит задержаться на минуту, потому что это объясняет то, что сбивает с толку многих новых пользователей: почему «правильный» способ использования этого инструмента, кажется, постоянно меняется. Это не непоследовательность. Просто инструмент, чьи создатели до сих пор активно открывают его реальные возможности в реальном времени — с помощью самого инструмента.
Годы, проведённые в статусе внутреннего исследовательского инструмента до того, как он стал продуктом, объясняют и то, почему значительная часть философии ниже читается как необычно безапелляционная для разработческого софта. Большинство инструментов с первого дня обрастает функциями, чтобы удовлетворить широкую внешнюю базу пользователей с конкурирующими потребностями. Claude Code сначала накопил свою философию — внутри маленькой команды, решавшей собственные задачи, — и лишь потом перед ним встала необходимость подстраиваться под чьи-то чужие рабочие процессы. Именно поэтому понимание конкретных паттернов использования Черни — а не общих советов про «ИИ-инструменты для кода» — стоит того времени, которое нужно, чтобы по-настоящему это усвоить.
Ключевой сдвиг: от промптов к проектированию циклов
Самое важное из того, что Черни публично говорил о реальном использовании Claude Code, — это приведённое выше утверждение о циклах. Его стоит разобрать с точки зрения практики, а не просто как яркую цитату.
Промпт — это одиночная инструкция: отправлен один раз, получил один ответ. Цикл — это система: он отправляет промпт Claude, оценивает результат, решает, что делать дальше, и повторяет — без человека в центре каждого цикла. Сформулированное Черни описание его работы — «моя работа — писать циклы» — означает, что он проектирует системы, которые генерируют и оценивают промпты, а не набирает промпты сам, ход за ходом.
Его подтверждённый ежедневный рабочий процесс прямо это отражает. Телефон как основной интерфейс — а не клавиатура ноутбука. От пяти до десяти активных сессий одновременно, каждая из которых способна порождать субагентов: иногда несколько сотен разом, иногда несколько тысяч за ночь на более глубокой работе. Десятки циклов, непрерывно работающих в фоне: присматривают за пулл-реквестами, следят за здоровьем continuous integration, кластеризуют обратную связь по регулярному расписанию. Рутины, которые продолжают работать на серверной стороне, даже когда ноутбук закрыт.
Практический вывод для тех, кто использует Claude Code ежедневно: потолок возможностей инструмента определяется не тем, насколько хорош отдельный промпт, а тем, насколько хорошо вы спроектировали систему вокруг повторяющихся автоматических циклов «промпт → проверка → повтор».
Что на самом деле изменилось в системном промпте и почему это важно
Черни также прямо говорил о конкретном техническом решении, которое показывает, как он вообще мыслит об инструктировании Claude: «Мы удалили ~80% системного промпта Claude Code для наших новейших моделей. Вот чему мы научились в написании системных промптов».
Это сокращение произошло именно в поколении Opus 4.8: системный промпт уменьшился примерно с 15 000 до 4 500 символов без измеримой потери качества на задачах оценки кода. Урок, стоящий за этим, согласно собственному руководству Anthropic по контекстной инженерии, таков: жёсткие исчерпывающие списки правил перестают быть необходимыми, как только модель становится достаточно способной, чтобы применять настоящее суждение. Правила становятся оценочными суждениями. Примеры использования инструментов уступают место интерфейсам, которые документируют сами себя. Заранее загружаемый исчерпывающий контекст уступает место прогрессивному раскрытию: информация подтягивается только тогда, когда конкретная ситуация действительно этого требует, а не загружается по умолчанию в каждую сессию.
Один нюанс, который стоит честно упомянуть, поскольку он усложняет простую версию этой истории: когда вышел Opus 5, независимое тестирование разработчиков показало, что его фактический системный промпт оказался примерно на 72% длиннее, чем у Opus 4.8. Это не противоречие уроку выше, а его более глубокая версия. Промпт сжался в объёме жёстких инструкций, а затем снова вырос — за счёт более богатых и конкретных отсылок, проработанных примеров, тестовых наборов, рубрик оценки: того контекста, который по-настоящему более способная модель действительно может эффективно использовать. Вывод не в том, что «короче — всегда лучше». Вывод в том, что объём инструкций должен соответствовать тому, что конкретной модели реально нужно для вынесения хороших суждений, а не фиксированной цели в ту или иную сторону.
Написание CLAUDE.md так, как это делают команды Anthropic
Это напрямую связано с тем, как вам стоит структурировать собственные инструкции уровня проекта. В официальной документации Anthropic прямо описан нужный ментальный шаблон: представляйте Claude как блестящего, но очень нового сотрудника с амнезией, которому нужны явные инструкции.
Практические следствия этой рамки. «Блестящий» — значит, не нужно излишне объяснять общую компетентность: она уже есть. «Новый» — значит ноль накопленных знаний об истории и конвенциях вашего конкретного проекта. «Амнезия» — значит каждая сессия начинается с нуля, и CLAUDE.md — единственное, что надёжно переносит контекст между сессиями.
Задокументированные рекомендации Anthropic нацелены на то, чтобы держать файл в пределах 200 строк; некоторые из самых дисциплинированных команд ужимаются до 60. Тест на то, стоит ли чему-то быть в файле: это действительно релевантно почти каждой сессии или только узкому ситуативному срезу работы? Универсальные вещи — команды сборки, обязательные правила стиля, ожидания по тестированию, настоящие предохранители — принадлежат корневому файлу. Всё более узкое принадлежит импортируемому файлу, который подтягивается в контекст только тогда, когда конкретная работа сессии действительно этого требует, через синтаксис импорта @path/to/file, поддерживаемый инструментом напрямую.
Для инструкций, которые действительно нельзя пропустить, собственная внутренняя практика Anthropic использует явные маркеры акцентирования — «IMPORTANT» или «YOU MUST», — приберегая их для тех немногих правил, где цена того, что Claude их пропустит, действительно высока. Помечать так всё подряд — значит полностью обесценивать приём: он перестаёт работать как сигнал в тот момент, когда применяется без разбора.
Plan Mode: понять, прежде чем действовать
В практику работы с инструментом стоит встроить один конкретный поведенческий паттерн: пусть Claude планирует до того, как приступит к изменениям, а не прыгает сразу в правки.
Это не просто переключатель функции. Это отражает реальный сдвиг, который описывают собственные материалы Anthropic: новые модели планируют корректно, без необходимости в жёстком предварительном управлении, как ранним версиям, — до такой степени, что некоторые команды сообщают: им больше не нужно принудительно вставлять явный шаг plan mode для каждой задачи, потому что собственные рассуждения модели уже по умолчанию выдают связный план перед действием. Тем не менее для действительно сложных многофайловых изменений явный запрос плана в начале — с ревью перед одобрением исполнения — остаётся крайне полезной контрольной точкой: он ловит неверно понятое требование до того, как оно расползётся по дюжине файлов, а не после.
Субагенты и параллельная работа
Подтверждённый рабочий процесс Черни — сотни, иногда тысячи субагентов в одной сессии — указывает на структурную возможность, которую стоит понимать и использовать осознанно, а не случайно.
Основной агент может разложить сложную задачу на более мелкие части и развернуть субагентов для их независимого выполнения: каждый работает в своём контексте, вместо того чтобы всё конкурировало за место в одном непрерывном диалоге. Это служит двум целям одновременно. Работа, которая переполнила бы одно окно контекста, выполняется во множестве меньших контекстов. И добавляется настоящий слой проверки: субагент, ревьюящий вывод другого агента, проверяет работу, которую не сам создал, а это структурно надёжнее, чем когда агент сам же оценивает то, что только что написал.
Для параллельной работы в частности: git worktrees позволяют нескольким сессиям работать с разными ветками или директориями одновременно, не давая незавершённым изменениям одной сессии мешать другой. Это и есть механическая инфраструктура, лежащая в основе множества параллельных циклов, о которых Черни говорит как о личном подходе: не один агент работает быстрее, а много агентов одновременно работают над действительно независимыми кусками работы.
Решение про grep: кейс-стади «простота вместо хитроумности»
Одно конкретное, хорошо задокументированное техническое решение команды Черни иллюстрирует более широкую философию, которую стоит впитать. Claude Code отказался от векторного поиска и эмбеддингов для поиска по кодовой базе в пользу обычных grep и glob. Его собственные слова о результате: «обошло всё. С большим отрывом».
Урок применим не только к этому конкретному решению. Более сложно звучащее решение — семантический векторный поиск — автоматически не лучше более простого — grep — если простое на самом деле хорошо подходит к задаче. В кодовых базах есть точный синтаксис, точные имена функций, точные пути импортов — то, в чём grep силён и что нечёткое семантическое сопоставление может подорвать, выдавая правдоподобные, но неверные результаты.
Практический вывод для настройки собственных рабочих процессов: не выбирайте по умолчанию более сложно звучащий инструмент или архитектуру из предположения, что сложность означает возможности. Сначала протестируйте простой вариант на вашем реальном сценарии. Часто он побеждает. А даже если нет, вы как минимум подтвердили, что более сложный подход заслужил своё место, а не просто предположили это.
Никогда не позволяйте агенту оценивать собственную работу
Отдельный подтверждённый принцип из собственной практики Anthropic по инженерии обвязки, напрямую применимый к тому, как стоит структурировать любой шаг проверки в ваших рабочих процессах Claude Code: генерация и оценка должны происходить в реально раздельных ролях, потому что модель, проверяющая собственный вывод сразу после его создания, склонна завышать оценку, даже когда человек-ревьюер мгновенно заметил бы изъян.
На практике это означает: агент, который пишет код, не должен быть тем же проходом, который решает, достаточно ли код хорош для релиза. Отдельный шаг оценки — в идеале с доступом к тому, чего у генерировавшего агента не было:
