# Агент сломал то, что работало: как откатиться назад

У агента нет кнопки «отменить»: он меняет файлы на диске. Разбираю точки сохранения, порядок отката простыми фразами и то, чего откат не спасёт.

URL: https://posts.danashkin.ru/guides/kak-otkatit-izmeneniya-agenta
Обновлено: 2026-08-26

---

## Коротко

**Главное**

- Кнопки «отменить всё» у агента нет: он меняет файлы на диске, а не текст в окне. Вернуть состояние можно только тем способом, который ты подготовил заранее.
- Точка сохранения - это снимок всего проекта на конкретный момент. Она делается одной фразой и стоит секунду, а спасает часы работы.
- Фиксировать надо не по завершении проекта, а каждый раз, когда есть состояние, в которое не стыдно вернуться. Обычно это несколько раз за сеанс.
- Откат делается словами: «покажи, что изменилось с последней фиксации» и «верни файлы к ней». Изучать команды для этого не нужно.
- Точка сохранения не спасает данные в базе, файлы клиентов и действия во внешних сервисах. Для них нужна отдельная копия, и об этом думают до, а не после.

## Почему у агента нет кнопки «отменить»?

**Главное**

Агент правит файлы на диске и иногда запускает команды, а не пишет текст в редакторе. Отмена в привычном смысле тут не работает: изменения уже применены к проекту. Единственный надёжный способ вернуться - иметь сохранённое состояние, к которому можно откатиться.

Первое, что удивляет непрограммиста: агент не показывает черновик, а сразу делает. Он создаёт файлы, переписывает существующие, устанавливает нужные ему компоненты, запускает проект.

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

Отсюда правило, которое я даю на первых занятиях: **страховка ставится до работы, а не после аварии.** Это не занудство, а разница между «потерял двадцать минут» и «потерял два дня».

Сама авария при этом не редкость и не признак плохого агента. Он перебирает варианты, и часть из них оказывается хуже предыдущего.

Три типовые аварии, которые я вижу чаще всего:

- **Улучшил и сломал.** Просьба «сделай красивее» превращается в переписанную страницу, где заодно отвалилась работавшая форма.
- **Обновил зависимости.** Агент поставил свежую версию какого-то компонента, и проект перестал запускаться целиком. Внешне это выглядит как «вчера работало, сегодня нет», хотя ты ничего не менял в своей части.
- **Спрятал ошибку вместо починки.** Сообщение об ошибке исчезло с экрана, потому что агент убрал проверку, а не причину. Самый неприятный случай: выглядит как успех, всплывает через неделю на живых пользователях.

## Точка сохранения простыми словами

**Главное**

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

Аналогия с игрой работает лучше всего. Ты проходишь сложный уровень, сохраняешься перед боссом, и если что-то пошло не так, загружаешься.

Разница только в том, что сохранёнка в проекте называется по-другому и хранит не позицию персонажа, а состояние всех файлов сразу: код, тексты, настройки, структуру папок.

**Как выглядит фиксация на практике**

Ты пишешь агенту: «зафиксируй текущее состояние с описанием: работает форма заявки, добавлена страница цен». Он делает снимок и подписывает его. Всё, это заняло пять секунд.

Термин лишним не будет, если ты собираешься читать документацию: этот снимок называют коммитом, а всю систему таких снимков - контролем версий. Другие слова из этой области я собрал в [словаре вайбкодинга](/guides/slovar-vibecodinga-bez-zhargona).

## Когда фиксировать состояние?

**Главное**

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

На занятиях этот вопрос звучит почти дословно так: «мы фиксируем каждый раз, когда я на сегодня задачу закончила, но проект-то не закончен?» Отвечаю: да, именно так. Фиксация не означает готовность продукта, она означает «сюда можно вернуться».

1. **В начале работы**

   Проект в известном состоянии, всё работает. Первая точка - опора для всего сеанса.

2. **Перед рискованной правкой**

   Меняешь структуру, ставишь новую библиотеку, переделываешь то, что уже работает. Сначала снимок.

3. **После каждого рабочего результата**

   Заработала функция - зафиксируй. Не жди, пока накопится «достойный объём».

4. **В конце сеанса**

   Даже если задача не доделана. Незаконченное состояние тоже стоит сохранить, иначе назавтра начнёшь с непонятного.

Один нюанс, который стоит проговорить агенту сразу: **фиксируем осознанно, а не всё подряд.** Иногда в снимок попадают временные файлы, выгрузки с данными или файл с паролями, и они остаются в истории надолго. Проси показать список того, что войдёт в снимок, если работаешь с чувствительными материалами.

## Как откатиться, если сломалось?

**Главное**

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

Порядок действий:

1. **Остановись.** Не проси «почини» в панике: каждая новая правка усложняет возврат.
2. **Спроси, что изменилось.** «Покажи списком, что поменялось с последней зафиксированной точки, коротко и по-русски».
3. **Реши, что откатывать.** Иногда достаточно одного файла, иногда нужен весь проект.
4. **Попроси вернуть.** «Верни проект к последней точке сохранения, ничего не дописывая».
5. **Проверь руками.** Открой, нажми, пройди сценарий. Отсутствие ошибок на экране агента ещё не значит, что всё работает: как это принимать, разбирал в материале про [приёмку работы агента](/guides/kak-proveryat-ai-kod-bez-teh-bekgraunda).
6. **Зафиксируй заново** и только потом продолжай.

**Если фиксаций не было вообще**

Шансы всё же есть. По порядку: история чата с агентом (там часто лежит прежняя версия файла целиком), корзина операционной системы, встроенная история версий файлов на компьютере, копия в облаке. Это лотерея, поэтому первое, что стоит сделать после восстановления, - завести привычку фиксировать.

## Чего откат не спасёт?

**Главное**

Точка сохранения хранит файлы проекта, но не данные в базе, не письма и сообщения, отправленные наружу, и не изменения в чужих сервисах. Для данных нужна отдельная резервная копия, а для внешних действий - подтверждение перед выполнением.

Это место, где люди обжигаются второй раз, уже освоив фиксацию.

**База данных.** Снимок проекта не хранит содержимое базы. Если агент почистил таблицу, откат кода её не вернёт. На одном из разборов участник сформулировал это точно: данные можно случайно стереть, поэтому нужна база с резервной копией. Копию базы делают отдельно и по расписанию.

**Файлы вне проекта.** Документы на рабочем столе, выгрузки, чужие папки. Если агенту дали доступ шире, чем к проекту, страховка тоже нужна шире.

**Внешние действия.** Отправленное письмо, опубликованный пост, платёж, запись в чужой системе. Их не отменить откатом. Единственная защита - подтверждение перед выполнением.

| Что меняется | Чем спасаемся | Когда готовим |
|---|---|---|
| Файлы проекта | точки сохранения | перед каждой рискованной правкой |
| Данные в базе | резервная копия базы | до первого запуска на реальных данных |
| Документы вне проекта | ограничение доступа + копия | до выдачи доступа |
| Действия во внешних сервисах | подтверждение вручную | всегда |

Про то, где вообще проходит граница между «поиграться» и «работает на живых данных», подробно писал в материале про [деплой прототипа и персональные данные](/guides/prototip-gotov-chto-dalshe-deploy-152fz).

## Три привычки, чтобы не доводить до отката

**Главное**

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

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

Вторая - **одна правка за раз**. Соблазн попросить пять улучшений одной фразой велик, но когда что-то ломается, ты не знаешь, какое из пяти виновато. С одной правкой причина очевидна.

Третья - **не соглашаться вслепую**. Режим, в котором [ИИ-агент](/concepts/ai-agent) делает всё без подтверждений, экономит время и увеличивает цену ошибки. Держать его включённым разумно на песочнице и опасно на проекте с живыми данными.

Четвёртая, менее очевидная: не наводить порядок в папке проекта руками. Как это ломает работу агента и что делать вместо, разбирал в материале про [гигиену рабочей папки](/guides/gigiena-rabochey-papki-agenta).

## Частые вопросы

**Главное**

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

### Частые вопросы

**Сколько точек сохранения хранить?**

Все. Они почти ничего не весят и хранятся историей, а не копиями папок. Удалять их специально не нужно.

**Можно вернуться не на одну точку назад, а на пять?**

Да. Скажи агенту, к какому состоянию хочешь вернуться: «верни к точке, где ещё работала форма оплаты». Он найдёт её по описанию.

**Нужен ли отдельный сервис для хранения истории?**

Для работы на своём компьютере не обязателен. Но копия истории в облачном хранилище кода спасает, если с ноутбуком что-то случится.

**Агент фиксирует сам, без просьбы. Это нормально?**

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

## Главный вывод

**Главное**

Откат существует только там, где заранее сделан снимок. Точка сохранения ставится одной фразой, откат делается тремя, и оба действия не требуют технических знаний. Всё остальное - данные, письма, внешние сервисы - защищается отдельно и до, а не после.

Правило, которое дешевле всего выучить заранее: работа с агентом безопасна ровно настолько, насколько ты подготовил возврат.

Практический минимум выглядит так: снимок в начале сеанса, снимок после каждого рабочего результата, план до рискованных правок и отдельная копия данных. Четыре привычки, каждая из которых стоит секунды.

Сегодня же спроси агента, когда в твоём проекте была последняя точка сохранения. Если ответ «её нет», ты только что нашёл главный риск ближайшей недели.

### Источники

- [Pro Git - книга о контроле версий: снимки состояния, история и возврат, русский перевод](https://git-scm.com/book/ru/v2)
- [GitHub Docs - что такое система контроля версий простыми словами, русская версия](https://docs.github.com/ru/get-started/using-git/about-git)
- [Version control - обзорная статья о контроле версий, Википедия](https://en.wikipedia.org/wiki/Version_control)
- [PostgreSQL - документация о резервном копировании базы данных](https://www.postgresql.org/docs/current/backup.html)
- [Apple - резервное копирование данных Mac с помощью Time Machine](https://support.apple.com/ru-ru/104984)
- [Claude Code - официальная документация: что агент делает с файлами и когда спрашивает подтверждение](https://code.claude.com/docs/en/overview)