Керована реалізація — це короткі контрольовані ітерації
Claude Code не видає готову істину: він пропонує зміни, які потрібно перевірити через diff, тести та інші докази. Керований цикл бере один пункт затвердженого плану, виконує його в обмеженій області й лише потім переходить далі.
Такий підхід зберігає автономність агента, але не дозволяє йому непомітно реалізувати весь issue, додати супутній рефакторинг або змінити контракт без людського checkpoint.
| Крок | Контрольне питання |
|---|---|
| Вибір пункту | Яку одну частину approved plan виконуємо? |
| Обмежений запит | Які файли та наступні кроки дозволені? |
| Зміна | Чи залишився агент у погодженій області? |
| Targeted check | Яку саме поведінку підтверджує перевірка? |
| Diff review | Чи немає сторонніх змін і scope creep? |
| Рішення | Прийняти, уточнити крок або зупинитися? |
Один крок — один намір
- Крок має бути достатньо вузьким для швидкого перегляду.
- Його можна перевірити окремо й за потреби скасувати.
- Крок повʼязаний із конкретною зміною поведінки або структури.
- Контролер, сервіс, mapper, SQL і конфігурацію не слід без потреби обʼєднувати в один запит.
- Якщо потрібен інший файл, Claude спочатку має назвати його та пояснити причину.
Контракт запиту для Claude Code
Явно названі заборони допомагають відрізнити виконання поточного кроку від самостійного розширення задачі. Якщо план не дозволяє зміни в іншій області, запит не повинен мовчки їх санкціонувати.
Plan step: add the empty-cart guard
Allowed files: OrderController and its focused test
Forbidden for now: service refactor, API redesign, unrelated cleanup
Required check: targeted empty-cart test
Report: changed files, diff summary, command, result, open questions
Stop: if another module or shared contract must change Перевірка після кожної ітерації
- Перегляньте список змінених файлів і статистику diff.
- Прочитайте зміни в production-коді та тестах окремо.
- Запустіть перевірку, повʼязану саме з поточним кроком.
- Зіставте результат із пунктом approved plan.
- Прийміть крок, уточніть його або поверніться до плану.
- Зафіксуйте важливе рішення та evidence до переходу далі.
git diff --stat
git diff -- path/to/changed-file
git status --short Stop rules і робота за формальною метою
- Зупиніться, якщо змінено файл поза дозволеною областю.
- Зупиніться, якщо одна перевірка не проходить двічі поспіль без нових доказів.
- Зупиніться, якщо diff складно пояснити одним реченням.
- Зупиніться, якщо Claude додав попутне «покращення».
- Режим роботи до формальної мети доречний лише за чітких file boundaries, автоматичних критеріїв і низької ціни помилки.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush