Робочий процес plan-first і review-first

Plan-first до змін, review-first після них

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

Це особливо важливо для платежів, refund-операцій, баз даних, авторизації та production-конфігурацій.

Приклад Explore → Plan для refund

1. Знайти controller або іншу точку входу.
2. Простежити виклики сервісів і платіжного клієнта.
3. Перевірити наявні тести та сценарій повторної спроби.
4. Оцінити ризик зміни зовнішнього API.
5. Скласти короткий план із послідовністю кроків.
6. Записати ризики та умови, за яких потрібно зупинитися.

1. Додати ідемпотентний захист у RefundService.
2. Передати ідентифікатор до PaymentClient.
3. Створити regression test для повторної спроби.

Ризики: зміна public API та вплив на retry-логіку.

Implement невеликими кроками

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

git diff --stat
git diff

Verify і Review відповідають на різні питання

• Verify перевіряє тести, команди, логи та очікувану поведінку.
• Review перевіряє scope, зайві файли, public contract і зрозумілість правки.
• Зелені тести не є автоматичним дозволом на merge.

Коли потрібен повний процес

• незнайома частина системи;
• зміна кількох файлів;
• auth, payments, database або config;
• production-ризик або нечіткий scope;
• рефакторинг чи сумісність із зовнішнім API.