31 марта 2026 года наружу буквально вывалились исходники Claude Code (через sourcemap в npm‑пакете). История уже сама по себе комичная: продукт, который помогает писать код и в теории должен быть особенно аккуратен с публикацией артефактов, случайно публикует не просто кусок дебажной информации, а почти анатомический атлас самого себя.
Но меня в этой истории интересует не столько сам факт утечки, сколько более приземлённый вопрос: что там внутри? Если убрать обычное для таких случаев «вау, утекло», остаётся более интересная интонация: ну‑ка, посмотрим, что тут у нас (или «там у них»?) и нормально ли там написан код.
Да, написано с головой. Даже с душой. Но и с очень характерными симптомами продукта, который из «удобного CLI для общения с моделью» давно мутировал в маленькую операционную систему для одного терминала.
Сразу неприятная правда: это не аккуратный git checkout
Первое, что бросается в глаза при прогулке по дереву без романтики: перед нами не идеальный репозиторий разработчика. Тут нет привычных package.json, tsconfig.json и прочей обвязки, зато есть характерная смесь живого TypeScript‑кода, следов сборки и трансформаций.
Более того, часть импортов в коде указывает на файлы, которых в этой копии просто нет: assistant/index.ts, assistant/gate.ts, proactive/index.js, daemon/main.js, environment-runner/main.js, а также несколько KAIROS‑специфичных инструментов. Это важно проговорить именно в контексте способа утечки: наружу вышел не git‑репозиторий, а огромный source snapshot, восстановленный из sourcemap и связанных артефактов. Поэтому перед нами не стерильный внутренний checkout «как у разработчика на ноутбуке», а очень крупный, но местами неполный слепок клиентского кода.
Например, screens/REPL.tsx начинается с react/compiler-runtime: это уже не «чистый авторский TSX», а результат React Compiler‑трансформаций. При этом main.tsx выглядит гораздо ближе к исходному коду и начинается с ручных оптимизаций старта: ранние profileCheckpoint, префетч keychain, параллельный MDM‑read и так далее.
Это важная оговорка для всей статьи. Мы смотрим не на музейный экспонат «исходники как они лежали у команды», а на очень крупную и местами рваную выгрузку внутренностей клиента. Поэтому самые громкие выводы лучше делать осторожно: не «вот весь секретный продукт», а «вот очень большой и очень говорящий срез того, как этот клиент реально устроен».
Первое впечатление: это не «маленький CLI»
Снаружи Claude Code продаётся как CLI для разработчика. Внутри это ощущается скорее как фреймворк для терминальной среды, к которому случайно приделали команду claude.
entrypoints/cli.tsx сразу даёт понять, что здесь не один сценарий запуска, а целый вокзал маршрутов:
облегчённая ветка запуска для
--version;отдельный путь для вывода system prompt;
отдельные режимы для MCP‑серверов;
daemon;remote-controlи bridge‑режим;фоновые сессии
ps/logs/attach/kill;environment-runner;self-hosted-runner;работа через
tmuxиworktree.
То есть это не «запускаем чат в терминале». Это многорежимный рантайм, у которого CLI всего лишь фасад.
Здесь появляется первая развилка между симпатией и скепсисом.
Симпатия: команда явно понимает цену старта и ленивой загрузки. В entrypoints/cli.tsx почти всё тяжёлое тянется динамическими импортами. Комментарии там вполне прямолинейные: All imports are dynamic to minimize module evaluation for fast paths («все импорты динамические, чтобы минимизировать загрузку модулей на коротких и простых сценариях запуска»), Fast-path for --version has zero imports beyond this file («ветка для --version вообще не тянет ничего за пределами этого файла»), workers are lean («воркеры должны оставаться лёгкими»).
Пользовательская польза от такого подхода очень простая: если вы попросили программу сделать что‑то элементарное, она не должна ради этого разворачивать полсистемы. --version, служебные команды, фоновые воркеры и похожие режимы должны запускаться быстро, потреблять меньше памяти и реже ломаться из‑за побочных зависимостей. Это не косметика, а нормальная инженерия для большого CLI.
Скепсис: когда продукту приходится знать про daemon, bridge, remote, self‑hosted runner, tmux, worktree, MCP и UI одновременно, он начинает быть похожим не на CLI, а на аэропорт, где на схеме уже страшно, а жить ещё можно только потому, что везде развешаны указатели.
Главный герой этой пьесы: огромный main.tsx
Любая такая система рано или поздно выдаёт свою точку гравитационного коллапса. У Claude Code это main.tsx.
Сам по себе большой entrypoint не преступление. Но когда файл становится центром, через который проходят:
инициализация;
выбор режима;
system prompt;
tool pool;
feature flags;
remote‑сессии;
KAIROS/Proactive;
structured output;
UI‑пуск;
восстановление сессий;
это уже не «точка входа», а центральная нервная система.
У такого подхода есть плюс: все ключевые продуктовые развилки лежат в одном месте, архитектуру удобно читать. Но есть и минус: файл превращается в склад компромиссов. Поэтому в коде повсюду мелькают конструкции в стиле «сначала включим proactive mode до getTools(), потому что иначе SleepTool.isEnabled() не сработает». Это не баг, а следствие масштаба.
Хороший инженерный запах здесь смешан со следами очень долгой эволюции. В начале проекта кто‑то явно хотел написать аккуратный CLI. Потом CLI начал обрастать режимами, потом режимы начали конфликтовать, потом их стали развешивать на feature‑флаги и ранние проверки. Результат лежит перед нами.
Технически это React‑приложение, которое притворяется терминалом
Ещё одна вещь, которую полезно проговорить прямо: Claude Code внутри не «суровый консольный бинарник из мира curses». Это React‑приложение на Ink и сопутствующей инфраструктуре, только живёт оно не в браузере, а в терминале.
Из‑за этого screens/REPL.tsx выглядит не как «экран чата», а как полноценный фронтенд‑комбайн:
уведомления;
модалки;
IDE‑интеграция;
MCP‑соединения;
плагины;
загрузка навыков;
teammate‑режим;
remote‑callout;
dialog priority;
transcript mode;
floating UI;
и, конечно, Buddy.
Это одновременно впечатляет и отлично объясняет, почему у продукта такой характер. Claude Code не просто «посылает промпт и печатает ответ». Он постоянно синхронизирует состояние, фильтрует набор инструментов, подмешивает плагины и MCP‑клиенты, решает, какой режим сейчас активен, и рендерит всё это в один терминальный интерфейс.
Иными словами: это фронтенд. Просто фронтенд, которому тесно в браузере, и он переехал в терминал вместе со своими травмами.
Перед нами не один агент, а диспетчерская
Самый важный архитектурный вывод после прогулки по коду такой: Claude Code построен не вокруг «главной модели», а вокруг оркестрации.
AgentTool в tools/AgentTool/AgentTool.tsx — не декоративная добавка, а один из главных механизмов всей системы. Агент можно:
запустить синхронно;
отправить в background;
изолировать в отдельный
worktree;в некоторых сборках увести в remote;
сделать teammate внутри команды;
ограничить набором доступных агентов;
посадить на другой permission mode.
И это уже не уровень «у нас есть субагенты». Это уровень «у нас есть инфраструктура жизненного цикла субагентов».
Особенно хороши детали:
для async‑агентов есть отдельная регистрация, прогресс и уведомления;
worker получает собственный tool pool, а не просто наследует всё от родителя;
worktreeизоляция создаётся прямо как часть маршрута исполнения;fork‑path отдельно заботится о кэш‑идентичности system prompt и набора tools.
То есть здесь видно взрослую инженерную мысль: не просто «давайте позовём вторую модель», а «давайте сделаем так, чтобы эта вторая сущность не сломала контекст, права, cwd и жизненный цикл».
Это одна из самых сильных частей всей системы.
Потому что очень многие AI‑инструменты красиво показывают слово «agents», а внутри там один Promise.all и молитва. Здесь не так. Здесь агентность довели до состояния инфраструктуры.
При этом они прекрасно понимают, что агентность легко превращается в балаган
Показательный пример — встроенный Explore‑агент в tools/AgentTool/built-in/exploreAgent.ts.
Это не просто роль, а почти педагогически выписанный характер:
только чтение;
никаких write/edit/delete;
никаких redirect и heredoc;
максимум поиска и анализа;
по возможности распараллеливать grep/read‑вызовы.
Это хороший момент для понимания всей философии Claude Code. Команда явно не доверяет даже собственным же агентам настолько, чтобы оставлять поведение «ну он сам разберётся». Каждый специализированный режим стараются ограничить не только технически, но и риторически, прямо через системную инструкцию.
То есть продукт строится на любопытной паре тезисов:
Мы очень хотим дать модели больше самостоятельности.
Мы прекрасно понимаем, что без намордника она моментально начнёт вести себя как стажёр на третий день после дедлайна.
Это, кстати, разумный взгляд на современные агентные системы.
Инструменты здесь оркестрируются всерьёз, а не для демо
Отдельно мне понравился слой исполнения инструментов.
В services/tools/toolOrchestration.ts вызовы делятся на concurrency‑safe и всё остальное. То есть система не просто умеет запускать несколько инструментов подряд, она осознанно группирует read‑only и безопасные вызовы в параллельные пачки, а рискованные гоняет сериализованно.
Дальше идёт services/tools/StreamingToolExecutor.ts, и там видно, что люди уже натерпелись реальных проблем:
есть отдельная логика для отмены соседних tool call, если один из параллельных упал;
есть различие между
user_interrupted,sibling_errorиstreaming_fallback;есть аккуратная буферизация результатов, чтобы отдавать их в правильном порядке;
отдельно учитывается поведение инструментов при interrupt.
Это то место, где «прототип для AI» заканчивается и начинается продукт. Потому что прототип умеет делать tool call. Продукт умеет переживать, что tool call застрянет, будет прерван, конфликтнёт с соседним и сломает UI.
Паранойя в Bash‑слое заслуживает отдельной премии
Если смотреть только маркетингово, Claude Code — это «попроси модель выполнить команду». Если смотреть в код, это «мы потратили чудовищное количество сил на то, чтобы команда не стала способом самоубийства».
Файлы tools/BashTool/bashPermissions.ts и tools/BashTool/bashSecurity.ts выглядят как коллективный дневник команды, которую уже один раз очень больно укусил shell.
Там блокируются и учитываются вещи, о которых половина разработчиков вспоминает раз в год:
command substitution;
process substitution;
heredoc‑краевые случаи;
zsh equals expansion;
zmodload,ztcp,zptyи прочие радости;обфусцированные флаги;
опасные префиксы через
env,sudo,nice,timeout;странные формы whitespace и экранирования.
Это выглядит почти маниакально, но в хорошем смысле. Потому что именно здесь особенно хорошо видно: Claude Code писали не люди, которые обсуждают «агентов будущего» на слайдах, а люди, которые уже насмотрелись на реальное поведение LLM в shell и решили больше не удивляться.
С инженерной точки зрения это один из самых зрелых слоёв проекта.
С эстетической точки зрения — это напоминание, что вся современная AI‑магия очень быстро упирается в банальное: «а теперь не дай модели случайно или не случайно пробить себе дыру через bash».
Дальше начинается самое человеческое: Buddy, Dream и прочая психотерапия для CLI
Самые обсуждаемые фрагменты этой утечки — не orchestration и не permissions, а вещи, которые делают продукт неожиданно человечным.
Buddy
Каталог buddy/ выглядит так, будто кто‑то в середине корпоративного CLI внезапно разрешил дизайнеру и геймдизайнеру провести свой праздник жизни.
Buddy — это терминальный компаньон с ASCII‑спрайтами, пузырями речи, анимацией, сердечками после «погладить» и отдельным тизерным окном на 1–7 апреля 2026 года. В buddy/useBuddyNotification.tsx это всё ещё и оформлено с явным расчётом на пояса времени и «растянутый» вирусный эффект. А buddy/CompanionSprite.tsx содержит нормальную маленькую систему рендеринга персонажа: тайминги, fade, narrow‑mode, reserved columns, idle sequence.
Отдельно смешно, что вокруг Buddy уже успела вырасти собственная мифология. README в зеркале рисует один набор существ, а реальный buddy/types.ts гораздо прозаичнее и веселее: duck, goose, blob, cat, capybara, robot, mushroom, chonk. То есть даже утёкший код моментально оброс вторичным фанфиком, и это хороший повод читать именно файлы, а не только их пересказы.
Самая смешная деталь не в спрайте, а в промпте buddy/prompt.ts: модели прямо объясняют, что рядом сидит маленькое существо, которое иногда отвечает в отдельном пузыре, и самой модели в этот момент лучше не лезть с лишней болтовнёй.
Это поразительно точная иллюстрация того, во что превращаются современные AI‑продукты. С одной стороны, перед нами серьёзный инструмент разработки. С другой — терминальный питомец, которому нужно место в layout, реплики и режим «не мешайся, когда говорит зверёк».
Это не выглядит нелепо. Это выглядит как закономерная стадия эволюции продукта, который хочет жить рядом с человеком дольше пяти минут.
Dream
Если Buddy — это маркетинговая человечность, то autoDream — уже архитектурная поэзия.
В services/autoDream/autoDream.ts живёт механизм фоновой консолидации памяти. Не «сохранить заметку», а именно dream: отдельный forked subagent, который запускается по трём воротам:
прошли часы с последней консолидации;
накопилось достаточно новых сессий;
удалось взять lock.
А в services/autoDream/consolidationPrompt.ts это всё оформлено как ритуал на раз-два-три-четыре:
Осмотреться.
Собрать свежий сигнал.
Сконсолидировать память.
Подчистить индекс и противоречия.
Самое прекрасное здесь даже не название, а дисциплина. «Сон» не дают запускать слишком часто. Ему ограничивают инструменты. Ему отдельно объясняют, что транскрипты большие и читать их целиком не надо. Ему велят переводить относительные даты в абсолютные. Это очень хороший инженерный дизайн, замаскированный под художественный термин.
То есть да, Claude Code буквально «видит сны». Но с хорошим lock‑файлом, дедупликацией и read‑only Bash. Это важное уточнение.
Undercover Mode: самая смешная и самая показательная часть
Если бы нужно было выбрать один фрагмент кода, который лучше всего передаёт дух всей утечки, я бы выбрал utils/undercover.ts.
Там живёт режим, который нужен для работы сотрудников Anthropic в публичных репозиториях. И написан он не как шутка, а как очень серьёзная инструкция:
не палить внутренние кодовые имена моделей;
не светить внутренние project names;
не писать «Generated with Claude Code»;
не добавлять никакое AI‑attribution;
если не уверены, что репозиторий внутренний, работаем undercover.
То есть продукт буквально умеет делать вид, что он не продукт.
Можно сколько угодно спорить о корпоративной этике, но как инженерный артефакт это бесценно. Потому что мгновенно показывает два факта:
Claude Code используется в реальной работе с публичными репозиториями.
Команда прекрасно осознаёт репутационные и информационные риски того, что модель скажет лишнее.
Вся эта система — отличный холодный душ для тех, кто думает про AI‑кодинг как про «просто интерфейс к модели». Это ещё и контроль утечек, атрибуции, prompt‑режимов, привилегий и даже риторики commit message.
KAIROS, PROACTIVE и привкус отсутствующего куска пазла
По коду отлично видно, что в продукте есть или планировался слой «постоянно живущего» ассистента: KAIROS, PROACTIVE, Brief‑режим, отдельные инструменты вроде отправки файлов пользователю и push‑нотификаций.
Но здесь есть важная трезвая оговорка: в этой выгрузке это читается неравномерно.
main.tsx и screens/REPL.tsx постоянно ссылаются на assistant/index.js, assistant/gate.js и другие KAIROS‑сущности. При этом сам каталог assistant/ в этой копии почти пуст: фактически там лежит только assistant/sessionHistory.ts. То же самое относится к ряду ожидаемых соседних кусков вроде proactive/index.js и инструментов отправки файлов/нотификаций пользователю: код явно знает о них, но в слепке, восстановленном из sourcemap, эти модули отсутствуют.
Это очень хороший антидот против конспирологии. Исходников много, очень много, но не всё дошло одинаково полно. Где‑то мы видим полноценный слой. Где‑то только интерфейсы, флаги, вызовы и контуры.
Именно поэтому про KAIROS правильнее говорить так: код уверенно подтверждает существование этой линии развития продукта, но не даёт нам весь внутренний модуль целиком.
Плагины: да, система есть; нет, в этом репо она не раскрыта полностью
У пользователя, который посмотрит на это дерево впервые, может возникнуть естественная реакция: «Подождите, а где, собственно, все плагины?»
С одной стороны, плагинная инфраструктура в коде очень серьёзная:
hooks/useManagePlugins.tsгрузит plugin commands, agents, hooks, MCP и LSP;services/plugins/PluginInstallationManager.tsумеет фоновые установки маркетплейсов и авто‑refresh;services/mcp/MCPConnectionManager.tsxживёт как нормальный connection layer;skills/bundledSkills.tsумеет лениво распаковывать reference‑файлы для встроенных навыков.
С другой стороны, конкретно в этой копии репозитория картина очень скромная:
в
plugins/лежат буквально две заготовки;plugins/bundled/index.tsпрямо говорит, что встроенные плагины пока не зарегистрированы;реальная «начинка» во многом живёт не в
plugins/, а в bundled skills, MCP‑интеграциях и внешних маркетплейсах.
Формально плагинная архитектура огромная. Практически же в этой выгрузке она видна скорее как каркас и загрузчик, а не как коллекция готовых расширений. Это ещё одна причина не повторять без оговорок формулу «утёк весь Claude Code»: утёк очень большой пласт клиентского кода, но из‑за способа утечки через sourcemap не все прикладные слои представлены одинаково плотно.
Это типично для современных платформ. Самое сложное там давно не «написать ещё один плагин», а построить систему загрузки, доверия, политики, hot‑reload, ошибок, MCP‑подключения и обновления маркетплейса. Именно это в коде и видно.
Самая «вкусная» археология: hidden modes и фичефлаги
Если убрать эмоции и просто посчитать feature(...), выясняется забавное: самый частый персонаж в коде — не Claude, не Tool и даже не Agent, а флаг.
В репозитории особенно часто всплывают KAIROS, TRANSCRIPT_CLASSIFIER, TEAMMEM, VOICE_MODE, BASH_CLASSIFIER, KAIROS_BRIEF, PROACTIVE, COORDINATOR_MODE, BRIDGE_MODE, BUDDY, CHICAGO_MCP, ULTRAPLAN, BG_SESSIONS, AGENT_TRIGGERS, WEB_BROWSER_TOOL, TERMINAL_PANEL, REVIEW_ARTIFACT, CCR_MIRROR и ещё длинный хвост более редких сущностей.
Это очень важный момент для чтения всего дерева. Claude Code живёт не как единый монолит, а как набор режимов, которые то собираются, то вырезаются, то догейтваются рантаймом через GrowthBook‑конфиги вроде tengu_ultraplan_model, tengu_remote_backend, tengu_onyx_plover, tengu_ccr_bridge и десятков других.
Здесь нужна дисциплина формулировки. Наличие флага не означает, что перед нами shipped‑функция для всех пользователей. Корректнее говорить так: код подтверждает существование реализованной или частично реализованной линии продукта, скрытой за compile‑time и runtime gates.
Вот какие «тайники» здесь особенно хороши.
KAIROS и PROACTIVE: Claude, который не ждёт, пока его позовут
Это самый жирный скрытый пласт. В main.tsx KAIROS и PROACTIVE встречаются постоянно: ранние require('./assistant/index.js'), специальные ветки brief mode, отдельная активация assistant mode, отдельные каналы, особый UX‑поток и даже подготовка под teammate context.
Снаружи это читается так: внутри продукта давно есть или очень серьёзно прорабатывался режим «постоянно живущего» помощника, который не просто отвечает на реплики, а существует рядом с пользователем. В этом же направлении лежат KAIROS_BRIEF, KAIROS_CHANNELS, KAIROS_PUSH_NOTIFICATION, KAIROS_GITHUB_WEBHOOKS.
Правильная оговорка здесь одна: в этой выгрузке KAIROS виден скорее по каркасу, вызовам и гейтам, чем по полному модулю. То есть линия продукта бесспорно есть, но целиком внутренний assistant‑слой перед нами не раскрыт.
ULTRAPLAN: режим, в котором Claude уходит думать отдельно от вас
ULTRAPLAN — один из самых красивых артефактов именно как продуктовая идея. В commands/ultraplan.tsx есть 30-минутный таймаут, работа с удалённой CCR‑сессией, браузерный approval loop, polling статуса и развилка «выполнять дальше удалённо или телепортировать план обратно локально».
Это уже не «покажи пользователю chain‑of‑thought», а отдельный планировочный ритуал с удалённой инфраструктурой. И очень смешно, что рядом с этим есть ещё keyword trigger для ultraplan прямо в пользовательском вводе в utils/processUserInput/processUserInput.ts.
В коде реально просматривается режим «дай мне полчаса отдельно подумать и потом вернись с планом». Для статьи это подарок.
BUDDY: скрытый тамагочи, которого никто не просил, но все бы обсуждали
BUDDY встречается реже, чем KAIROS, но как культурный артефакт он мощнее половины enterprise‑фич. В buddy/CompanionSprite.tsx спрятан полноценный маленький UI‑движок для терминального зверька: idle sequence, fade‑out пузыря, narrow‑mode, резервация колонок в layout, сердечки после pet interaction. В buddy/prompt.ts модели отдельно объясняют, что рядом сидит существо со своей репликой и лучше ему не мешать.
Это хорошее напоминание, что серьёзные AI‑продукты неизбежно начинают обрастать не только «precision/recall», но и характером. А потом кто‑то пишет в production‑коде систему показа пузыря речи для ASCII‑питомца.
BRIDGE_MODE, CCR_MIRROR и remote‑control: терминал как тонкий клиент к удалённой среде
Если смотреть по entrypoints/cli.tsx, bridge/ и remote/, то становится видно, что у Claude Code есть не один «локальный» режим жизни. BRIDGE_MODE открывает remote‑control/bridge path, CCR_AUTO_CONNECT и CCR_MIRROR намекают на более тесную связь с Claude Code on the web и удалёнными контейнерами, а tengu_remote_backend в main.tsx дополнительно подсвечивает, что remote backend мыслится как отдельная операционная ось продукта.
Это тот случай, когда флаги рассказывают о стратегии продукта лучше презентации. Тут явно строится не просто CLI, а связка «локальный интерфейс + удалённая среда + мост между ними».
TEAMMEM, autoDream и память как отдельный продукт внутри продукта
Обычный AI‑клиент хранит историю. Claude Code на этом месте уже строит мемориальную бюрократию.
TEAMMEM размазан по claudemd, teamMemorySync и memory‑компонентам; autoDream живёт своей жизнью через tengu_onyx_plover; EXTRACT_MEMORIES и session memory накладываются сверху. В сумме это даёт удивительное ощущение: память здесь не «удобная опция», а отдельный продуктовый слой со своей синхронизацией, лимитами, watch‑логикой, защитой от секретов и фоновым уходом за собой.
Это один из лучших сюжетов для статьи: AI‑индустрия много говорит о «долговременной памяти», но редко показывает, сколько скучной инженерии стоит за этим в реальности.
CHICAGO_MCP, WEB_BROWSER_TOOL и прочие боковые ходы
Есть и менее громкие, но очень характерные режимы.
CHICAGO_MCP включает отдельный computer‑use MCP path в entrypoints/cli.tsx. WEB_BROWSER_TOOL влияет на то, как показывается Claude‑in‑Chrome hint в main.tsx. TERMINAL_PANEL, QUICK_SEARCH, HISTORY_PICKER, MESSAGE_ACTIONS, AUTO_THEME и WORKFLOW_SCRIPTS выглядят как уже не базовая функциональность, а постепенное превращение терминального клиента в полноценную оболочку со своим UX‑слоем.
Это очень в духе больших продуктов: сначала у тебя «ещё одна опция», потом «ещё один маленький режим», потом ты внезапно понимаешь, что строишь собственную настольную среду, только в тексте.
BG_SESSIONS, DAEMON, SELF_HOSTED_RUNNER, BYOC_ENVIRONMENT_RUNNER
Вот где особенно хорошо ломается наивная картинка «CLI = один процесс, один запрос, один ответ». В entrypoints/cli.tsx отдельно живут BG_SESSIONS, DAEMON, SELF_HOSTED_RUNNER, BYOC_ENVIRONMENT_RUNNER. То есть система заранее строится под длинноживущие процессы, фоновую жизнь, внешние окружения и сценарии, где локальная консоль уже не главный актор.
Это делает код тяжелее, но и честнее. Команда не притворяется, что продукт останется «маленьким terminal helper». Они уже пишут платформу.
И всё это вместе выглядит не как беспорядок, а как метод выживания
Из хорошего:
можно держать внутренние и внешние сборки рядом;
можно dogfood‑ить фичи на сотрудниках;
можно жёстко выкидывать куски кода через dead code elimination;
можно быстро катать экспериментальные режимы без того, чтобы ломать весь продукт;
можно вести параллельно несколько линий развития: CLI, remote, assistant, memory, plugins, MCP.
Из плохого:
архитектура начинает читаться не как один продукт, а как слоёный пирог решений;
некоторые инварианты становятся хрупкими, потому что порядок инициализации зависит ещё и от того, какой флаг сейчас включён;
постороннему читателю код временами напоминает археологию внутренних экспериментов и A/B‑тестов;
отдельные подсистемы существуют скорее как контур, чем как полностью раскрытый модуль, и это постоянно нужно оговаривать.
У такого продукта почти нет другого пути. Когда одновременно строишь CLI, агентную платформу, терминальный UI, память, remote‑контур и внутренний полигон для новых режимов, feature‑флаг перестаёт быть слабостью. Он становится способом не развалиться по дороге.
Так нормально ли это написано?
Мой ответ такой: да, в целом это написано сильно. Но сильно именно как большой живой продукт, а не как изящная учебная архитектура.
Что здесь правда хорошо:
видно реальное внимание к startup performance;
orchestration субагентов сделана серьёзно;
permission и Bash‑безопасность проработаны болезненно тщательно;
terminal UI не выглядит игрушкой;
memory, MCP, plugins и remote‑режимы связаны в одну систему, а не в россыпь демо‑модулей.
Что здесь явно болит:
слишком много центростремительности вокруг
main.tsx;feature‑флагов столько, что код местами начинает походить на карту политических союзов в поздней античности;
некоторые подсистемы читаются как «это уже почти отдельный продукт внутри продукта»;
сама выгрузка показывает, насколько много важного было вынесено в частично недостающие куски, маркетплейсы и внутренние сборки.
Главный вывод у меня не язвительный, а скорее уважительный.
Claude Code в этой утечке не выглядит «обёрткой над API». Он выглядит как тяжёлый, амбициозный, иногда перегруженный, но вполне серьёзный программный продукт. Со своими шрамами. Со своими перегибами. Со своим абсолютно корпоративным желанием одновременно быть и удобным, и безопасным, и расширяемым, и чуть‑чуть живым.
А ещё он выглядит как продукт, который очень хочет стать не просто CLI, а средой обитания для модели.
Buddy внизу экрана. Сны по ночам. Undercover в публичных репозиториях. Агентные команды. Remote‑сеансы. MCP. Плагины. Огромный REPL на React.
В какой‑то момент понимаешь, что смотришь уже не на «клиент для Claude», а на первую неловкую, но вполне рабочую попытку собрать персональную операционную систему для AI‑помощника.
Это и есть самая интересная часть всей истории.
