Керована реалізація — це короткі контрольовані ітерації

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

Такий підхід зберігає автономність агента, але не дозволяє йому непомітно реалізувати весь issue, додати супутній рефакторинг або змінити контракт без людського checkpoint.

КрокКонтрольне питання
Вибір пунктуЯку одну частину approved plan виконуємо?
Обмежений запитЯкі файли та наступні кроки дозволені?
ЗмінаЧи залишився агент у погодженій області?
Targeted checkЯку саме поведінку підтверджує перевірка?
Diff reviewЧи немає сторонніх змін і scope creep?
РішенняПрийняти, уточнити крок або зупинитися?

Один крок — один намір

  • Крок має бути достатньо вузьким для швидкого перегляду.
  • Його можна перевірити окремо й за потреби скасувати.
  • Крок повʼязаний із конкретною зміною поведінки або структури.
  • Контролер, сервіс, mapper, SQL і конфігурацію не слід без потреби обʼєднувати в один запит.
  • Якщо потрібен інший файл, Claude спочатку має назвати його та пояснити причину.

Контракт запиту для Claude Code

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

Приклад обмеженого implementation prompt
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

Перевірка після кожної ітерації

  1. Перегляньте список змінених файлів і статистику diff.
  2. Прочитайте зміни в production-коді та тестах окремо.
  3. Запустіть перевірку, повʼязану саме з поточним кроком.
  4. Зіставте результат із пунктом approved plan.
  5. Прийміть крок, уточніть його або поверніться до плану.
  6. Зафіксуйте важливе рішення та evidence до переходу далі.
Початкові команди для огляду зміни
git diff --stat
git diff -- path/to/changed-file
git status --short

Stop rules і робота за формальною метою

  • Зупиніться, якщо змінено файл поза дозволеною областю.
  • Зупиніться, якщо одна перевірка не проходить двічі поспіль без нових доказів.
  • Зупиніться, якщо diff складно пояснити одним реченням.
  • Зупиніться, якщо Claude додав попутне «покращення».
  • Режим роботи до формальної мети доречний лише за чітких file boundaries, автоматичних критеріїв і низької ціни помилки.

Канонічне джерело уроку · JavaRush

Відкрити матеріал JavaRush