9 практичних порад Бориса з Кодексу Клода: Виявляється, що конфігурація майстра дуже «проста» Борис Черний має прізвисько в Anthropic: батько Клода Кода. Останнім часом він був активним на X, тому багато хто запитує Бориса: Як саме ти сам користуєшся Claude Code? Він щойно поділився 9 практичними порадами щодо X. Трюків не так багато, як ви думаєте, і кожен з них простий. [1] Основна філософія: Не існує стандартної відповіді на найкращі практики Claude Code Борис почав словами: > Моя система може бути дивовижно ванільною! Claude Code чудово працює з коробки, тому особисто я не дуже його налаштовую. > Моя конфігурація може бути «оригінальною», як ви й очікуєте. Claude Code чудово працює з коробки, і особисто я не робив багато налагоджень. Зрозуміло, що ці найкращі практики, такі як Skills і Plugins, давно були вбудовані у функції розробників Claude Code. Не існує єдиного правильного способу використання Claude Code. Команда навмисно спроєктувала його так, щоб можна кидати невимушено, і ви можете використовувати його як завгодно, як хочете змінити і як хочете змінювати. Кожен у команді Claude Code використовує його зовсім по-різному. Тож немає потреби шукати «найкращі практики», найголовніше — підлаштовуватися під свій ритм. [2] Мультиагентні завдання паралельно: Відкривайте понад десяток Claudes одночасно Щоденний розпорядок Бориса такий: відкриває 5 екземплярів Claude Code у терміналі, відкриває вкладки з 1 по 5, вмикає системні сповіщення і пропускає, який потрібно ввести. Водночас він виконує 5–10 завдань у веб-версії. Термінали та веб-сторінки можуть «передавати» один одного: використовуйте символ & для передачі локальної сесії на веб-сторінку або використовуйте --телепорт для перемикання з обох сторін. Він запускає кілька завдань із додатку Claude на телефоні щоранку та вдень, а потім повертається, щоб побачити результати. Основна логіка цього «багатопотокного» способу роботи полягає в тому, що Claude Code добре виконує автономію, і багато завдань не вимагають контролю. Ви починаєте завдання, даєте йому напрямок, даєте їй працювати і робите щось інше самостійно. Скорочуйте витрати, коли потрібне ваше підтвердження. Це зовсім інше від традиційного «людина набирає рядок коду, а штучний інтелект вигадує кілька рядків». Однак це також вимагає вищих вимог користувачів, і потрібно добре призначати завдання агентам і вміти перемикатися між кількома завданнями в будь-який момент. Це великий виклик для традиційних моделей розробки, які звикли розробляти самостійно і виконують лише одне завдання одночасно. Мені соромно зізнатися, але хоча я також регулярно користуюся Coding Agent, я все ще не звик виконувати забагато завдань одночасно, тому цього року посилю свою практику в цій сфері. [3] Вибір моделі: Чому використовувати Opus замість швидшого Sonnet Борис каже, що використовує Opus 4.5 для всіх своїх завдань у режимі мислення. Це найкраща модель програмування, яку він коли-небудь використовував. Дехто запитає: хіба Opus не більший і повільніший за Sonnet? Відповідь Бориса полягає в тому, що хоча одна відповідь трохи повільніша, її потрібно коригувати значно менше, виклики інструментів точніші, а кінцевий результат швидший. Насправді, я завжди погоджувався, що написання коду не може бути швидким, а має бути якісним; якщо швидка модель вимагає тричі коригувати її туди-сюди, краще використовувати повільну модель одночасно. Час — це не лише час реакції моделі, а й ваша увага та витрати зусиль. Єдина проблема в тому, що Opus коштує дорожче. 【4】 є спеціальним конфігураційним файлом Claude Code, розміщеним у корені проєкту. Кожного разу, коли ви запускаєте Claude Code, він автоматично читає файл і розглядає його вміст як «фонові знання». Ви можете зрозуміти це так: це специфікація проєкту, яку ви написали для ШІ, яка описує структуру, специфікації та заходи безпеки проєкту. Підхід команди Boris полягає в тому, що весь репозиторій Claude Code підтримується в одному Git. Щотижня люди додають щось до Рігано. Правило просте: кожного разу, коли бачите, що Клод робить щось не так, напишіть «не роби цього», і наступного разу він дізнається. Ще цікавіше те, що вони також використовують цей механізм при перегляді коду. Борис напише @.claude у PR свого колеги і попросить Клода додати нове правило до . Це досягається за допомогою GitHub Action від Claude Code. Ден Шиппер називає це «проєктом зі складними відсотками»: кожна корекція помилки стає командним активом, що дозволяє ШІ краще розуміти ваш проєкт. Якщо ви ще не використовували команду, Claude автоматично проаналізує структуру проєкту і створить початкову версію. Потім додаєш по мірі використання і додаєш, що не так, коли бачиш це. [5] Режим планування: думайте чітко перед тим, як діяти Борис каже, що більшість своїх сесій починає в режимі планування. Подвійний клік Shift+Tab у Claude Code для перемикання. У режимі планування Клод не змінює код напряму, а спочатку дає план виконання. Ви можете обговорювати та переглядати свій план, поки не будете задоволені. Потім перемикаємося в режим автоматичного прийняття, який Клод зазвичай робить за один раз. «Хороше планування дуже важливе», ця звичка фактично переносить класичну мудрість розробки програмного забезпечення на співпрацю з ШІ: спочатку дизайн, а потім код. Проблема, з якою багато людей використовують ШІ для написання коду, полягає в тому, щоб почати його безпосередньо, і в результаті вартість переробки висока через неправильний напрямок. Кілька хвилин на узгодження плану економлять години на переробку. [6] Автоматизація повторюваної роботи: слеш-команди та підагенти Борис мав кілька операцій, які мусив виконувати десятки разів на день, і перетворив їх на слеш-команди. Наприклад, "/commit-push-pr" завершує подання, push і створення PR одним кліком. Slash-команди — це, по суті, файли Markdown, які розміщуються під каталогом .claude/commands/. Ви можете писати команди природною мовою, а також вбудовувати bash-скрипти, щоб отримати інформацію одразу, зменшуючи кількість викликів моделі туди-сюди. Ці команди можна передавати в Git і ділитися всією командою. Окрім команди косої черти, він також використовує підагента (агент — це окремий екземпляр Клода, який спеціалізується на певних типах роботи). Наприклад, у нього є підагент спрощувача коду, який автоматично спрощує код після завершення основної роботи Клод. Існує також підагент для перевірки додатків, який відповідає за наскрізне тестування. Те, що об'єднує ці дві риси — ти постійно закріплюєш те, що робиш, і дозволяєш Клоду називати це сам. Вам не потрібно повторювати пояснення щоразу чи запам'ятовувати деталі команди. Використовуйте PostToolUse Hook для форматування коду, згенерованого Claude. Claude зазвичай автоматично генерує добре відформатований код, і цей гачок обробляє останні 10% коду, щоб уникнути неправильного форматування на етапі процесу безперервної інтеграції (CI). [7] Безпека та інтеграція: конфігурація дозволів та зовнішні інструменти Борис не використовує опцію --dangerously-skip-permissions. Натомість він попередньо схвалює деякі поширені команди безпеки командою /permissions, щоб уникнути з'явлення вікна підтвердження щоразу. Ці конфігурації зберігаються у форматі .claude/settings.json і діляться командою. Ще потужнішою є інтеграція з MCP сервером. MCP, скорочено від Model Context Protocol, — це стандартний протокол, запущений компанією Anthropic, який дозволяє ШІ підключатися до зовнішніх інструментів. З MCP Claude Code може безпосередньо: - Пошук і надсилання повідомлень у Slack - Запуск запитів BigQuery для відповіді на питання з даними - Витягти журнал помилок із Sentry Команда Boris також надіслала конфігурацію MCP від Slack до репозиторію, і всі одразу ж користувалися нею. Це означає, що Claude Code — це не просто інструмент програмування, а «універсальний асистент», який може викликати весь ваш набір інструментів. [8] Довга обробка завдання: Нехай Клод сам це перевірить Для тривалих місій у Бориса є кілька стратегій: Перший — дозволити Клоду автоматично використовувати фоновий агент для перевірки результатів після завершення. Ви можете запитати це в підказці або використати Stop Hook, щоб активувати більш детерміновано. > Примітка: Гачки — це механізм «гака» в Claude Code, який дозволяє вставляти власну логіку в певні моменти, коли Клод виконує дію. Можна уявити це як «тригер»: коли трапляється подія, автоматично виконуйте свою команду або скрипт. > Stop Hook — це коли Клод відповідає і готовий передати контроль. > Пов'язана документація: Другий — використовувати плагін Ralph-Wiggum, який по суті є Bash-циклом: уявіть простий мертвий цикл (хоча це правда), який постійно подає той самий оператор завдання (файл запитів) агенту AI, змушуючи його постійно покращувати свою роботу, поки не буде повністю готовий. Третій — використовувати --permission-mode=dontAsk або --dangerously-skip-permissions у пісочниці, щоб Клод не був перерваний підтвердженням дозволу і не працював до кінця самостійно. Основна ідея така: оскільки це довге завдання, не дозволяйте йому чекати на вас. Дайте йому достатньо автономії та здатності до самокорекції. [9] Найважливіше: надати Клоду можливості валідації Борис ставить цю пісню наприкінці, стверджуючи, що це, ймовірно, найважливіший фактор для досягнення хорошого результату. Якщо Клод зможе підтвердити свою роботу, кінцеву якість результату можна підвищити у 2–3 рази. Він навів приклад: для кожної зміни, яку вони надсилають, Клод тестує себе за допомогою розширень Chrome: відкриває браузер, тестує інтерфейс і повторює, коли знайде проблему, поки все не запрацює правильно і досвід не стане розумним. Методи верифікації відрізняються залежно від ситуації. Це може бути запуск команди bash, тестовий набір або тестування додатку в браузері чи емуляторі мобільного телефону. Форма не важлива, але головне: дайте штучному інтелекту мати зворотний зв'язок. Ця істина насправді дуже проста. Людські інженери також покладаються на цикл «написання коду, тестування, перегляд результатів, модифікації» для забезпечення якості. Те саме стосується і штучного інтелекту. Якщо це можна лише написати, а не вимірювати, це як робити щось із закритими очима, і якість залежить від удачі. Пропозиція Бориса — інвестувати у зміцнення механізму верифікації. Це найвища рентабельність інвестицій. [10] Майстри використовують мечі, щоб перемагати без ходів У романах про бойові мистецтва майстри не мають стільки наворотів із мечами, і немає ходів для перемоги. Борис не демонструє складні кастомні налаштування, не має загадкових приватних підказок і використовує офіційні функції. Різниця в тому, що він дійсно розуміє логіку цих функцій і поєднує їх у ефективний робочий процес. Паралельна робота виконується тому, що Клод може виконувати автономно; Opus використовується через вищу загальну ефективність; Це перетворення корекції помилок на активи; Режим Плану — це чітко мислити перед тим, як діяти; слеш-команди та підагенти — це автоматична повторювана праця; Механізм верифікації полягає в тому, щоб надати зворотному зв'язку ШІ замкненому циклу. Якщо ви тільки починаєте з Claude Code, немає потреби поспішати з складними налаштуваннями. Спочатку добре використайте основи: навчіться працювати паралельно, планувати та накопичувати методи верифікації за допомогою ШІ. Коли ви справді стикаєтеся з вузьким місцем, ще не пізно кинути ці квіти.

Одне, про що Борис не згадав, — це базовий робочий процес перевірки CI/коду, що може бути нормою для великих компаній і має бути там за замовчуванням Наприклад, коли він виконує завдання за допомогою Claude Code, він не каже про пряме злиття з головною гілкою, а надсилає PR. Після подання PR усі lint і автоматизовані тести автоматично запускаються на CI-сервері, і якщо тест не пройде, PR не можна об'єднати. PR проходить усі автоматизовані тести і потребує когось для перевірки коду (звісно, допомога ШІ можлива, але її все одно потрібно підтвердити), і якщо перевірка коду виявляє проблеми, його потрібно переглянути. Для багатьох окремих розробників вони не звикли будувати робочий процес CI/перегляду коду, і навіть не займаються управлінням кодом у Git, тому не можуть повернутися назад, якщо щось піде не так.

[10] Ті речі, яких не видно Одне, що Борис не згадав, — це базовий робочий процес контролю версії/CI/перегляду коду, що може бути нормою для великих компаній і має бути там за замовчуванням Наприклад, коли він виконує завдання за допомогою Claude Code, він не каже про пряме злиття з головною гілкою, а надсилає PR. Після подання PR усі lint і автоматизовані тести автоматично запускаються на CI-сервері, і якщо тест не пройде, PR не можна об'єднати. PR проходить усі автоматизовані тести і потребує когось для перевірки коду (звісно, допомога ШІ можлива, але її все одно потрібно підтвердити), і якщо перевірка коду виявляє проблеми, його потрібно переглянути. Вони також є основою їхньої здатності виконувати кілька завдань одночасно, і без цих базових робочих процесів вони не можуть виконувати багатозадачність паралельно. Для багатьох окремих розробників вони не звикли будувати робочий процес CI/перегляду коду, і навіть не займаються управлінням кодом у Git, тому не можуть повернутися назад, якщо щось піде не так.