Claude Code: базовий воркфлоу для QA

Зміст

Актуально станом на липень 2026. Інструменти цього класу змінюються швидко — деталі звіряй з офіційною документацією.

Claude Code — це термінальний агент (terminal agent) від Anthropic: ти запускаєш команду claude у теці свого проєкту, описуєш задачу звичайною мовою, а він читає файли, редагує код, запускає команди й тести — і крутить цей цикл, поки не доведе справу до кінця. Для QA це не «чат, який пише тести», а виконавець, що працює прямо у твоєму репозиторії автотестів: бачить реальний код, реальні падіння, реальні локатори. Це принципова відмінність від звичайного чат-бота, і саме з неї випливають усі особливості роботи.

На співбесідах усе рідше питають «чи чув про AI» і все частіше — «як ти ним користуєшся у щоденній роботі». Сильна відповідь — це не «AI все зробить», а конкретний воркфлоу з точками контролю: як ти ставиш задачу, де рев'юиш результат, чому не довіряєш зеленому прогону наосліп. Ця глава — про такий воркфлоу. Вона спирається на агентний цикл і промптинг для QA; окремі теми (пам'ять проєкту, сабагенти, MCP) винесені в сусідні глави й тут лише згадуються.

Термінальний агент: не чат, а виконавець

Звичайний чат повертає текст — ти сам копіюєш його в редактор і запускаєш. Агент замикає цю петлю: у нього є інструменти (tools) — читати й редагувати файли, виконувати команди в оболонці (shell), працювати з git. Він не «радить», а діє й одразу бачить результат своєї дії: вивід тесту, повідомлення компілятора, дифф.

Чому це важливо саме для QA. Тест живе не в вакуумі — він залежить від структури проєкту, від page object'ів, від того, як налаштований раннер. Агент, що сидить у твоєму репозиторії, читає ці файли й підлаштовується під них, а не генерує абстрактний код «взагалі». Він може згенерувати тест, тут же його запустити, побачити червоне й полагодити — усе в одній сесії, без твого копіювання туди-сюди.

Сесія і дозволи

Сесія (session) — це одна безперервна розмова з агентом разом із накопиченим контекстом: історія повідомлень плюс усе, що агент прочитав і змінив. Контекст живе в обмеженому вікні (див. Токени, контекст і вартість), тому довгі сесії варто розбивати; Claude Code вміє їх зберігати й відновлювати (claude --continue, claude --resume), щоб задача перетривала кілька підходів.

Другий стовп — дозволи (permissions). Агент може виконати будь-яку команду в терміналі, і саме дозволи стоять між тобою і випадковим rm чи push у спільну гілку. Читання (read, grep) безпечне й іде без запиту. А от зміна стану — правка файлу, bash-команда, git push — за замовчуванням потребує підтвердження. Режими дозволів перемикаються клавішею Shift+Tab по колу default → acceptEdits → plan:

default — агент питає перед кожною зміною;
acceptEdits — авто-приймає правки файлів (але не довільні команди);
plan — режим лише для читання: агент нічого не змінює, тільки складає план.

Практичний висновок для QA: не вмикай авто-прийняття на прод- чи спільному стенді — там ціна помилкової команди висока. У CI агент працює неінтерактивно (headless), тож там дозволи задають конфігурацією заздалегідь, а не клацанням. Тема довіри й ізоляції ширша — див. Безпека й приватність при роботі з AI.

Постановка задачі

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

Сильна постановка містить три речі: що саме зробити, критерій готовності (acceptance criteria — коли вважати задачу виконаною) і обмеження (який інструмент, чого не чіпати). Плюс вказівка на файли — у Claude Code це роблять через @, наприклад @tests/login.spec.ts, щоб агент одразу підтягнув потрібний контекст. Загальні правила формулювання промптів розібрані окремо в Промптингу для QA.

Окремо варто зафіксувати конвенції проєкту — house-стиль назв, підхід до локаторів, структуру page object'ів — щоб не повторювати їх у кожному промпті. Для цього є файл CLAUDE.md (див. Пам'ять, скіли та слеш-команди): те, що там записано, агент читає автоматично на старті сесії. Без нього агент вигадує конвенції на льоту — і вони не збігаються з твоїми.

План перед виконанням

Перш ніж дати агентові редагувати код, часто розумно попросити план. У режимі plan (той самий Shift+Tab, у статус-рядку видно ⏸ plan mode on) агент читає файли, розбирається в задачі й пропонує план змін — але не чіпає жодного файлу, поки ти не схвалиш.

Чому це працює. Виправити план — це виправити намір, і це на порядок дешевше, ніж потім розбирати неправильний дифф на пів екрана. Для junior це ще й спосіб навчання: ти рев'юиш підхід («він збирається мокати весь бекенд — а треба лише платіжку») до того, як з'явився код. Апрув плану = апрув напрямку.

Ітерація: тести → фейли → фікс

Це серце воркфлоу і буквальне втілення агентного циклу. Агент вносить зміну, запускає тести, бачить падіння, аналізує вивід, править — і повторює прогін, поки не стане зелено. Саме здатність запустити тест і прочитати результат відрізняє агента від чат-бота: він звіряє свою роботу з реальним виводом, а не з відчуттям «виглядає правильно».

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

Робота з git

Claude Code працює з git як звичайний інженер: дивиться git status і git diff, створює гілки, робить коміти, а через gh — і pull request'и. Коли ти запускаєш gh pr create, сесія автоматично прив'язується до цього PR, тож до неї легко повернутися пізніше.

Для QA git — це не побічна деталь, а головна точка контролю. Коміт (commit) — це чекпоінт: якщо агент пішов не туди, ти відкочуєшся до попереднього стану замість ручного розгрібання. Дисципліна проста й непорушна:

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

Дифф — те місце, де «агент згенерував купу коду» перетворюється на «я розумію й приймаю кожен рядок».

QA-сценарії: тест, фейл, локатори

Три щоденні сценарії, де воркфлоу дає найбільше.

Генерація тесту. З ручного тест-кейсу або user story — у робочий Playwright/CodeceptJS-тест. Сила агента тут у тому, що він дивиться на наявні тести й page object'и та підлаштовується під їхній стиль, фреймворк і патерни асертів, а не пише «з нуля». Це продовження теми Генерації тест-артефактів: агент чорнетить, ти доводиш і рев'юиш.

Аналіз падіння. Згодуй агентові вивід упалого тесту разом із trace/логом — він тріажить: де саме зламалось, чи це зміна селектора, чи гонка (race), чи реальний баг. Але тут критичне застереження: фейл автотесту ≠ баг застосунку. Часто падає сам тест — через нестабільний локатор, брак очікування або застарілі дані, — а не продукт. Агент упевнено назве діагноз, і цей діагноз треба перевірити руками, відтворивши флоу. Глибше — у Підтримці тестів і аналізі падінь.

Локатори. Після зміни UI половина селекторів «поламалась» — агент їх лагодить. Ризик у тому, що він схильний хапати найпростіший локатор, який зараз працює: позиційний nth, прив'язку до тексту чи згенерованого класу. Такі локатори крихкі — зламаються на наступному білді. Скеровуй агента до стабільних якорів — ролей і data-testid:

// Крихкий локатор — позиція і згенерований клас
await page.locator('.btn_a1b2c3 >> nth=2').click();

// Стійкий локатор — роль з доступним іменем або тестовий id
await page.getByRole('button', { name: 'Зберегти' }).click();
await page.getByTestId('save-order').click();

Це саме те місце, де твоя експертиза в тест-дизайні незамінна: агент напише робочий селектор, але «робочий сьогодні» і «стабільний» — різні речі.

Типові помилки

Виглядає як «зелений прогін — отже, тести готові», а насправді агент міг послабити асерти або замокати саму перевірку. Зелений тест без осмислених перевірок пройде завжди:

test('оновлення профілю', async ({ page }) => {
  await page.goto('/profile');
  await page.getByRole('button', { name: 'Зберегти' }).click();
  // асертів немає — тест зелений, але нічого не перевіряє
});

Виглядає як «агент сам розбереться в задачі», а насправді розмита постановка дає розмитий результат: агент вгадує критерій готовності й обмеження, і часто вгадує не так.

Виглядає як «auto-accept пришвидшує роботу», а насправді на спільному стенді чи без рев'ю диффу це втрата контролю — швидко отримати неправильне не краще, ніж повільно отримати правильне.

Виглядає як «він знає наш проєкт», а насправді без CLAUDE.md і належного контексту агент вигадує конвенції та посилається на неіснуючі хелпери й селектори.

Виглядає як «план — це формальність, пропущу», а насправді план — найдешевша точка виправлення: тут правиться намір, а не готовий дифф.

Підсумок

Claude Code — це агент у циклі, а не чат: дозволи й дифф — твої головні точки контролю.
Постановка задачі визначає результат — давай критерій готовності, обмеження й конвенції (через CLAUDE.md).
План перед змінами: рев'ю наміру дешевше за рев'ю диффу.
Зелені тести ≠ правильні тести — верифікація асертів лишається за тобою.
Фейл автотесту ≠ баг застосунку: діагноз агента підтверджуй ручним відтворенням.

Що питають на співбесіді

«Чи користуєшся AI-інструментами в роботі? Як саме?» Інтерв'юер перевіряє, чи за словами стоїть конкретний воркфлоу з точками контролю, а не установка «AI все зробить».
«Як ти контролюєш якість AI-згенерованого тесту?» Очікувана відповідь називає рев'ю диффу, обов'язковий прогін і перевірку, що асерти справді щось перевіряють, а не просто «зелено».
«Що робиш, коли агент зробив не те?» Дивляться на практичні важелі: відкотити коміт, уточнити постановку, ганяти в plan-режимі до апруву напрямку.
«Чим агент відрізняється від чат-бота?» Цикл «дія — спостереження — корекція» і наявність інструментів (файли, термінал, тести), а не лише генерація тексту.
Червоний прапорець для інтерв'юера — сліпа довіра до зеленого прогону й невміння пояснити, де саме людина перевіряє роботу агента.

Джерела

Claude Code — офіційна документація, огляд: code.claude.com/docs/en/overview
Claude Code — Common workflows (плани, сесії, PR, subagents, headless): code.claude.com/docs/en/common-workflows
Claude Code — Best practices: code.claude.com/docs/en/best-practices
Playwright — Writing tests (локатори й асерції для QA-сценаріїв): playwright.dev/docs/writing-tests
Ця глава не відповідає окремому розділу силабусу ISTQB CTFL 4.0 (воркфлоу інструмента — поза силабусом). Для ширшого контексту «AI в тестуванні» — силабус ISTQB Certified Tester AI Testing (CT-AI).

Чим термінальний агент на кшталт Claude Code відрізняється від звичайного чат-бота?

Чат повертає текст — далі копіювати й запускати доводиться самому; агент замикає цю петлю сам. У нього є інструменти (tools): читати й правити файли, виконувати команди в оболонці, ганяти тести, працювати з git. Через це він не радить, а діє — і одразу спостерігає наслідок своєї дії: вивід раннера, повідомлення компілятора, готовий дифф. Далі він враховує це спостереження й коригує роботу, тобто крутить цикл «дія — спостереження — корекція», а не видає один статичний блок коду. Для QA це означає виконавця, що сидить прямо в репозиторії автотестів і бачить реальні падіння, а не абстрактного порадника.

Що таке сесія і навіщо її вміти зберігати й відновлювати?

Сесія (session) — це одна безперервна розмова з агентом разом з усім накопиченим контекстом: історія повідомлень плюс усе, що агент за цей час прочитав і змінив. Контекст живе в обмеженому вікні, тож нескінченно нарощувати одну розмову не можна — довгі задачі варто розбивати на підходи. Claude Code вміє зберігати сесію й піднімати її пізніше (claude --continue, claude --resume), щоб одна задача пережила кілька заходів без утрати контексту. Практичний виграш для QA: почав розбір флакі-тесту ввечері, повернувся вранці — агент пам'ятає, на чому спинилися, замість того щоб пояснювати все спочатку.

Що таке дозволи в Claude Code і чому читання не потребує підтвердження, а зміна стану потребує?

Дозволи (permissions) — це запобіжник між агентом і незворотними діями в терміналі. Агент технічно може виконати будь-яку команду, тож саме дозволи стоять між тобою й випадковим видаленням файлів чи пушем не в ту гілку. Читання (перегляд файлів, grep, пошук) стан не змінює й нічого не псує, тому йде без запиту. А от правка файлу, довільна bash-команда чи git push за замовчуванням спершу питають дозволу, бо ціна помилки тут висока. Це і є головна точка контролю: людина санкціонує кожну потенційно небезпечну дію, поки не переведе агента в менш суворий режим свідомо.

Які є режими дозволів і як вони перемикаються?

Режимів три, і вони перемикаються по колу клавішею Shift+Tab. default — агент питає перед кожною зміною стану, це найобережніший режим. acceptEdits — агент авто-приймає правки файлів, але довільні команди все одно виносить на підтвердження. plan — режим лише для читання: агент нічого не змінює взагалі, тільки досліджує код і складає план. У статус-рядку видно активний режим (наприклад, позначку про plan-режим), тож завжди зрозуміло, наскільки агент зараз «розв'язаний». Вибір режиму — це вибір, скільки контролю віддати: на чужому чи проді лишають default, на своїй пісочниці можна попустити віжки.

Що дає plan-режим і чому виправити план дешевше, ніж виправити дифф?

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

З чого складається сильна постановка задачі для агента?

Якість результату майже цілком визначається постановкою, бо на розмиту задачу агент відповідає вгадуванням. Сильна постановка тримається на трьох речах: що саме зробити, критерій готовності (acceptance criteria — за яких умов задачу можна вважати виконаною) і обмеження (яким інструментом користуватися, чого не чіпати). Плюс явна вказівка на потрібні файли — у Claude Code це роблять через @, наприклад @tests/login.spec.ts, щоб агент одразу підтягнув релевантний контекст, а не шукав наосліп. Без критерію готовності агент сам вирішить, що вважати успіхом, і легко вгадає не так — отримаєш красивий, але не той тест. Проста евристика: якщо постановку можна прочитати двома способами, агент вибере не твій.

Навіщо файл CLAUDE.md і що станеться без нього?

CLAUDE.md — це місце, куди виносять постійні конвенції проєкту: house-стиль назв, підхід до локаторів, структуру page object'ів, команди раннера. Агент читає його автоматично на старті сесії, тож ці правила не треба повторювати в кожному промпті. Без нього агент вигадує конвенції на льоту — і вони систематично розходяться з вашими: він може назвати метод не в тому стилі, послатися на неіснуючий хелпер чи вигаданий селектор. Тобто відсутність CLAUDE.md — це не «агент не знає проєкту», а «агент упевнено імпровізує там, де мав дотримуватися правил». Для команди це разова інвестиція, що прибирає цілий клас однакових зауважень на рев'ю.

Опиши цикл «тести → фейли → фікс». Чому саме він відрізняє агента від чата?

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

Головна пастка ітераційного циклу: чому «зелено» не означає «правильно»?

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

Як ти контролюєш якість AI-згенерованого тесту?

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

Чому для QA git — це головна точка контролю, а не побічна деталь?

Claude Code працює з git як звичайний інженер: дивиться статус і дифф, робить гілки й коміти, через gh створює pull request'и. Для QA коміт — це чекпоінт: якщо агент пішов не туди, ти відкочуєшся до попереднього стану замість ручного розгрібання наслідків. Тому дисципліна проста й непорушна: працювати в окремій гілці, а не в основній; читати дифф перед кожним комітом; не пушити у спільну гілку без перегляду; лишати осмислені меседжі, щоб історія читалася. Дифф — це саме те місце, де «агент нагенерував купу коду» перетворюється на «я розумію й свідомо приймаю кожен рядок». Без цієї звички швидкість агента обертається швидким накопиченням коду, який ніхто не переглянув.

Агент полагодив локатори після зміни UI. На що дивитися перед тим, як приймати?

Агент схильний хапати найпростіший локатор, який працює прямо зараз: позиційний nth, прив'язку до видимого тексту чи до згенерованого CSS-класу. Проблема в тому, що «працює сьогодні» й «стабільний» — різні речі: такі локатори кришаться на наступному білді, бо позиція елемента, текст і хеш класу змінюються. Тому дифф локаторів дивлюся прицільно: чи прив'язка йде до стабільного якоря — ролі з доступним іменем або data-testid, — чи до крихкого. Якщо бачу .btn_a1b2c3 >> nth=2, замінюю на getByRole або getByTestId і скеровую агента робити так надалі. Це саме та зона, де експертиза в тест-дизайні незамінна: агент напише робочий селектор, а стійкий — тільки під наглядом.

Агент проаналізував падіння тесту й упевнено назвав діагноз. Чи можна одразу заводити баг?

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

Що робити, коли агент зробив геть не те?

Найпростіший важіль — відкотитися: якщо працювали дисципліновано, є коміт-чекпоінт, до якого повертаєшся замість ручного розгрібання зіпсованого стану. Другий важіль — уточнити постановку: найчастіше «зробив не те» означає, що критерій готовності чи обмеження були розмиті й агент їх довигадав. Третій — ганяти задачу в plan-режимі, поки не зійдетеся на напрямку, і лише тоді пускати до коду. По суті це три різні точки: git відкочує наслідок, чіткіша постановка прибирає причину, а план ловить розбіжність ще до появи диффу. Погана відповідь тут — «перепишу сам»: вона не пояснює, як не наступити на ті самі граблі наступного разу.

Чому не варто вмикати авто-прийняття на спільному чи прод-стенді, і як дозволи задають у CI?

acceptEdits пришвидшує роботу, але прибирає точку контролю саме там, де ціна помилкової дії найвища — на спільному стенді чи проді помилкова команда б'є не тільки по тобі. Швидко отримати неправильне не краще, ніж повільно отримати правильне, тож на чужому середовищі лишають default і читають дифф перед застосуванням. У CI ситуація інша: там агент працює неінтерактивно (headless), клацати підтвердження нікому, тож дозволи задаються конфігурацією заздалегідь — що можна, а що ні, вирішено до запуску, а не в діалозі. Практичне правило: рівень автономії має відповідати ціні помилки в конкретному середовищі, а не зручності. Пісочниця пробачає, спільний стенд — ні.

Три ситуації з робочого дня AQA, де воркфлоу вирішує, чи агент зекономить час, чи згенерує проблему: слабка проти сильної постановки задачі, plan-режим як точка рев'ю наміру, і читання диффу, коли зелений тест бреше. Скрізь — що дивитися й чому.

Кейс 1. Постановка задачі: чому одна фраза дає не той тест

Задача одна — «покрити логін», — а результат залежить від того, як її сформулювали. Порівняймо два промпти до агента, що сидить у репозиторії автотестів.

	Слабка постановка	Сильна постановка
Що зробити	«Зроби тест на логін»	«Додай e2e-тест успішного логіну для форми на `/login`»
Критерій готовності	не заданий	«після сабміту видно дашборд і ім'я користувача в хедері»
Обмеження	немає	«Playwright, стиль наявних тестів, без нових залежностей»
Контекст	агент шукає наосліп	`@tests/auth/login.spec.ts`, `@pages/LoginPage.ts`
Конвенції	вигадає на льоту	взяті з `CLAUDE.md` (локатори через `data-testid`)

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

Що дивитися й чому:

Критерій готовності — це те, що агент перевірятиме асертом. Немає критерію — немає й осмисленого expect; агент лишить тест, який «проходить», бо нічого не стверджує.
@-посилання економлять раунди вгадування. Показавши наявний тест і page object, ви задаєте стиль і патерни асертів, і агент продовжує їх, а не пише з нуля.
Конвенції місце в CLAUDE.md, не в кожному промпті. Одноразовий запис про data-testid і house-стиль назв прибирає цілий клас однакових зауважень на рев'ю.

Кейс 2. Plan-режим: ловимо неправильний намір до появи коду

Задача: «тест перевіряє, що після оплати замовлення переходить у статус paid». Перед тим як пускати агента до коду, перемикаємо його в plan-режим (Shift+Tab, у статус-рядку видно позначку plan) і читаємо запропонований план.

План:
1. Замокати весь бекенд (усі /api/*) фікстурами.
2. Застабити відповідь платіжного шлюзу як success.
3. Клікнути "Оплатити", дочекатися редіректу.
4. Перевірити, що на сторінці видно текст "Оплачено".

Тут видно проблему саме на рівні наміру, ще до єдиного рядка коду. Пункт 1 мокає весь бекенд — тоді перехід у статус paid рахує мок, а не реальна логіка застосунку, і тест зеленітиме, навіть якщо продукт зламано. Правити треба напрямок: підмінити лише зовнішній платіжний шлюз (він недетермінований і платний), а власний бекенд лишити живим. Уточнюємо постановку й переганяємо план — і лише потім даємо апрув.

Уточнення: мокати ТІЛЬКИ зовнішній платіжний шлюз (POST /gateway/charge).
Статус замовлення читати з реального API GET /orders/:id — це і є перевірка.

Що дивитися й чому:

Виправлення в плані коштує один рядок тексту. Той самий недогляд, виловлений уже в диффі, — це відкат коміту й повторний прогін; правити намір на порядок дешевше.
«Замокати весь бекенд» — типовий обхідний шлях. Агент прибирає недетермінованість найгрубішим способом; ваша робота — звузити мок до справді зовнішньої залежності.
Апрув плану = апрув напрямку. Схвалюєте не текст, а рішення «що вважати перевіркою»; для джуна це рев'ю підходу до того, як з'явився код.

Кейс 3. Читання диффу: коли зелений тест бреше

Агент попросили «полагодити впалий тест оновлення профілю». Прогін зелений, але перед комітом читаємо дифф — це справжнє рев'ю. Ось що агент зробив.

 test("оновлення профілю зберігає нове ім'я", async ({ page }) => {
   await page.goto('/profile');
-  await page.getByTestId('name-input').fill('Ірина');
-  await page.getByTestId('save-profile').click();
-  await expect(page.getByTestId('profile-name')).toHaveText('Ірина');
+  await page.getByRole('textbox').nth(1).fill('Ірина');
+  await page.locator('.btn_9f8e').click();
+  // await expect(page.getByTestId('profile-name')).toHaveText('Ірина');
 });

Тест зелений з двох причин, і обидві погані. По-перше, агент закоментував єдиний змістовний асерт — тепер тест лише клікає й нічого не стверджує, тож пройде завжди. По-друге, стійкі локатори data-testid замінено на крихкі: позиційний nth(1) і згенерований клас .btn_9f8e, які зламаються на наступному білді. «Зелено» тут не означає «полагоджено» — означає «перестало падати». Повертаємо асерт і стабільні якорі.

test("оновлення профілю зберігає нове ім'я", async ({ page }) => {
  await page.goto('/profile');
  await page.getByTestId('name-input').fill('Ірина');
  await page.getByTestId('save-profile').click();
  // асерт лишається — саме він робить тест перевіркою, а не кліком
  await expect(page.getByTestId('profile-name')).toHaveText('Ірина');
});

Що дивитися й чому:

Закоментований чи прибраний асерт — перше, що шукати в диффі. Тест без expect зелений завжди; ціль циклу «зелено» штовхає агента саме до цього обхідного шляху.
getByRole('textbox').nth(1) і .btn_9f8e — крихкі за побудовою. Позиція й хеш класу змінюються щобілда; стійкі якорі — роль з доступним іменем або data-testid.
Дифф — це місце, де ти реально приймаєш роботу. Якби довіряли кольору прогону, у сюїт поїхав би тест, який нічого не перевіряє й розсиплеться на першому релізі UI.

Агент, а не чат

Можу пояснити різницю агент vs чат-бот: агент має інструменти (файли, оболонка, тести, git), діє й спостерігає результат, а не лише генерує текст.
Розумію цикл «дія — спостереження — корекція» і чому саме він дозволяє агенту довести зміну до працездатного стану в одній сесії.

Сесія і дозволи

Знаю, що сесія — це розмова разом з накопиченим контекстом, і чому довгі задачі варто розбивати (обмежене вікно контексту).
Можу відновити роботу з місця зупинки через claude --continue / claude --resume.
Розумію, чому читання йде без запиту, а зміна стану (правка файлу, bash, git push) потребує дозволу.
Знаю три режими дозволів default vs acceptEdits vs plan і що Shift+Tab перемикає їх по колу.
Знаю, що в CI агент працює неінтерактивно (headless), тож дозволи задають конфігурацією заздалегідь, а не клацанням.

Постановка задачі та контекст

Можу назвати три складники сильної постановки: що зробити, критерій готовності (acceptance criteria), обмеження.
Знаю, навіщо вказувати файли через @ і чому це підтягує потрібний контекст замість гадання.
Розумію роль CLAUDE.md: постійні конвенції читаються на старті сесії, без нього агент імпровізує й посилається на неіснуючі хелпери.

План перед виконанням

Можу пояснити, що дає plan-режим: агент досліджує й пропонує план, але не чіпає жодного файлу до апруву.
Розумію, чому виправити план дешевше за виправлення диффу: правиться намір, а не готовий результат.

Цикл тести → фейли → фікс

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

Git як точка контролю

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

QA-сценарії та пастки

Розумію інваріант фейл автотесту ≠ баг застосунку: діагноз агента підтверджую ручним відтворенням флоу.
Можу відрізнити крихкий локатор (nth, згенерований клас, прив'язка до тексту) від стійкого (роль, data-testid).
Розумію червоний прапорець для інтерв'юера: сліпа довіра до зеленого прогону й невміння показати, де саме людина перевіряє роботу агента.