Як творець Claude Code запускає кожен проєкт: 6 принципів ефективної роботи з AI

Підхід Бориса Черні (Boris Cherny), творця Claude Code, до старту будь?якого проєкту виявився набагато простішим і «ванільнішим», ніж можна очікувати від інженера. YouTube?канал Austin Marchese зібрав публічні інтерв’ю, треди та приклади його роботи й сформулював шість базових принципів, які можуть застосувати не лише розробники, а й будь?хто, хто будує продукти з допомогою Claude Code.

1. Планування перед кодом: «рухайся повільно, щоб рухатися швидко»

Ключова відмінність у підході — майже все починається з плану. Черня стверджує, що приблизно 80% сесій він стартує в plan mode. Логіка проста: якщо спочатку узгодити хороший план, далі модель «майже завжди просто робить усе правильно».

Типовий сценарій роботи з AI виглядає інакше: користувач відкриває Claude Code, формулює запит і чекає результату. Проблема в тому, що:

• модель намагається якнайшвидше розв’язати задачу, а не обов’язково правильну задачу;
• нечіткий запит ? неправильна постановка задачі ? години дебагу.

Показовий приклад: замість того, щоб виправити відображення числа на сайті, Claude змінив значення в базі даних, «полагодив» один екран і зламав кілька інших. Модель розв’язала проблему, яку сама собі сформулювала, а не ту, яку мав на увазі розробник.

Plan mode якраз і потрібен, щоб цього уникнути. Рекомендований підхід:

• перед початком розробки увійти в plan mode (у терміналі — Shift+Tab двічі);
• проговорити з моделлю:
• які основні проблеми має розв’язати проєкт;
• для кого він створюється;
• що таке успіх;
• чого система не повинна робити;
• попросити Claude інтерв’ювати вас і потім переказати підсумковий план перед тим, як писати будь?який код.

Це зміщує «важке мислення» на початок, а виконання стає майже автоматичним.

2. Claude.md: мінімальні інструкції замість «суперпідказок»

Файл Claude.md — це персональний маніфест для Claude Code: інструкції, які модель читає на старті кожної нової сесії. Його можна використовувати як:

• місце, куди додаються правила після помилок («онови Claude.md, щоб це більше не повторилося»);
• компактний опис стилю роботи, обмежень, стандартів коду чи контенту.

Поширена помилка — перетворювати Claude.md на гігантський документ з десятками правил, які ніхто не чистить. Черня робить навпаки:

• тримає файл коротким (кілька тисяч токенів);
• якщо Claude.md розростається й починає заважати — радить просто видалити його й почати з нуля;
• додає лише мінімально необхідні інструкції, коли модель систематично помиляється в чомусь конкретному.

Аргументація проста:

• моделі швидко еволюціонують, і те, що було критичною інструкцією пів року тому, сьогодні вже «вшито» в саму модель;
• надлишок правил збільшує ризик, що Claude проігнорує справді важливі.

Більш обережний варіант — не видаляти файл повністю, а періодично просити Claude:

«Онови Claude.md, видаливши все, що більше не потрібно, суперечливе, дублюється або створює зайвий шум».

У будь?якому разі принцип той самий: менше — краще, а Claude.md має бути живим, регулярно оновлюваним документом, а не статичним «суперпідказом».

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

Ще один ключовий принцип — дати Claude спосіб перевіряти власну роботу. Черня формулює це так: якщо модель має зворотний зв’язок, це може підвищити якість результату в 2–3 рази.

Схема складається з двох кроків:

1. Надати інструмент, який дозволяє побачити результат роботи (браузер, тестовий запуск, валідаційний скрипт, внутрішній тул).
2. Пояснити Claude, як цим інструментом користуватися.

Далі модель здатна сама:

• запускати сайт у браузері й перевіряти, чи працює функціонал;
• виконувати код і аналізувати помилки;
• проганяти автоматизовані тести.

Це працює не лише для «чорнобілих» задач (код, тести), а й для більш творчих:

• для контенту: «перевір цей текст на відповідність бренд?гайдам і познач усе, що не збігається»;
• для автоматизацій: «запусти цей workflow і переконайся, що вихідні дані відповідають очікуваним».

Універсальний прийом — заздалегідь описати в Claude.md, як саме слід перевіряти результати роботи в конкретному проєкті. Тоді перед побудовою рішення Claude спершу сформулює план верифікації. Якщо чіткого способу перевірки немає, це сигнал, що варто переосмислити підхід.

Корисна команда для періодичного «аудиту» сесії:

«Будь ласка, повернися й перевір усю свою роботу до цього моменту. Переконайся, що ти дотримувався найкращих практик, працював ефективно й не ввів нових проблем».

4. Паралельні сесії та «внутрішні цикли»: як масштабувати себе

Паралельна робота без конфліктів

Щоб збільшити продуктивність, Черня активно працює в паралельних сесіях Claude, але з важливою умовою: задачі мають бути чітко розділені.

Ідея така:

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

Практично це означає: розбивати роботу на непересічні підзадачі й запускати для кожної окрему сесію Claude Code.

«Внутрішні цикли» та Claude Skills

Ще один важливий концепт — inner loop, або «внутрішній цикл». Це дії, які ви повторюєте декілька разів на день:

• типові звіти;
• стандартні перевірки;
• однотипні перетворення даних;
• шаблонні фрагменти коду чи тексту.

Черня використовує slash?команди для таких повторюваних задач, щоб не вводити один і той самий промпт знову і знову.

Більш універсальний інструмент для користувачів Claude Code — Claude Skills. Це спосіб:

• один раз задокументувати процес;
• надалі викликати його як «готову дію» за командою.

Спортивна аналогія: звичайний промпт — це «подриблінгуй м’яч», а Claude Skill — це «зіграємо пік?енд?рол за цією схемою». Модель знає усю послідовність кроків, а ви лише підставляєте нові дані.

Приклад з практики:

• інженерна компанія регулярно готує звіти типу Local Law 97;
• створюється скіл /LL97, який:
• генерує звіт у сталій структурі;
• дотримується одного стилю;
• змінює лише вхідні дані.

Після цього внутрішній цикл стає нескінченно відтворюваним без втрати якості.

Щоб знайти такі внутрішні цикли у власній роботі, можна прямо запитати Claude:

«Виходячи з проєкту, над яким я працюю, які Claude Skills варто створити?»

5. Будувати з прицілом на майбутнє, а не на «ідеальний промпт»

Останній принцип — стратегічний. У команді Черні на стіні висить роздруківка есе Rich Sutton «The Bitter Lesson», де ключова ідея: більш загальні моделі з часом перемагають спеціалізовані рішення.

Звідси випливає кілька висновків:

• не варто «ставити проти моделі» — тобто будувати складні надбудови й мікроналаштування, які через пів року стануть зайвими;
• кожен шматок «скелетування» (обхідних рішень, хаків, надмірно оптимізованих промптів) з великою ймовірністю втратить сенс у найближчі місяці;
• моделі постійно стають кращими, і сьогоднішні обмеження — тимчасові.

Це не означає, що не треба будувати системи. Але варто чесно відповісти собі:

• чи виправданий 10% приріст якості за рахунок складного промпт?тюнінгу, якщо модель через місяць і так стане точнішою?
• чи не краще інвестувати час у:
• інформаційний контур (які дані ви подаєте моделі);
• систему накопичення досвіду (як ви оновлюєте Claude.md, Skills, внутрішні інструменти);
• процеси, які роблять AI кориснішим у вашому контексті?

Формула, яку пропонує цей підхід: менше фетишизму навколо «ідеальних промптів», більше уваги до того, як саме AI вбудований у вашу роботу.

Джерело

How Claude Code’s Creator Starts EVERY Project — Austin Marchese