Як я веду дев’ять проєктів через Claude Code, не будучи програмістом

Claude Code — це ШІ-агент від Anthropic, який працює просто на вашому комп’ютері. Він читає й редагує файли, запускає команди, публікує сайти. Ви пишете завдання звичайними словами, а агент виконує його сам.

Я керую SEO та маркетингом. Десять років займаюся стратегією, аналітикою, контентом і командами — але не кодом. Раніше я створив кілька невеликих сайтів в іншому ШІ-редакторі, але ніколи не налаштовував комп’ютер для розробки.

7 липня 2026 року я щойно купив Mac. Я спитав Claude, що встановити, щоб створювати сайти за допомогою GitHub і Cloudflare. Потім поставив два запитання, на які будь-який розробник усміхнувся б. Спочатку треба встановити Homebrew, а вже поверх нього — все інше? І що таке wrangler — хіба це не щось усередині Cloudflare, навіщо тоді він мені?

Нотатка, яку агент зберіг про мене того дня, написана без прикрас: новачок, який не знає, що таке wrangler і навіщо потрібен Homebrew. Homebrew був єдиним, що агент не зміг установити за мене, бо треба було ввести пароль від Mac. Усе інше він установив сам менш ніж за чотири хвилини.

Через три місяці той самий агент працює зі мною над дев’ятьма проєктами. Зростання, аналітика й SEO для happymonday.ua — української кар’єрної платформи. Фабрика сайтів на роботі, яка створює, розгортає й відстежує мережу сайтів у Cloudflare. Моя невелика мережа контентних сайтів. Енциклопедія кімнатних рослин англійською та українською. Невеликий сайт з інструментами, застосунок для ШІ-контенту й цей сайт. І два проєкти з другом: застосунок із графами Notion і застосунок для диктування на Mac.

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

Цифри за три місяці

Я порахував. Із 7 липня до 3 жовтня я надіслав близько 1 750 повідомлень. Медіанна довжина повідомлення — близько 620 символів; приблизно 280 повідомлень довші за 2 000. Третина містить «е-е» і «м-м»: я говорю, а не друкую. Приблизно до 950 повідомлень я додав знімки екрана — загалом близько 2 500 зображень.

Два показники говорять більше за решту. Я вручну перемикав модель близько сотні разів. А мій робочий проєкт із 10 липня живе в одній головній розмові: вона переросла робочу пам’ять агента, і її стискали 43 рази. Один проєкт, одна головна розмова, три місяці. Це працює лише тоді, коли важливе зберігається поза розмовою — у файлах, які агент щоразу перечитує.

Перший рівень: глобальний CLAUDE.md, який агент читає щоразу

1 серпня я знову поскаржився, що в кожній новій сесії мушу заново пояснювати про ключі, SSH, GitHub і Cloudflare. Того вечора з’явилася перша версія глобального файлу правил: CLAUDE.md у моїй домашній папці. Claude Code читає його на початку кожної сесії в кожному проєкті. Сьогодні в ньому трохи понад 200 рядків. Одразу під заголовком написано: цей файл має бути коротким.

У ньому п’ять речей:

• Профілі. У мене їх чотири: робота, клієнт, мої партнерські сайти й особисті проєкти. Кожен профіль — це набір з одного облікового запису Google, одного облікового запису Cloudflare й одного GitHub. Проєкт завжди працює під одним профілем, і агент ніколи їх не змішує.
• Де зберігаються ключі та як читати їх, не виводячи на екран.
• Як я хочу працювати — дев’ять правил, більшість із яких з’явилися після помилок.
• Стандарт проєкту: кожен проєкт має паспорт і один беклог.
• Що ніколи не відбувається без мого «так»: видалення будь-чого, купівля домену чи будь-які інші витрати.

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

Ключі заслуговують на окремий абзац. Я більше не вставляю їх у чат. Вони зберігаються в KeePassXC, головний пароль — у Зв’язці ключів macOS, а агент читає ключ однією командою й ніколи не виводить його значення. Коли я отримую новий ключ, то додаю його у звичайний текстовий файл у кореневій папці проєкту. Агент переносить його до сховища, перевіряє реальним запитом і лише після цього очищає файл. Саме очищає, а не видаляє. Через це слово я втратив токен, але до цього ще повернуся.

Другий рівень: скіли (skills) — плейбуки замість промптів

6 серпня я помітив неприємну річ. В одному проєкті я налаштував резервні копії. В іншому — ні, хоча був упевнений, що налаштував. Спільної бази практик не було: кожен проєкт знав лише те, що я сказав у його власній розмові.

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

В одному місці перевірка дійшла хибного висновку. У старому рядку мого файлу правил було написано не використовувати Tag Manager, а додавати тег Google напряму, і агент хотів зробити це жорстким правилом. За кілька хвилин я виправив його: ми завжди встановлюємо Tag Manager. Потім агент перевірив код: Tag Manager уже використовували сім сайтів у моїх проєктах. Плейбук має описувати те, що я справді роблю, а не те, що написано в одному старому рядку.

Зараз є сім скілів:

1. Запустити новий сайт — домен, репозиторій, розгортання, аналітика, Search Console, індексація, резервна копія.
2. Налаштувати аналітику — Tag Manager на кожному сайті, один службовий обліковий запис на профіль, перевірка на опублікованій сторінці.
3. Перевірити резервні копії — резервна копія зараховується лише після перевіреного відновлення.
4. Перевірити доступи — знайти всі секрети, перенести їх до сховища, замінити ті, що витекли.
5. Перевірити проєкт за стандартом і заповнити його паспорт.
6. Перевірити логіку — знайти помилки, яких не ловлять тести.
7. Яким метрикам Ahrefs довіряти — а які ігнорувати.

Промпт — це побажання. Плейбук — чек-лист із перевірками, які агент може виконати сам. «Налаштуй аналітику» нічого не означає. «Один контейнер на сайт, теги лише всередині контейнера, роботу підтверджено мережевими запитами на опублікованій сторінці» — це те, що агент може зробити й довести.

Друга половина системи — паспорт. У кожного проєкту є короткий файл, де вказано його профіль, спосіб розгортання, розташування аналітики й резервних копій, а також посилання на єдиний беклог. Усе, що ми обговорили, але не зробили, потрапляє до цього беклогу. Не в чат, не в другий документ — один файл на проєкт.

Третій рівень: пам’ять, де кожне правило має шрам

Агент зберігає пам’ять між сесіями: близько 150 нотаток у моїх проєктах. Понад 50 із них — уроки: щось пішло не так, і ось правило. Мені так подобається цей формат, що тепер я не довіряю правилам без історії. Ось кілька прикладів.

Коли	Що зламалося	Правило відтоді
7 серпня	Здавалося, що розгортання триває до 20 хвилин. Насправді воно займало близько десяти секунд, а повільний етап генерації був доданий до тієї самої команди.	Перед запуском команди оцінити, скільки часу вона має тривати.
7 серпня	Агент зберіг обрізаний токен, сприйняв undefined як успіх і видалив початковий файл. Токен було втрачено.	Спочатку перевірити реальним запитом. Потім очистити файл — ніколи не видаляти його.
14 серпня	Фонові завдання дев’ять хвилин показували «No output yet». Сама робота зайняла близько хвилини.	Людина має бачити прогрес рядок за рядком.
15 серпня	Перезапис історії git стер із диска 31 кадр брендбука й 156 дизайнів обкладинок — одразу після слів «із диска нічого не видаляється».	Нічого не видаляти без окремого чіткого «так» для кожного видалення.
25 серпня	Три нові перевірки пройшли успішно, нічого не перевіривши.	Перевірка зараховується лише тоді, коли вона знаходить навмисно повернену помилку.
21 вересня	Агент оцінив сторінку за мініатюрою: «структурно все гаразд». У повному розмірі 12 із 56 клітинок були порожніми.	Оцінювати макет за вимірами або в повному розмірі.
22 вересня	«Готово» — хоча коду ще не було в продакшені.	«Готово» означає розгорнуто й перевірено запитом.

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

Деякі шрами повторюються. 26 вересня було втрачено ще один секрет: значення надійшло без розриву рядка, а помічник для збереження ключів однаково вивів «✓». Тепер він зчитує збережений запис і порівнює значення. Той самий урок, але на рівень глибше.

Четвертий рівень: як я навчив його писати для мене

Агент багато вмів, але його було важко читати. Він використовував назви з коду, вигадував власні терміни й замість відповіді давав звіт про роботу. За моїми приблизними підрахунками, частка повідомлень, де я скаржився на зрозумілість, зросла з 6% у липні до 15% у серпні та 28% у вересні. Що складнішою ставала система, то більше сил вимагало її розуміння.

Мої повідомлення зі скаргами на зрозумілість

Частка повідомлень зі скаргами на зрозумілість: 6% у липні, 15% у серпні, 28% у вересні.

6% Липень

15% Серпень

28% Вересень

Тому агент переглянув мою історію й зібрав 100 пар «його відповідь → моя скарга». Найчастіші проблеми: жаргон і англійські терміни, яких я ніколи не вживав (28 випадків), назви з коду (27), звіт про роботу замість відповіді (25), самостійно вигадані терміни (21), суцільні полотна тексту (16) і запитання завдовжки три слова (12). Із цих пар з’явився гайд зі стилю: перше речення відповідає на запитання; речі названі так, як я бачу їх на екрані; біля чисел є одиниці вимірювання й пояснення; кожне запитання до мене зрозуміле без контексту й містить рекомендацію.

Про що були 100 пар «відповідь агента → моя скарга»

Жаргон 28, назви з коду 27, журнал роботи замість відповіді 25, вигадані терміни 21, суцільні полотна тексту 16, запитання на три слова 12.

Жаргон і англійські терміни, яких я не вживаю 28

Назви з коду 27

Журнал роботи замість відповіді 25

Вигадані терміни 21

Суцільні полотна тексту 16

Запитання на три слова 12

До

Бар’єр порівнює назви класів, а не геометрію. Пропонується бар’єр другого рівня: візуалізація в Playwright…

Після

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

Потім ми провели сліпий тест. Два агенти переписали сім реальних відповідей, на які я скаржився: одному сказали «просто зроби зрозуміліше», інший дотримувався гайду зі стилю. Третій агент оцінив їх, не знаючи, де чия версія. Перша версія гайду перемогла лише в 4 випадках із 7. Після виправлень вона перемогла в 5 із 7, програла в 1 і ще в 1 була нічия. Зрозумілість після першого прочитання: 4,1 проти 3,1 із 5.

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

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

Погані тексти не залишилися лише в моєму чаті. 21 вересня агент за один день написав документ зі статусом на 2 600 слів і чотири коментарі до завдань у клієнтському проєкті. Я сказав, що це читається як складна технічна документація, і того ж дня команда клієнта сказала те саме. 1 жовтня в моєму робочому проєкті він майже дослівно передав мені п’ять запитань від іншого агента. У жодному не було сказано, яку кнопку мають на увазі й що зараз відбувається. Я не зрозумів жодного. На чотири з п’яти я відповів: просто зроби логічно.

Із 3 жовтня гайд зі стилю охоплює кожен текст, який читатиме людина: відповіді мені, завдання й коментарі в командному трекері, повідомлення в Slack, документи, статуси, навіть кнопки й сповіщення в наших інструментах. Контент сайтів він не охоплює: у нього залишається власний голос. Для запитань діє окреме правило. Усе, що має логічну відповідь, агент вирішує сам і повідомляє мені одним рядком. Він запитує лише про справжній вибір: де це на екрані, що відбувається зараз, що зміниться після «так» або «ні» та що він рекомендує.

Як я з ним розмовляю

Я диктую. Мої повідомлення довгі й змішані: запитання, рішення, нове завдання та скарга одним духом — часто поки агент ще працює над попереднім. Близько 180 повідомлень я надіслав, поки він був зайнятий.

Це має свою ціну. 12 серпня я сказав: «Я щось диктую, ти відповідаєш на частину, а решта губиться». Ми перевірили: із 32 повідомлень за два дні зникло близько 15 пунктів. Відтоді правило просте. Кожне повідомлення розбивається на пункти, а кожен пункт або виконують, або записують у беклог, або явно відхиляють.

Через шість тижнів ми перевірили дев’ять завантажених днів мого робочого проєкту: 660 пунктів із моїх повідомлень. 403 виконано, 145 були в беклозі, 21 скасовано — а 91 не потрапив нікуди. Саме через останнє число існує це правило. І саме тому його виконання треба перевіряти, а не вважати само собою зрозумілим.

Куди потрапили 660 пунктів із моїх повідомлень

660 пунктів: 403 виконано, 145 у беклозі, 21 скасовано, 91 загубився.

• Виконано 40361%
• У беклозі 14522%
• Скасовано 213%
• Загубилися 9114%

Коли 50 субагентів — неправильна відповідь

Claude Code може паралельно запускати десятки субагентів (subagents). Це створює відчуття сили, і сам агент охоче перетворить невелику перевірку на сотню субагентів. Ось кілька чисел із моєї історії:

• 49 субагентів запустили, щоб відповісти на запитання, відповідь на яке вже була у файлі, написаному напередодні.
• Перевірка аналітики дала 31 знахідку, а скрипт призначив на кожну трьох скептиків — 93 субагенти й близько 6,5 мільйона запланованих токенів. Я зупинив процес на 31 вердикті й приблизно 2,2 мільйона токенів. Тоді я сказав: «Я не проти великих досліджень. Але в них має бути сенс».
• Одного вечора перевірка із 24 + 7 субагентів витратила весь тижневий ліміт флагманської моделі.

Тепер правила такі: перед запуском назвати кількість субагентів і приблизну кількість токенів. Щонайбільше — близько десяти субагентів на завдання. Не відправляти субагентів перевіряти те, на що можна відповісти одним запитом. Масові паралельні запуски виконувати на дешевшій моделі, а підсумки залишати флагманській — і ніколи мовчки не перемикатися на слабшу модель.

Auto mode: скільки самостійності я йому даю

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

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

Два запитання, які мені ставлять

Чи можна користуватися Claude Code, якщо не вмієш програмувати?

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

Де зберігається глобальний CLAUDE.md?

У домашній папці: ~/.claude/CLAUDE.md. Claude Code читає його в кожному проєкті. Додатково кожен проєкт може мати власний CLAUDE.md у своїй папці. У моїх зберігається короткий паспорт: які облікові записи використовує проєкт, як він розгортається, де його беклог.

Якщо ви керуєте SEO й починаєте завтра

1. До першого проєкту створіть один файл правил: облікові записи, де зберігаються секрети, що означає «готово», що ніколи не відбувається без дозволу.
2. Ніколи не вставляйте ключі в чат. Використовуйте менеджер паролів, із якого агент може їх читати.
3. Перетворюйте кожне повторюване завдання на скіл із перевірками, а не на промпт.
4. Ведіть один беклог на проєкт. Кожен пункт, який ви диктуєте, має бути виконано, додано до беклогу або відхилено.
5. Записуйте кожну помилку як правило — разом із її історією.
6. Просіть докази: опубліковану сторінку, реальні дані, запит. А не «я перевірив код».
7. Рахуйте субагентів і токени перед великими запусками.
8. Навчіть агента писати для вас і перевірте це сліпим тестом.

Для цього мені не довелося вчитися програмувати. Мені довелося керувати агентом так, як я керував би сильним, швидким і надто самовпевненим новим працівником: чіткі правила, записані стандарти й жодної довіри без доказів.