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

> Чим AI-агент у терміналі відрізняється від чату і як застосувати його в React-роботі: генерація компонентів за зразком, тести до хуків, пошук причини бага. З прикладами промптів.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-09-24
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/claude-code-dlia-react

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

```text
Баг: при швидкому перемиканні табів у 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: рефакторинг зі збереженням поведінки

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

```text
У 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-коду](/blog/ai-kod-chek-list-perevirky) стосується агентів так само, як чату.
- **Архітектурні рішення.** Агент запропонує структуру, але компроміси (продуктивність vs простота, локальний стейт vs глобальний) зважуєш ти – це саме те, що перевіряють на [React-співбесіді](/blog/react-interview-guide).
- **Розуміння.** Якщо після задачі ти не можеш пояснити, що змінилось і чому, – зупинись і розберися, поки зміни свіжі.

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

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

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