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

Воркфлоу у чотири етапи

Етап 1: Планування. Перед написанням будь-якого коду я готую специфікацію. Не розпливчастий опис — нумерований список задач із критеріями прийняття для кожної. Claude Code добре працює з чіткою задачею і погано — з розмитою. Цей етап досі на 100% людський; ШІ тут нема місця, доки ви самі не знаєте, чого хочете.

Етап 2: Worktree. Кожна задача отримує окремий Git worktree (git worktree add). Це та частина, яку більшість людей пропускає, і саме через пропуск AI-assisted проєкти перетворюються на спагеті. Worktree дає кожному субагенту чистий чекаут без побічних ефектів від інших задач у роботі.

Етап 3: Розробка через субагентів. Я викликаю Claude Code в кожному worktree з вузько окресленим промптом: одна задача, одне контекстне вікно, один результат. Ізоляція контексту — не обмеження, а фіча. Субагент, який не бачить решту кодової бази, не може будувати щодо неї припущення. Це змушує промпт бути повним.

Етап 4: Дворівневе рев’ю. Кожна задача проходить рев’ю двічі. Перший прохід: чи реалізація відповідає специфікації? Другий прохід: якість коду — нейминг, складність, чи не було вигадано щось, чого не просили (порушення YAGNI трапляються в AI-виводі часто). Другий прохід я роблю через PR-рев’ю GitHub Copilot, а виправлення застосовує Claude Code. Комбінація працює добре: Copilot позначає проблеми, Claude Code виправляє їх без суперечок.

Реальний приклад: valpere.github.io, фаза 1

Переробка мого власного сайту мала 11 визначених задач — система layout, SCSS override, інтеграція polyglot, сторінки портфоліо, сторінки проєктів і так далі. Кожна задача — один worktree, один виклик субагента, один PR. Загальний астрономічний час на 11 задач склав приблизно три дні календарного часу, з яких активної людської уваги — може, чотири години.

Дві задачі, що виглядали простими, насправді вимагали ретельного промптингу:

• SCSS override для Minima. Minima інжектує власний assets/main.scss через gem. Якщо у вашому проєкті теж є assets/main.scss, Jekyll використовує ваш — але тільки якщо в ньому правильні @import-директиви. Пастка: згенерований _site/assets/main.scss виявився порожнім при першому запуску, бо субагент створив файл без жодного імпорту. Виправлення тривіальне, щойно продіагностоване, але субагент не мав жодного способу дізнатися конвенцію Minima, якщо йому про неї не сказати.

• Перемикач мов polyglot. jekyll-polyglot переписує кореневі відносні href на сторінках недефолтної мови. Перемикач мов, що посилається на /about/, перепишеться на /uk/about/ при рендерингу української версії — включно з посиланням, яке мало б лишатися на тій самій сторінці. Рішення — Liquid-теги static_href, які polyglot явно пропускає. Але субагент використав звичайний <a href>, бо це очевидний варіант. Промпту треба було явно сказати “використовуй static_href для посилань перемикача мов”.

Комбінація Copilot + Claude

PR-рев’ю GitHub Copilot добре ловить стилістичні проблеми та потенційні баги ізольовано. Claude Code добре застосовує виправлення в контексті. Запуск обох на кожен PR забирає, може, десять зайвих хвилин на задачу — і ловив реальні проблеми: дубльовану логіку, відсутню обробку помилок і один випадок, коли субагент додав опцію конфігурації, яку ніхто не просив.

Реальні пастки

Найболючіша не-кодова проблема: мій глобальний ~/.gitignore_global мав патерн _* для ігнорування чернеткових директорій. Jekyll-івські _layouts/, _includes/, _data/ та _posts/ всі підпадають під цей патерн. Worktree виглядали чистими, але їм бракувало критичних директорій. Діагностика зайняла близько години, бо git status не показував нічого поганого — файли були не untracked, вони були невидимими.

Компроміс

Субагентам потрібні точні промпти. Це і ціна, і дисципліна водночас. Написання точного промпту змушує вас насправді продумати задачу перед кодуванням, а це непогана звичка незалежно від тулінгу. Ізоляція контексту означає, що жоден агент не накопичує стан і не робить припущень поперек задач. Ви втрачаєте зручність “ШІ пам’ятає, що ми обговорювали” і натомість отримуєте відтворюваність.

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