Розробка з підтримкою ШІ: Claude, Cursor і межі автоматизації

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

Сьогодні кожен розробник може будь-коли скористатися ШІ як парним програмістом. Питання вже не в тому, чи варто його використовувати, а в тому, як інтегрувати його так, щоб технічний борг не накопичувався швидше, ніж ШІ генерує код. У цій статті я описую робочий процес, до якого прийшов після року використання Claude і Cursor у продакшн-проєктах.

Основна суперечність

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

Це не заклик використовувати ШІ менше. Це пропозиція використовувати його інакше.

Ролі інструментів

Я використовую ці два інструменти для різних завдань:

Claude (у Claude Code / API) — для завдань, що потребують міркування: архітектурних рішень, налагодження складного стану гонитви, перевірки коректності PR, пояснення того, чому фрагмент коду працює саме так. Він спирається на контекст розмови й добре працює з неоднозначністю.

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

Жоден із цих інструментів не замінює проєктне мислення. Обидва замінюють набір тексту.

Контекст — це вузьке місце

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

❌ "Додай пагінацію до блогу"

✅ "Додай курсорну пагінацію до getMdxPosts() у lib/mdx.ts.
   Зараз функція повертає всі дописи, відсортовані за датою у спадному порядку.
   Параметри: { cursor?: string; limit: number }.
   Результат: { posts: BlogPost[]; nextCursor: string | null }.
   Курсор — це slug останнього елемента на попередній сторінці."

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

CLAUDE.md як постійний контекст

Одна з найкорисніших можливостей Claude Code — файл CLAUDE.md: інструкції рівня проєкту, які додаються до кожної сесії. Я документую в ньому те, що модель не може з’ясувати з коду:

## Стратегія тестування

Юніт-тести мокають Prisma через vi.mock() у **tests**/setup.ts — не змінювати цей підхід.
Ніколи не мокати адаптер бази даних; використовувати справжній Prisma client із тестовою базою.

## API Routes

Усі API routes мають використовувати rate limiting через lib/rate-limit.ts.
Використовувати logger.ts (Pino), а не console.log.

## Патерни компонентів

UI-компоненти дотримуються патернів shadcn/ui з CVA для варіантів.
markdown

Це не дає моделі «послужливо» перебудувати вашу тестову конфігурацію або додати console.log у продакшн-код.

Робочий процес для нової функції

Ось як типова функція проходить через набір інструментів:

1. Проєктування в діалозі

Перш ніж торкатися коду, опишіть функцію Claude й обговоріть підхід:

"Мені потрібно додати endpoint для підписки на розсилку. Для email ми використовуємо Resend.
Endpoint має: перевіряти формат email, шукати дублікати через Prisma,
надсилати вітальний лист і повертати відповідь з урахуванням rate limit.
Яка найпростіша реалізація відповідає наявному патерну api/?"

Так архітектурні рішення — де розмістити rate limiting і який вигляд мають відповіді з помилками — стають явними ще до того, як потрапляють у код.

2. Генерація в Cursor

Коли інтерфейс зрозумілий, реалізуйте його за допомогою inline generation у Cursor. Контекст навколишнього файла — наявні routes — підкаже потрібний стиль.

3. Критична перевірка результату

Код, згенерований ШІ, має передбачувані типи помилок:

• Надмірне проєктування: абстракції, яких не виправдовують поточні вимоги
• Брак обробки помилок на межах: добра внутрішня логіка, але слабка перевірка вхідних даних
• Оптимістична робота з конкурентністю: стан гонитви не враховано, наприклад коли двоє користувачів підписуються одночасно
• Вигадані API: функції виглядають правильно, але їх немає у встановленій версії

Читайте результат так, як читали б PR молодшого розробника. Приймайте коректні частини, решту переписуйте.

4. Пишіть тести самостійно

Тести — це специфікація. Коли ви пишете їх самі, доводиться продумати крайові випадки, які ШІ не врахував. Використовуйте ШІ для каркаса тестів — блоків describe і налаштування моків, — але твердження пишіть вручну.

Коли не варто використовувати ШІ

Деякі завдання з підтримкою ШІ виконуються повільніше:

Налагодження продакшн-проблем — модель не бачить ваших логів, реальних даних чи інфраструктури. Вона пропонуватиме правдоподібні виправлення, які не усувають першопричину. Спочатку використовуйте інструменти спостережуваності.

Код, критичний для безпеки — логіка автентифікації, очищення вхідних даних, криптографія. ШІ помиляється тут непомітно, і такі помилки можуть пройти code review. Пишіть цей код із розумінням основ і віддавайте його на аудит.

Рефакторинг між багатьма файлами — контекстне вікно моделі обмежує її огляд залежностей. Великі рефакторинги краще спочатку спланувати в діалозі, а потім виконати вручну або спеціалізованим скриптом.

Вимірювання реального прискорення

За моїми спостереженнями, рутинні завдання реалізації — CRUD-endpoints, компоненти форм, утилітарні функції — виконуються у 3–4 рази швидше. Швидкість архітектурної роботи й налагодження майже не змінюється: основний час іде на планування.

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

Висновок

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