# Claude code review в 2026: как проверить diff до правки

> Claude Code не обязан быть автопилотом. Сначала попроси агента изучить задачу, показать план, список файлов и предполагаемый diff, а уже потом разрешай изменения.

Источник: https://vibeceh.ru/guides/claude-code-prosit-agenta-pokazat-diff-do-pravki
Автор: Сергей Мазур · опубликовано 2026-08-18

Если ты ищешь `claude code review`, тебе нужен контроль до изменения файлов. Попроси Claude Code как ИИ-агент сначала изучить задачу, показать план, назвать файлы и описать предполагаемый diff.

Проверь границы работы и разреши только понятные изменения. После правки сравни обещанный результат с реальным через Git.

## Что такое diff и зачем просить Claude Code показать его до правки?

Diff обычно используют для просмотра различий между версиями. В `plan` агент предлагает план без изменения исходников; в других режимах показанный diff не следует автоматически считать доказательством, что запись ещё не произошла. Claude сначала предлагает действие, а ты отдельно проверяешь смысл, список файлов и соответствие задаче.

Claude Code работает с файлами, тестами, командной строкой и GitHub. Поэтому запрос «сделай страницу» может закончиться несколькими правками: изменениями в компонентах, стилях, настройках и тестах.

Я разделяю здесь две вещи:

- **Предложение агента.** Claude изучил задачу и подготовил план или изменение.
- **Принятый результат.** Правка действительно записана в файлы проекта.

Diff нужен на границе между ними. Diff и список файлов вместе отвечают на два разных вопроса: «Что изменится?» и «Где именно это произойдёт?» Подробнее о безопасном допуске агента к проекту читай в [инструкции по доступу Claude Code](/guides/claude-code-bezopasnyy-dopusk-agenta-k-proektu).

Peter Bloem разделяет работу с кодом на выполнение и проверку в статье [AI coding without the vibes](https://peterbloem.nl/blog/craft-coding).

Я бы строил работу так:

1. Сначала дай задачу.
2. Попроси изучить проект без правок.
3. Получи план и список файлов.
4. Попроси показать предполагаемый diff.
5. Проверь каждое существенное изменение.
6. Подтверди только то, что понимаешь.
7. После записи снова посмотри общий diff.

Зелёные тесты здесь не заменяют ревью. Они проверяют только те сценарии, которые в них заложены. Агент всё ещё может изменить лишний файл, удалить нужную логику или решить не ту задачу.

## Как настроить Claude Code, чтобы он не менял файлы сразу?

В документации Claude Code режим `default` запрашивает разрешение перед изменениями, а `plan` предназначен для предварительного изучения. Название `acceptEdits` встречается в описаниях permission mode, но доступные режимы и их поведение зависят от версии, поэтому перед работой проверь видимый статус интерфейса.

![Кот сравнивает режимы Claude Code и поднимает лапу у карточки plan.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-code-prosit-agenta-pokazat-diff-do-pravki/kadr-1.webp)

У Claude Code есть режимы контроля, которые полезно сравнить через claude code settings:

| Режим | Что делает | Когда использовать | Риск |
| --- | --- | --- | --- |
| `default` | Запрашивает разрешение перед редактированием файлов и большинством команд | Для ручного контроля изменений | Можно начать автоматически подтверждать частые запросы |
| `plan` | Изучает проект и предлагает план без перехода к правкам | Для предварительного изучения задачи | План не показывает фактическое содержимое записанного изменения |
| `acceptEdits` | Автоматически принимает изменения файлов | Только когда область и последствия уже понятны | Легко пропустить лишний файл до проверки через Git |

Plan Mode нужен перед diff. В отдельном разборе [Plan Mode в Claude Code](/guides/plan-mode-splanirovat-ispravlenie-ne-lomaya-proekt) показано, как он отделяет исследование от редактирования. Он показывает намерение: какие части проекта агент собирается трогать и в каком порядке. Diff показывает уже конкретное содержимое изменения.

Сначала проверь общую стратегию. Если задача про цвет кнопки, а в плане появились маршруты, база данных и авторизация, остановись. Проблема возникла не в строках. Claude неправильно понял границы.

После плана можно попросить предполагаемый diff. Не выдавай ответ «план хороший» за разрешение. Я бы прямо написал: «План принят. Теперь покажи ожидаемые изменения и дождись отдельного подтверждения». Если нужен практический разбор такой схемы, пройди практикум по вайб-кодингу, где работу с агентом разбирают маленькими проверяемыми шагами.

## Как записать правило «сначала покажи изменения» в CLAUDE.md?

В `CLAUDE.md` можно закрепить постоянную инструкцию проекта: перед правкой назвать файлы, описать план, показать ожидаемые изменения и ждать подтверждения. Точный синтаксис для такого запрета в собранной фактуре не подтверждён, поэтому воспринимай шаблон ниже как текст правила, без подтверждённой настройки режима.

Файл [`CLAUDE.md`](/guides/claude-md-udalit-ili-perepisat) передаёт Claude постоянные правила проекта, которые он учитывает при работе с кодом. Это удобное место для постоянного порядка действий. Не придётся каждый раз заново объяснять, что сначала нужен план, а потом правка.

Сделай правило коротким: длинный свод запретов агент начнёт выполнять выборочно, поэтому оставь только порядок проверки и границы изменений. В основу можно положить такую заготовку:

Эта инструкция задаёт ожидание, но не превращает агента в механический шлюз. Если интерфейс уже работает в `acceptEdits`, текстовое правило не заменит настройку режима. Поэтому проверяй и файл инструкций, и видимый статус разрешений.

## Как запретить Claude Code менять файлы без разрешения?

В обычном permission-based режиме Claude Code обычно читает проект, но спрашивает разрешение перед изменением файлов и запуском команд. Окно подтверждения только даёт возможность остановить действие. Оно не заменяет чтение diff: перед ответом «разрешить» проверь файлы, строки, секреты и побочные эффекты.

Базовая модель Claude Code по умолчанию консервативная: чтение доступно, изменения требуют разрешения.

В инженерной статье Anthropic David Dworken и Oliver Weller-Davies пишут, что Claude Code использует модель разрешений: по умолчанию он работает в режиме чтения и запрашивает разрешение перед изменением файлов или запуском команд. [Источник: Beyond permission prompts: making Claude Code more secure and autonomous](https://www.anthropic.com/engineering/claude-code-sandboxing)

Запрос разрешения не равен ревью. Если агент показал десять мелких действий подряд, легко начать нажимать `approve` автоматически. Anthropic отдельно называет это approval fatigue, усталостью от подтверждений.

Проверяй перед каждым существенным действием:

1. Тот ли файл меняется.
2. Относится ли изменение к текущей задаче.
3. Нет ли удаления существующей логики.
4. Не появились ли секреты, токены или `.env`.
5. Не запускается ли команда с опасным побочным эффектом.
6. Понимаешь ли ты, что произойдёт после подтверждения.

Claude может попросить разрешение на правильное техническое действие, которое решает не ту задачу. Сначала прочитай план и diff, потом подтверждай действие. Автоматическое разрешение не отменяет ручной review.

Sandbox тоже не отвечает на вопрос, правильно ли Claude понял задачу. В [разборе безопасного допуска Claude Code к проекту](/guides/claude-code-bezopasnyy-dopusk-agenta-k-proektu) разобраны технические границы доступа. Ошибка внутри разрешённой области всё равно останется ошибкой.

## Как ограничить область файлов, которые может менять агент?

Перед началом назови цель, разрешённые файлы и запреты. Чем уже область задачи, тем проще заметить лишнюю правку в списке файлов и diff. Sandbox задаёт технические границы, но не проверяет понимание задачи. Для широкой работы добавь промежуточные проверки и возможность отката через Git.

Не отправляй агенту расплывчатую просьбу вроде «приведи проект в порядок». Для новичка такая формулировка почти приглашает к перестройке половины проекта.

Конкретная формулировка выглядит так:

- задача: добавить подпись под кнопкой;
- можно менять: `src/components/PriceCard.tsx`, `src/styles/pricing.css`;
- нельзя менять: маршруты, базу данных, авторизацию, зависимости;
- результат: одна подпись на экране тарифов;
- проверка: показать план, список файлов и diff до записи.

Если Claude просит добавить третий файл, которого не было в плане, не соглашайся автоматически. Спроси, зачем он нужен. Иногда новый файл действительно необходим. Объяснение должно появиться до принятия, до любых последствий.

Широкую задачу разбивай на смысловые блоки:

1. Изучить текущий экран.
2. Изменить компонент.
3. Проверить отображение.
4. Отдельно изменить стили.
5. Снова проверить diff.

Так проще вернуть один шаг, чем искать ошибку в огромном результате. Checkpoint помогает откатить правки Claude, но не покрывает ручные изменения и bash-команды. Поэтому я бы всё равно держал работу под Git.

На практикуме мы руками собираем именно такую связку: формулируем узкую задачу для ИИ-агента, ограничиваем область файлов, читаем diff и принимаем изменения небольшими порциями. В результате у тебя остаётся понятная точка проверки после каждого шага, а не один большой непроверенный результат.

## Как по шагам попросить Claude Code показать план и diff?

Начни с ручного режима и отдельного запроса на изучение без правок. Получи план, список файлов и ожидаемый diff, затем сравни его с общим `git diff`. Подтверждай только понятные изменения. После записи запусти подходящие тесты, проверь итоговый diff и убедись, что агент не вышел за согласованные границы.

![Сиба-ину одобряет последовательность проверки режима, плана и итогового diff.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-code-prosit-agenta-pokazat-diff-do-pravki/kadr-2.webp)

Убедись, что auto-accept выключен и интерфейс показывает ручное подтверждение. Если статус непонятен, не поручай агенту большую задачу.

Проверь также состояние рабочей папки:

   ```bash
   git status
   ```

Не начинай работу вслепую, если там уже есть ручные изменения и непонятен Контекст рабочей папки. Фраза claude code context может встретиться в поиске, но это не название штатной команды. Иначе потом будет трудно отделить результат Claude от своей работы.

Напиши, что сейчас нельзя менять файлы, запускать команды с побочными эффектами и устанавливать зависимости.

   

Сверь ответ с исходной задачей. В списке должны быть конкретные пути, вместо расплывчатых формулировок вроде «несколько компонентов» или «конфигурация проекта».

Если агент включил в план базу данных, авторизацию или новые зависимости для простой подписи, задай вопрос до следующего шага. Такой порядок полезен и для сценария claude code tasks: план проверяет общую стратегию, вместе с тем качество каждой строки требует отдельной проверки.

После принятия плана попроси описать предполагаемые изменения по каждому согласованному файлу и дождаться отдельного разрешения на запись.

   

Это текстовый запрос к агенту. Универсальной Git-командой он не служит. Я не выдаю его за подтверждённую команду Claude Code, которая строит полный diff до записи.

Если изменения уже появились, используй claude code commands как поисковую фразу для этого сценария: посмотри список файлов и содержимое diff в терминале.

   ```bash
   git status --short
   git diff
   ```

Проверяй новые файлы отдельно через `git status --short` и список в Source Control редактора, потому что обычный вызов `git diff` предназначен для diff уже отслеживаемого состояния.

Разреши только тот шаг, который совпадает с планом и diff. Если появился неожиданный файл, лишняя зависимость или удаление, останови действие и попроси объяснение.

Проверь, можешь ли ты пересказать подтверждаемое изменение своими словами. Формулировка «агент сказал, что так правильно» для проверки не подходит.

Запусти подходящие тесты или проверку сборки, а затем снова посмотри `git status` и `git diff`.

   ```bash
   git status --short
   git diff
   ```

Зелёный результат тестов подтверждает только проверенные сценарии. Он не доказывает, что изменились именно согласованные файлы, что в них нет лишней логики и что лишний Токен не увеличил объём проверки.

## Что ломается, когда Claude Code меняет несколько файлов сразу?

Multi-file diff плохо подходит для принятия крупной задачи одним подтверждением. Сначала проверь полный список файлов и общий смысл, затем разбери изменения по смысловым блокам. Если diff стал слишком большим для внимательного чтения, остановись, вернись к последнему понятному состоянию и раздели задачу на маленькие шаги.

![Мужчина закрывает лицо ладонью перед карточками большого списка файлов.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-code-prosit-agenta-pokazat-diff-do-pravki/kadr-3.webp)

В одном файле inline diff обычно читается нормально. Когда Claude меняет несколько файлов, просмотр распадается между терминалом, редактором и Git. Принять часть изменений становится трудно.

Первый фильтр - список файлов: он быстрее строк отвечает на вопрос, агент всё ещё решает исходную задачу или уже перестраивает проект.

Дальше читай diff в два прохода:

1. Сначала общий масштаб: файлы, добавленные зависимости, конфигурация, удаления.
2. Потом смысловые блоки: компонент, стили, данные, тесты.

Большой diff теряет практическую проверяемость: пользователь может технически открыть его, но это не значит, что он внимательно прочитает все изменения. Усталость превращает ревью в прокрутку.

Я бы не принимал задачу, если не могу объяснить назначение каждой изменённой группы строк. Разбей работу по функции или модулю и используй claude code tools только для тех проверок, которые относятся к задаче. После каждого блока проверь diff и только потом переходи дальше.

Тесты запускай в конце каждого небольшого шага: они нужны, вместе с тем зелёный статус не заменяет проверку области изменения. Агент мог пройти тесты и одновременно добавить лишний маршрут или изменить конфигурацию.

## Что делать, если auto-accept не выключается или общий diff не виден?

Сначала проверь видимый статус режима, затем не давай Claude большую задачу при неясных настройках. Выполни `git status`, потом `git diff`, отдельно проверь новые файлы и ручные изменения. Если правишь предложенный diff вручную, снова сравни итоговый файл: исходное предложение Claude может перезаписать ручную корректировку.

В [Issue #2372 Claude Code](https://github.com/anthropics/claude-code/issues/2372) пользователь сообщил, что после команды переключения интерфейс продолжал показывать автоматическое принятие. Перезапуск в описанном сценарии тоже не вернул ожидаемый режим.

Действуй по запасному маршруту:

1. Посмотри на явный статус режима в интерфейсе.
2. Не запускай крупную задачу, пока статус неясен.
3. Проверь рабочую папку через `git status --short`.
4. Посмотри содержимое через `git diff`.
5. Отдельно найди новые файлы.
6. Повтори проверку после первого изменения.

```bash
git status --short
git diff
git diff --stat
```

`git diff` показывает изменения отслеживаемых файлов. Новый файл может остаться за пределами этого вывода, пока Git его не отслеживает. Смотри такие файлы в Source Control или открывай их отдельно.

В [Issue #8224 Claude Code](https://github.com/anthropics/claude-code/issues/8224) пользователь сообщил о сценарии, в котором ручная правка предложения Claude в diff editor исчезала, а записывался исходный вариант агента. После такой правки проверь содержимое файла и итоговый `git diff`. Одного экрана первоначального preview недостаточно.

Если общего diff в Claude Code нет, отсутствие preview само по себе ничего не доказывает. Для нескольких файлов обязательна проверка через Git. Если и там нет ожидаемого результата, проверь неотслеживаемые файлы и ручные изменения в редакторе.

## Вопросы и ответы

Сначала попроси Claude изучить задачу без изменения файлов, описать план, назвать конкретные файлы и показать предполагаемые изменения. После этого проверь общий `git diff` и только затем дай отдельное разрешение на запись. Точный универсальный запрос зависит от интерфейса, поэтому текстовая инструкция должна дополнять режим разрешений.

Да. Сначала передай задачу в режиме `plan` или обычным текстовым запросом с прямым запретом на правки. Получи общую стратегию, список файлов и ожидаемый результат. Если план совпадает с задачей, попроси показать изменения и только потом разреши конкретный шаг.

Claude Code работает с файлами, тестами, командной строкой и GitHub. Для контроля правок в сценарии `claude code tools` полезны Plan Mode, inline diff, checkpoints и Git-команды. Plan Mode проверяет намерение, inline diff показывает строки, checkpoint помогает откатить изменения Claude, а `git status` и `git diff` показывают фактическое состояние рабочей папки.

Для ручного контроля используй `default`: Claude спрашивает разрешение перед изменениями. `plan` нужен для предварительного изучения и общей стратегии. `acceptEdits` автоматически принимает изменения файлов, поэтому при незнакомой задаче он повышает риск пропустить лишнюю правку. После любого режима всё равно проверяй итоговый diff.

Оставь permission-based режим и не включай auto-accept для первого прохода. Перед началом проверь claude code settings и видимый статус режима. Если он неясен или переключение не сработало, не поручай агенту большую задачу. Выполняй `git status --short` и `git diff` до и после первого изменения.

Для списка изменённых и новых файлов в сценарии claude code commands используй `git status --short`. Содержимое изменений отслеживаемых файлов смотри через `git diff`. Команда `git diff --stat` даёт краткий масштаб правки. Новые файлы дополнительно проверяй через Source Control или открывай отдельно, потому что обычный `git diff` может их не показать.

Запиши короткую инструкцию: сначала изучить задачу, описать план, назвать разрешённые файлы, перечислить запреты, показать ожидаемые изменения и ждать подтверждения. После правки добавь требование показать итоговый diff. Это постоянное правило проекта, но оно не заменяет настройку разрешений и проверку Git.

Назови цель, разрешённые файлы и то, что менять нельзя. Для каждой задачи укажи ожидаемый результат и попроси сообщить о необходимости нового файла до правки. Если список изменился, останови работу и выясни причину. Узкая область снижает риск лишних изменений, но не проверяет правильность понимания задачи.

Проверь три уровня в сценарии claude code context: общий план, список файлов и строки diff. Сначала убедись, что агент выбрал правильную стратегию. Потом найди неожиданные файлы, удаления, зависимости, настройки и секреты. После записи запусти подходящие тесты и снова посмотри `git diff`. Не подтверждай изменение, которое не можешь объяснить.

Отсутствие preview не означает отсутствие правок. Выполни `git status --short`, затем `git diff`, отдельно проверь новые файлы и Source Control. Если auto-accept включён или его статус неясен, не поручай агенту крупную задачу. После ручной правки diff обязательно сравни фактический файл с ожидаемым результатом.

- [AI coding without the vibes](https://peterbloem.nl/blog/craft-coding)
- [Choose a permission mode - Claude Code Docs](https://code.claude.com/docs/en/permission-modes)
- [Beyond permission prompts: making Claude Code more secure and autonomous](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [Enabling Claude Code to work more autonomously](https://www.anthropic.com/news/enabling-claude-code-to-work-more-autonomously)
- [Claude 3.7 Sonnet and Claude Code](https://www.anthropic.com/news/claude-3-7-sonnet)
- [How we built Claude Code auto mode: a safer way to skip permissions](https://www.anthropic.com/engineering/claude-code-auto-mode)
- [How Anthropic teams use Claude Code](https://claude.com/blog/how-anthropic-teams-use-claude-code)
- [Cannot toggle auto-accept edits](https://github.com/anthropics/claude-code/issues/2372)
- [Manual changes are discarded in diff editor](https://github.com/anthropics/claude-code/issues/8224)
- [How do I review multi file changes?](https://www.reddit.com/r/ClaudeCode/comments/1rbddmb/how_do_i_review_multi_file_changes/)
- [Does Claude Code not show the diff of its edits?](https://www.reddit.com/r/ClaudeAI/comments/1vqgwqf/does_claude_code_not_show_the_diff_of_its_edits/)