Творець Claude Code показав, як він використовує цей інструмент у своїх робочих процесах

Борис Черні, основний розробник і керівник проекту Claude Code в Anthropic, опублікував серію постів на X, в яких розкрив секрети роботи з цим популярним інструментом кодування. Галузеві оглядачі вже назвали цей тред «революційними оновленнями Черні», пише Venture Beat.

Найбільш вражаючим відкриттям стало те, що Борис не пише код лінійно. У традиційному «внутрішньому циклі» розробки програміст пише функцію, тестує її та переходить до наступної. Черні ж діє як командир флоту:

«Я запускаю 5 команд Claude паралельно у своєму терміналі. Я нумерую вкладки від 1 до 5 та використовую системні сповіщення, щоб знати, коли команді Claude потрібні дані».

https://code.claude.com/docs/en/terminal-config#iterm-2-system-notifications

Використовуючи системні сповіщення iTerm2, Черні ефективно керує п’ятьма одночасними робочими потоками. Поки один агент запускає набір тестів, інший рефакторує застарілий модуль, а третій пише документацію. Він також запускає «5-10 Claude на claude.ai» у своєму браузері, використовуючи команду «teleport» для передачі сеансів між веб-сторінками та локальним комп’ютером.

Отже, перелік дій у Claude Code від його творця:

«Я також запускаю 5-10 сесій Claude на http://claude.ai/code паралельно з моїми локальними сесіями Claude. Під час написання коду в терміналі я часто передаю локальні сесії до web-версії (використовуючи &) або вручну запускаю сесії в Chrome, а іноді я –teleportуюся туди-сюди. Я також запускаю кілька сесій з телефону (з програми Claude для iOS) щоранку і протягом дня та перевіряю їх пізніше».

Несподіваним кроком для індустрії, одержимої затримкою, Черні розповів, що він виключно використовує найважчу та найповільнішу модель Anthropic: Opus 4.5.

«Я використовую Opus 4.5 з урахуванням усіх факторів. Це найкраща модель кодування, яку я коли-небудь використовував, і хоча вона більша та повільніша за Sonnet, оскільки вам потрібно менше нею керувати, і вона краще використовує інструменти, зрештою вона майже завжди швидша, ніж використання меншої моделі.

Наша команда використовує http://CLAUDE.md як репозиторій Claude Code. Ми перевіряємо його в git, і вся команда робить свій внесок кілька разів на тиждень. Щоразу, коли ми бачимо, що Claude робить щось неправильно, ми додаємо це до http://CLAUDE.md, щоб Claude знав, що наступного разу цього не робити.
Інші команди підтримують свої власні http://CLAUDE.md. Завдання кожної команди — оновлювати їх.

Під час код-рев’ю я часто позначаю @.claude у PR-запитах моїх колег, щоб додати щось до http://CLAUDE.md як частину PR. Для цього ми використовуємо дію Claude Code Github (/ install-github-action). Це наша версія Compounding Engineering від @danshipper

Більшість сесій починаються в режимі «Планування» (двічі Shift+Tab). Якщо моєю метою є написання запиту на злиття (Pull Request), я використовую режим «Планування» та чергую з Claude, доки мені не сподобається його план. Звідти я перемикаюся в режим автоматичного прийняття редагувань, і Claude зазвичай може зробити це за один раз. Гарний план справді важливий!

Я використовую команди зі слеш-літерою для кожного робочого процесу “внутрішнього циклу”, який я виконую багато разів на день. Це позбавляє мене від повторних запитів і дозволяє Claude також використовувати ці робочі процеси. Команди перевіряються в git і зберігаються в .claude/commands/.

Наприклад, ми з Claude використовуємо команду /commit-push-pr slash десятки разів на день. Команда використовує вбудований bash для попереднього обчислення статусу git та кількох інших фрагментів інформації, щоб команда працювала швидко та уникала постійної взаємодії з моделлю.

https://code.claude.com/docs/en/slash-commands#bash-command-execution

Я регулярно використовую кілька субагентів: code-simplifier спрощує код після того, як Claude завершив роботу, verify-app має детальні інструкції для тестування коду Claude від початку до кінця. Подібно до команд зі слеш-літерами, я думаю про субагенти як про автоматизацію найпоширеніших робочих процесів, які я виконую для більшості PR.

https://code.claude.com/docs/en/sub-agents

Ми використовуємо хук PostToolUse для форматування коду від Claude. Клод зазвичай генерує добре відформатований код одразу після встановлення, а хук обробляє останні 10%, щоб уникнути помилок форматування в CI пізніше.

Я не використовую –dangerously-skip-permissions. Натомість я використовую /permissions, щоб попередньо дозволити поширені команди bash, які, як я знаю, безпечні в моєму середовищі, аби уникнути непотрібних запитів на дозволи. Більшість із них перевіряються у .claude/settings.json та надаються команді.

Claude Code використовує всі мої інструменти. Він часто шукає та публікує дописи в Slack (через сервер MCP), виконує запити BigQuery для відповідей на аналітичні питання (за допомогою bq CLI), отримує журнали помилок з Sentry тощо. Конфігурація Slack MCP реєструється в нашому .mcp.json та надається команді.

Для дуже тривалих завдань я або запропоную Клоду перевірити його роботу за допомогою фонового агента після завершення, або використовую перехоплювач Stop агента для більш детермінованого виконання цього завдання, або використовую плагін ralph-wiggum. Я також використовуватиму або –permission-mode=dontAsk, або –dangerously-skip-permissions у пісочниці, щоб уникнути запитів на дозвіл для сеансу, щоб Claude міг працювати, не будучи заблокованим зі мною.

https://github.com/anthropics/claude-plugins-official/tree/main/plugins/ralph-wiggum
https://code.claude.com/docs/en/hooks-guide

І остання порада: мабуть, найважливіше для отримання чудових результатів від Claude Code — це надати Claude спосіб перевірити свою роботу. Якщо Claude має такий зворотний зв’язок, якість кінцевого результату буде в 2-3 рази вищою.

Claude тестує кожну зміну, яку я вношу в http://claude.ai/code за допомогою розширення Claude for Chrome. Воно відкриває браузер, тестує інтерфейс користувача та виконує ітерації, доки код не запрацює, а UX не буде приємним.

https://code.claude.com/docs/en/chrome

Перевірка виглядає по-різному для кожного домену. Це може бути щось просте, як виконання команди bash, запуск набору тестів або тестування програми в браузері чи симуляторі телефону. Обов’язково інвестуйте в те, щоб зробити її надійною».

Як виявилось, робочий процес Черні доволі простий, проте він дозволяє одній людині працювати з потужностями невеликого відділу розробників. Як зазначив один користувач на X, цей досвід «більше нагадує Starcraft», ніж традиційне кодування — перехід від синтаксису набору тексту до керування автономними підрозділами.