Claude Code для React-розробника: агент у терміналі на практиці

Коротка відповідь. Агент у терміналі – це наступний клас AI-інструментів після чату: він бачить твій репозиторій, сам читає файли, запускає команди й ітерує, поки тести не пройдуть. Для React-розробника це означає, що задачі рівня «додай компонент за зразком сусіднього» або «напиши тести до цього хука» можна делегувати цілком – залишивши собі постановку задачі й рев'ю. Розберемо на прикладі Claude Code, але принципи стосуються будь-якого інструмента цього класу.

Чим агент відрізняється від чату

У чаті ти – транспортний шар: копіюєш код у вікно, копіюєш відповідь назад, запускаєш, повертаєшся з помилкою. Агент цю петлю замикає сам:

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

Практичний наслідок: якість результату залежить не від «вміння промптити», а від того, наскільки чітко ти визначив задачу і критерій готовності. Це та сама формула специфікації, що й для чату – але з агентом вона працює на повну, бо критерій готовності («тести проходять») він може перевірити сам.

Сценарій 1: компонент за зразком сусіднього

Найвдячніша агентна задача в React – «зроби ще один такий самий, але інший». У кодовій базі вже є патерн, і агент його зчитує краще, ніж переказ у чаті:

Додай компонент StatusBadge у components/ui/.
- зразок: components/ui/Badge.tsx – та сама структура props,
  той самий підхід до variants
- варіанти: 'active' (зелений), 'pending' (нейтральний),
  'failed' (червоний з токена --error)
- використай існуючі CSS-токени, нових кольорів не додавай
- покажи використання в одному місці: components/OrderRow.tsx
- критерій: pnpm typecheck і pnpm lint проходять

Зверни увагу: жодного опису, ЯК писати компонент. Агент візьме конвенції зі зразка – саме тому важливо вказати, який файл вважати зразком.

Сценарій 2: тести до наявного хука

Типова ситуація: хук useCart працює в продакшені, тестів немає, чіпати страшно.

Напиши тести для hooks/useCart.ts.
- фреймворк: vitest + @testing-library/react (вже в проєкті)
- покрий: додавання товару, повторне додавання того самого id
  (кількість +1, не дубль), видалення, підрахунок total
- окремо: що відбувається з total при порожньому кошику
- НЕ змінюй сам useCart.ts – якщо тест виявить баг, опиши його
  в коментарі, а тест познач як .todo

Останній рядок важливий: без нього агент може «полагодити» хук під свій тест і тихо змінити поведінку продакшен-коду. Гарний тест-сьют, який агент напише за хвилини, далі читай як специфікацію: чи справді це та поведінка, яку ти очікуєш. Як писати такі тести самому – окремо в статті про тести для live coding.

Сценарій 3: пошук причини бага по стек-трейсу

Агент сильний у дебазі, бо може сам відтворити помилку:

Баг: при швидкому перемиканні табів у ProductTabs.tsx у консолі
"Can't perform a React state update on an unmounted component".
- відтвори: запусти тести або dev-сервер, поясни ланцюжок причин
- знайди джерело, запропонуй мінімальний фікс без зміни API компонента
- поясни, чому фікс правильний, перш ніж застосовувати

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

CLAUDE.md: пам’ять проєкту замість повторення правил

Агенти читають файл конвенцій у корені репозиторію (у Claude Code це CLAUDE.md). Усе, що ти повторюєш у кожній задачі, винеси туди один раз:

• стек і версії, команди запуску тестів/лінтера;
• заборонені патерни («класові компоненти не використовуємо», «стилі лише через токени»);
• структуру папок і де що лежить.

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

Сценарій 4: рефакторинг зі збереженням поведінки

Агент особливо доречний там, де зміна велика, але механічна:

У components/ багато компонентів імпортують кольори literal-ами
('#0D7C4D' тощо). Переведи їх на CSS-токени з tokens.css.
- знайди всі входження hex-кольорів у components/ і app/
- для кожного підбери відповідний токен; якщо точного токена
  немає – НЕ вигадуй новий, а випиши список у відповідь
- поведінка й вигляд не змінюються: жодних інших правок у цих файлах
- критерій: pnpm build проходить, git diff містить лише заміни кольорів

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

Типові помилки при роботі з агентом

1. Розмита задача. «Полагодь стилі» – агент щось полагодить, але не факт, що те. Що конкретніший критерій готовності, то кращий результат.
2. Занадто велика задача. «Перепиши застосунок на нову архітектуру» одним заходом – рецепт неконтрольованого diff на п'ятдесят файлів. Ріж на кроки, кожен із яких можна відревʼювати за десять хвилин.
3. Сліпий accept. Прийняти все, не читаючи, бо «тести ж зелені» – тести перевіряють те, що в них написано, а не те, що ти мав на увазі.
4. Брудний робочий стан. Запускати агента поверх незакомічених змін – потім не розплутаєш, де твоє, а де його. Правило просте: коміт перед агентною сесією, окремий коміт після. Тоді відкат – це одна команда.
5. Очікування телепатії. Агент не знає, що «у нас так не прийнято», поки це не написано в CLAUDE.md або в задачі. Незадокументовані конвенції для нього не існують.

Межі: що не делегується

• Рев'ю. Кожен diff читаєш як чужий pull request. Агент прискорює написання, а не приймання рішень – чекліст перевірки AI-коду стосується агентів так само, як чату.
• Архітектурні рішення. Агент запропонує структуру, але компроміси (продуктивність vs простота, локальний стейт vs глобальний) зважуєш ти – це саме те, що перевіряють на React-співбесіді.
• Розуміння. Якщо після задачі ти не можеш пояснити, що змінилось і чому, – зупинись і розберися, поки зміни свіжі.

Документація Claude Code – на docs.claude.com; але клас інструментів ширший за один продукт, і навички постановки задач переносяться між ними без змін.

З чого почати завтра

Візьми найнуднішу задачу з беклогу – ту, яку відкладаєш тиждень: тести до старого коду, рутинний рефакторинг, типізація API-відповідей. Сформулюй письмово контекст, обмеження й критерій готовності, віддай агенту, а собі залиш рев'ю. Одна така задача покаже більше, ніж десять оглядових відео.