Аналіз вихідного коду Claude Code: чому він кращий за інші інструменти програмування зі штучним інтелектом?

Оригінальна назва: "Розуміння вихідного коду Claude Code від Anthropic в одній статті: чому він просто кращий за інші?"

Оригінальний автор: Yuker, дослідник ШІ

31 березня 2026 року дослідник безпеки Chaofan Shou виявив, що у релізі пакета Claude Code від Anthropic для npm не було видалено файл карти вихідного коду (source map).

Це означає, що повний вихідний код Claude Code на TypeScript — 512 000 рядків, 1903 файли — був відкритий у загальнодоступному інтернеті.

Звісно, я не міг прочитати такий обсяг коду за кілька годин, тому підійшов до цього вихідного коду з трьома питаннями:

1. У чому фундаментальна різниця між Claude Code та іншими інструментами програмування зі ШІ?

2. Чому процес написання коду в ньому «відчувається» кращим за інші?

3. Що саме приховано у 510 000 рядках коду?

Після прочитання моя перша реакція була такою: це не просто помічник для програмування зі ШІ; це операційна система.

I. Почнемо з історії: якби ви наймали віддаленого програміста

Уявіть, що ви найняли віддаленого програміста і надали йому віддалений доступ до свого комп'ютера.

Як би ви це контролювали?

Якби ви були Cursor: ви б посадили його поруч, і кожного разу, коли йому потрібно ввести команду, ви б дивилися на екран і натискали «дозволити». Це просто, але ви повинні постійно стежити за ним.

Якби ви були GitHub Copilot Agent: ви б надали йому абсолютно нову віртуальну машину для роботи. Після завершення він надсилає код, ви перевіряєте його, а потім об'єднуєте. Це безпечно, але він не бачить ваше локальне середовище.

Якби ви були Claude Code:

Ви дозволили б йому використовувати ваш комп'ютер безпосередньо, але оснастили б його надзвичайно складною системою безпеки. Що він може робити, чого не може, які дії потребують вашого схвалення, які він може виконувати самостійно, і навіть якщо він захоче використати rm -rf, це має пройти 9 рівнів перевірки перед виконанням.

Ось три абсолютно різні філософії безпеки:

Чому DID Anthropic обрали найскладніший шлях?

Тому що тільки так ШІ може працювати з вашим терміналом, середовищем та конфігурацією — це і означає «справжня допомога в програмуванні», замість «написання коду в стерильних умовах з подальшим копіюванням».

Але яка ціна? Вони написали для цього 510 000 рядків коду.

II. Ваше сприйняття Claude Code проти реального Claude Code

Більшість людей вважають, що інструменти програмування зі ШІ працюють так:

Введення користувача → Виклик LLM API → Отримання результату → Відображення користувачу

Насправді Claude Code працює так:

Введення користувача
→ Динамічне збирання 7 рівнів системних промптів
→ Впровадження стану Git, конвенцій проєкту, історичної пам'яті
→ 42 інструменти, кожен з інструкцією
→ LLM вирішує, який інструмент використати
→ 9 рівнів перевірки безпеки (парсинг AST, класифікатори ML, перевірки в «пісочниці»...)
→ Вирішення конфліктів дозволів (локальна клавіатура/IDE/хук/ШІ-класифікатор працюють одночасно)
→ 200 мс затримка для запобігання втомі
→ Виконання інструменту
→ Повернення результатів у потоковому режимі
→ Чи наближається контекст до ліміту? → Триетапне стиснення (мікростиснення → автостиснення → повне стиснення)
→ Потрібен паралелізм? → Генерація рою субагентів
→ Цикл до завершення завдання

Я вірю, що всім дуже цікаво дізнатися про це, але не хвилюйтеся, давайте розберемо все по черзі.

III. Перший секрет: промпти не пишуться, вони «збираються»

Відкрийте src/constants/prompts.ts, і ви побачите цю функцію:

Помітили SYSTEM_PROMPT_DYNAMIC_BOUNDARY?

Це роздільник кешу. Вміст над роздільником є статичним і може кешуватися Claude API для економії витрат на токени. Вміст під роздільником є динамічним — ваша поточна гілка Git, конфігурація проєкту CLAUDE.md, ваші попередні вподобання... кожна взаємодія унікальна.

Що це означає?

Anthropic ставиться до підказок як до виводу компілятора для оптимізації. Статична частина — це «скомпільований бінарний файл», а динамічна частина — це «параметри середовища виконання». Переваги цього підходу:

1. Економія коштів: статична частина кешується, уникаючи зайвих нарахувань

2. Швидкість: потрапляння в кеш дозволяє пропускати обробку цих токенів

3. Гнучкість: динамічна частина дозволяє кожній взаємодії враховувати поточне середовище

Кожен інструмент має свою «інструкцію користувача»

Ще більш вражаючим є те, що кожна директорія інструменту містить файл prompt.ts — це інструкція користувача, спеціально адаптована для LLM.

Подивіться на BashTool (src/tools/BashTool/prompt.ts, близько 370 рядків):

Це не документ для людей, це кодекс поведінки для ШІ. Кожного разу, коли запускається Claude Code, ці правила впроваджуються в системні промпти.

Ось чому Claude Code ніколи не виконує примусово git push --force самостійно, тоді як деякі інші інструменти можуть це робити — справа не в тому, що модель розумніша, а в тому, що правила вже чітко прописані в підказках.

Крім того, внутрішня версія Anthropic відрізняється від тієї, яку використовуєте ви

Код має численні гілки, такі як ця:

ant відноситься до внутрішніх співробітників Anthropic. Їхня версія має детальніші вказівки щодо стилю коду ("Не пишіть коментарі, якщо причина не є очевидною"), агресивнішу стратегію виводу ("Письмо перевернутою пірамідою") та деякі експериментальні функції, що все ще проходять A/B тестування (Агент верифікації, Агент дослідження та планування).

Це ілюструє, що Anthropic є найбільшим користувачем Claude Code. Вони використовують власний продукт для розробки власного продукту.

IV. Другий секрет: 42 інструменти, але ви бачили лише верхівку айсберга

Відкрийте src/tools.ts, і ви побачите реєстр інструментів:

42 інструменти, але більшість із них ви ніколи не бачили безпосередньо. Це тому, що багато інструментів завантажуються ліниво — вони впроваджуються за запитом через ToolSearchTool лише тоді, коли вони потрібні LLM.

Навіщо це зроблено?

Тому що для кожного додаткового інструменту системний промпт потребує додаткового опису, а токени коштують грошей. Якщо ви просто хочете, щоб Claude Code допоміг вам змінити один рядок коду, йому не потрібно завантажувати «Планувальник завдань Cron» та «Менеджер командної співпраці».

Існує ще розумніший дизайн:

Встановіть CLAUDE_CODE_SIMPLE=true, і в Claude Code залишиться лише три інструменти: Bash, Читання файлу, Зміна файлу. Це «чорний хід» для мінімалістів.

Усі інструменти виходять з однієї фабрики

Зверніть увагу на ці значення за замовчуванням: isConcurrencySafe за замовчуванням false, isReadOnly за замовчуванням false.

Це називається дизайном «відмова в закритому стані» — якщо автор інструменту забуває оголосити атрибути безпеки, система припускає, що він «небезпечний і доступний для запису». Краще бути надмірно обережним, ніж пропустити хоча б один ризик.

Залізний закон «читай перед записом»

FileEditTool перевірить, чи ви вже читали цей файл за допомогою FileReadTool. Якщо ні, він видасть помилку і не дозволить модифікацію.

Ось чому Claude Code не буде «магічно писати фрагмент коду для перезапису вашого файлу», як деякі інші інструменти — він зобов'язаний спочатку зрозуміти, а потім змінювати.

V. Третій секрет: система пам'яті — чому він може «пам'ятати вас»

Кожен, хто використовував Claude Code, має відчуття: він справді знає вас.

Ви кажете йому «не імітуй базу даних у тестах», і він не буде цього робити в наступній взаємодії. Ви кажете «я бекенд-інженер, новачок у React», і він пояснюватиме фронтенд-код, використовуючи бекенд-аналогії.

За цим стоїть повна система пам'яті.

Використання ШІ для отримання спогадів

Claude Code використовує інший ШІ (Claude Sonnet), щоб визначити, «які спогади релевантні поточній розмові».

Не пошук за ключовими словами, не векторний пошук — він дозволяє невеликій моделі швидко сканувати всі назви та описи файлів пам'яті, вибираючи до 5 найбільш релевантних, а потім впроваджуючи їх повний вміст у контекст поточної розмови.

Стратегія полягає в «точності над повнотою» — краще пропустити потенційно корисний спогад, ніж впровадити нерелевантний, що забруднює контекст.

Режим KAIROS: нічні «сновидіння»

Це найбільш науково-фантастична частина для мене.

У коді є прапорець функції під назвою KAIROS. У цьому режимі спогади з довгих розмов зберігаються не в структурованих файлах, а в записах, схожих на логи з додаванням дати. Потім є навичка /dream, яка запускається в «нічний час» (низька активність), дистилюючи ці сирі логи в структуровані тематичні файли.

ШІ організовує спогади під час «сну». Це вже не інженерія; це біоніка.

VI. П'ятий секрет: це не агент, це група

Коли ви змушуєте Claude Code виконати складне завдання, він може тихо зробити ось що:

Він генерує субагента.

І субагент має суворе впровадження «самосвідомості», щоб запобігти рекурсивній генерації нових субагентів:

Цей фрагмент коду говорить: «Ти працівник, а не менеджер. Не думай про найм нових людей, виконуй роботу сам».

Шаблон координатора: шаблон менеджера

У шаблоні координатора Claude Code стає чистим оркестратором завдань, не виконуючи роботу сам, а лише делегуючи її:

Основні принципи, записані в коментарях до коду:

«Паралелізм — ваша суперсила» для дослідницьких завдань лише для читання: запускайте паралельно. Для завдань запису файлів: запускайте послідовно для кожної групи файлів (уникаючи конфліктів).

Оптимізація кешу промптів до крайності

Щоб максимізувати швидкість потрапляння в кеш субагентів, усі результати утиліт розгалужених субагентів використовують однаковий текст-заповнювач:

«Fork розпочато — обробка у фоновому режимі»

Чому? Тому що кеш промптів Claude API базується на префіксному зіставленні на рівні байтів. Якщо префіксні байти 10 субагентів ідентичні, то лише перший потребує «холодного старту», інші 9 безпосередньо потрапляють у кеш.

Це оптимізація, яка економить кілька центів за виклик, але в масштабі це може заощадити значну суму коштів.

VII. Шостий секрет: тришарове стиснення для забезпечення діалогів, що «ніколи не перевищують ліміти»

Усі LLM мають обмеження вікна контексту. Чим довша розмова, тим більше історичних повідомлень, і врешті-решт ліміт буде перевищено.

Claude Code розробив для цього тришарове стиснення:

Рівень 1: Мікростиснення — мінімальні витрати

Мікростиснення стосується лише результатів викликів старих інструментів — замінюючи «Вміст 500-рядкового файлу, прочитаного 10 хвилин тому» на [Вміст результату старого інструменту очищено].

Промпти та потік діалогу повністю зберігаються.

Рівень 2: Автостиснення — проактивне зменшення

Коли споживання токенів наближається до 87% вікна контексту (розмір вікна - 13 000 буфер), запускається автоматично. Існує запобіжник: зупинити спроби після 3 послідовних невдач стиснення, щоб уникнути циклу.

Рівень 3: Повне стиснення — ШІ-узагальнення

ШІ генерує резюме всієї розмови, а потім замінює всі історичні повідомлення цим резюме. Під час генерації резюме діє суворе правило:

Чому так суворо? Тому що якби ШІ робив додаткові виклики інструментів під час процесу узагальнення, це призвело б до більшого споживання токенів, що було б контрпродуктивно. Цей промпт по суті говорить: «Твоє завдання — узагальнити, більше нічого не роби».

Бюджет стиснутих токенів:

· Відновлення файлів: 50 000 токенів

· Ліміт на файл: 5 000 токенів

· Вміст навичок: 25 000 токенів

Ці цифри не випадкові — вони представляють точку балансу між «збереженням достатнього контексту для продовження роботи» та «звільненням достатнього місця для отримання нових повідомлень».

VIII. Чого я навчився після прочитання цього вихідного коду

90% роботи ШІ-агента знаходиться поза межами «ШІ»

У 510 000 рядках коду частка, що безпосередньо викликає LLM API, ймовірно, становить менше 5%. А що з рештою 95%?

· Перевірки безпеки (18 файлів лише для одного BashTool)

· Система дозволів (квадратичне рішення дозволити/заборонити/запитати/пропустити)

· Управління контекстом (тришарове стиснення + ШІ-отримання пам'яті)

· Відновлення після помилок (запобіжник, експоненціальна затримка, збереження транскриптів)

· Координація мультиагентів (оркестрація рою + поштове спілкування)

· UI-взаємодія (140 React-компонентів + міст до IDE)

· Оптимізація продуктивності (стабільність кешу промптів + паралельне попереднє завантаження при запуску)

Якщо ви створюєте продукт ШІ-агента, це реальні проблеми, які вам потрібно вирішити. Справа не в тому, наскільки розумна ваша модель; справа в тому, наскільки надійні ваші «риштування».

Хороший промпт-інжиніринг — це системна інженерія

Справа не лише в створенні гарного промпту. Промпти Claude Code включають:

· 7-рівневе динамічне збирання

· Кожен інструмент має окрему інструкцію користувача

· Межі кешу точно окреслені

· Внутрішні та зовнішні версії мають різні набори інструкцій

· Порядок інструментів фіксований для підтримки стабільності кешу

Це інженерне управління промптами, а не ремісництво.

Проєктування з урахуванням відмов

Кожна зовнішня залежність має відповідну політику відмови:

Anthropic ставиться до Claude Code як до операційної системи

42 інструменти = Системні виклики; Система дозволів = Управління дозволами користувачів; Система навичок = App Store; Протокол MCP = Драйвер пристрою; Рій агентів = Управління процесами; Стиснення контексту = Управління пам'яттю; Збереження транскриптів = Файлова система

Це не «чат-бот плюс кілька інструментів»; це операційна система з LLM в основі.

Резюме

510 000 рядків коду. 1903 файли. 18 файлів безпеки лише для одного інструменту Bash.

9 рівнів перевірки лише для того, щоб безпечно дозволити ШІ допомогти вам ввести команду.

Це відповідь Anthropic: Щоб зробити ШІ справді корисним, ви не можете замкнути його в клітці або дозволити йому діяти безконтрольно. Ви повинні побудувати навколо нього повну систему довіри.

І ціна цієї системи довіри — 510 000 рядків коду.

Оригінальний пост