# Как починить проект после вайб-кодинга: 4 этапа от папки до коммита

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

Источник: https://vibeceh.ru/guides/vajb-koding-chinim-razvalivshijsya-proekt
Автор: Сергей Мазур · опубликовано 2026-08-06

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

## Что такое вайб-кодинг?

[Вайб-кодинг](/concepts/vajb-koding) - это работа, где ты описываешь желаемый результат обычным языком, а ИИ берёт на себя детали реализации. Он читает файлы, меняет код, запускает команды и проверяет результат. От тебя всё равно нужны контекст, ограничения и понятный критерий готовности. Одна фраза «сделай приложение» не заменяет план работы.

Ты не обязан сначала становиться программистом. Можно начать с задачи, которую ты понимаешь по смыслу: добавить форму, изменить страницу, собрать каталог. Ты описываешь, что должно происходить для человека на экране. ИИ подбирает файлы и технические изменения. Путь от пустой папки до первой страницы я разбираю в статье «[Вайб-кодинг с нуля](/guides/vajb-koding-s-nulya)».

Anthropic описывает этот подход так:

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

В Claude Code работа не заканчивается на генерации. Инструмент проходит три фазы: собирает контекст, действует и проверяет результат. Эти фазы могут смешиваться, но сама логика полезна: сначала понять состояние проекта, потом менять, затем проверять.

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

Для первой задачи держи простую рамку:

1. опиши результат глазами пользователя;
2. назови ограничения;
3. попроси сначала изучить проект;
4. согласуй небольшой план;
5. заранее скажи, чем проверять готовность.

## Почему проект после генерации ломается?

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

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

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

Для запроса «почему вайб-кодинг» ответ часто находится в первом шаге: агенту не дали контекст и план. Anthropic прямо советует разделять исследование, планирование и реализацию, чтобы не решать не ту проблему.

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

Есть четыре типовые причины:

| Причина | В чём проблема |
|---|---|
| **Неверная картина проекта** | Агент работает не с той папкой, веткой или группой файлов |
| **Слишком большой запрос** | Несколько функций меняются одновременно, и ошибку трудно привязать к конкретному действию |
| **Нет проверки** | Агент объявляет задачу готовой после изменения файлов, но не получает проверяемый результат |
| **Внешняя зависимость** | Проект требует SSO, API, секреты или учётные данные, которых нет локально |

Перед сложной задачей отправь сначала такой запрос:

## Какие проблемы бывают у проекта после вайб-кодинга?

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

Запрос «вайб-кодинг примеры» полезно разбирать по условиям запуска. Репозиторий Cleanlab Office Presence Dashboard показывает, как приложение может быть собрано за несколько часов, но для рабочего результата требует Google SSO, Forkable API, секреты и учётные данные. Локального запуска без этих зависимостей недостаточно.

Есть и более простой тип проекта. YAAL собирает сайты из подборок GitHub Awesome Lists. Данные лежат в Markdown-файле, а генератор строит страницу. Такое разделение проще для первой проверки: отдельно смотришь исходные данные, отдельно интерфейс и генератор.

Вот как выглядит поломка на практике:

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

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

Если приложение требует внешние сервисы, SSO, API, секреты или учётные данные, локальный запуск не доказывает готовность. Сначала зафиксируй зависимости, затем проверь сценарий, ради которого проект создавался.

Попроси ИИ отделить интерфейс от данных:

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

## Сколько времени и денег занимает первый прототип?

Первый прототип URL-shortener был собран за 4 вечерних часа. Около 30 минут из этого времени ушло на подготовку спецификации. Оценка стоимости сессии составила $2-4. Это ориентир для сборки прототипа. Он не обещает, что уже сломанный проект получится восстановить за такое же время.

В [разборе одной сессии](https://www.reddit.com/r/ClaudeAI/comments/1reh0lb/i_tracked_30_coding_sessions_i_redo_tasks_from/) есть только оценка первой сборки. Точной длительности аварийного ремонта нет. Я не буду переносить цифру 4 часа на ситуацию, где агент уже изменил много файлов и оставил проект в непонятном состоянии.

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

Стоимость сессии оценили в $2-4. Сюда нельзя автоматически добавлять стоимость внешних API, секретов, SSO, хостинга или времени на ручную проверку. Для проекта с зависимостями эти расходы нужно считать отдельно.

Перед первой сборкой зафиксируй хотя бы четыре пункта:

1. что должен сделать пользователь;
2. какие данные он вводит;
3. какой результат должен увидеть;
4. какая команда, проверка или сценарий покажет готовность.

Не ставь себе срок из этой оценки на восстановление. Универсальной длительности ремонта нет: она зависит от состояния конкретной папки и внешних зависимостей.

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

## С чего начать восстановление проекта?

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

![Кот у карточек с командами проверки папки и сохранения diff.](https://s3.regru.cloud/crossmark/statejnik/images/guides/vajb-koding-chinim-razvalivshijsya-proekt/kadr-1.webp)

Первый риск при запросе «вайб-кодинг с чего начать» - работа не в той папке или ветке. Терминал, Claude Code и Git могут считать текущей разной директорию. Особенно легко ошибиться с worktree и запуском из родительской папки.

Перед новой попыткой выполни:

```bash
cd path/to/the/project
pwd
git status
git diff
```

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

Если состояние уже запутано, сохрани diff:

```bash
git diff > failed-attempt.patch
```

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

Проверь три вещи:

1. Какие файлы изменены.
2. Есть ли незакоммиченные изменения.
3. Какие внешние сервисы нужны для запуска и проверки.

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

Отправь в новой сессии:

## Как восстановить проект шаг за шагом?

Восстанавливай проект в порядке `Explore → Plan → Implement → Commit`: сначала изучи файлы и состояние, затем составь и проверь план, после этого внеси одно небольшое изменение и зафиксируй рабочий результат. Для каждого шага заранее задай проверяемый критерий: тест, сборку, линтер, скрипт или проверку интерфейса. Постоянные правила проекта держи в [`CLAUDE.md`](/guides/claude-md-udalit-ili-perepisat).

![Мужчина закрывает лицо лапой рядом с цепочкой из пяти шагов ремонта.](https://s3.regru.cloud/crossmark/statejnik/images/guides/vajb-koding-chinim-razvalivshijsya-proekt/kadr-2.webp)

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

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

   

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

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

   

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

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

Anthropic описывает разницу так:

> «Дай Claude проверку, которую он может запустить: тесты, сборку или скриншот для сравнения. Это отличает сессию, за которой ты наблюдаешь, от сессии, которую можно оставить работать.»
> - Anthropic, [Best practices for Claude Code](https://code.claude.com/docs/en/best-practices)

После проверки плана отправь короткое подтверждение с ограничением:

   

Не объединяй восстановление нескольких функций в один запрос. После изменения посмотри diff и список файлов. Если область оказалась шире плана, останови работу до следующего запроса.

В Claude Code изменения можно принимать, отклонять или просить переделать после просмотра сравнения исходного и нового варианта. В этот момент ты проверяешь конкретную правку, а не обещание агента.

   

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

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

   ```bash
   git status
   git diff
   git add path/to/changed-file
   git commit -m "Fix specific project issue"
   ```

## Как новичку чинить проект и не сломать его снова?

Ограничивай каждую правку конкретными файлами и маленьким числом строк, не соглашайся на полную замену файла без причины и всегда смотри diff. Инструкции храни в [`CLAUDE.md`](/guides/claude-md-udalit-ili-perepisat) в корне проекта, а состояние между сессиями - в `PROGRESS.md`. После каждой правки запускай проверку.

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

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

`CLAUDE.md` положи в корень репозитория:

```text
my-project/
├── CLAUDE.md
├── package.json
├── src/
└── ...
```

В начале сессии проверь, какие инструкции загружены:

```text
Покажи, какие CLAUDE.md и другие memory-файлы ты загрузил.
Кратко перечисли применимые правила.
```

`PROGRESS.md` нужен для переноса состояния между сессиями. Попроси сохранить в нём:

Не держи бесконечную историю в одном чате. После [сжатия контекста](/guides/kontekst-v-claude-code-zabyvaet-proekt) могут потеряться точные решения, список изменённых файлов и незавершённые шаги. Новая сессия с `CLAUDE.md` и `PROGRESS.md` даёт более ясную отправную точку.

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

Есть граница, которую я не буду маскировать советом. В собранных источниках нет универсального визуального критерия, по которому человек без опыта всегда отличит безопасный diff от опасного. Поэтому остаются механические проверки: область файлов, diff, тесты, сборка, линтер, скрипты и реальный сценарий.

## Что делать, если тест проходит, а функция всё ещё сломана?

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

![Собака поднимает лапу рядом с чек-листом теста и пользовательского сценария.](https://s3.regru.cloud/crossmark/statejnik/images/guides/vajb-koding-chinim-razvalivshijsya-proekt/kadr-3.webp)

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

Поэтому проверяй два разных результата:

- что тест завершился успешно;
- что пользовательский сценарий действительно работает.

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

После основной проверки попроси ИИ найти крайние случаи:

Anthropic предлагает сначала найти непокрытый код, добавить проверки, запустить тесты и отдельно попросить найти крайние случаи. Это не универсальный чек-лист для любого проекта: конкретный набор проверок зависит от проекта.

## Что делать, если откат не вернул проект в рабочее состояние?

`/rewind` открывает меню отката внутри сессии, но контрольные точки не отслеживают файлы, изменённые через Bash-команды. Контрольные точки также не заменяют Git и не дают полной гарантии возврата изменений из внешних процессов или других сессий. Для постоянной рабочей точки используй коммиты и ветки.

Команда отката:

```text
/rewind
```

В Claude Code есть и другой способ открыть меню:

```text
Esc Esc
```

Он работает, когда поле запроса пустое.

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

Но `/rewind` не отслеживает файлы, изменённые Bash-командами вроде `rm`, `mv` или `cp`. Ограничения также относятся к внешним процессам, другим сессиям, subagents и ссылкам.

Считай контрольные точки локальной отменой, а Git - постоянной историей.

Поэтому после отката проверь:

```bash
git status
git diff
```

Если проект не вернулся в рабочее состояние, не повторяй ту же команду вслепую. Зафиксируй текущее состояние, найди изменения вне checkpoint и начни новую диагностику с Git-историей.

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

Вайб-кодинг подходит для создания прототипов и простых проектов, если ты описываешь результат обычным языком, даёшь ИИ контекст и проверяешь каждое изменение маленькими шагами. Он не отменяет проверку файлов, зависимостей, тестов, сборки и реального пользовательского сценария. Подход работает, когда ты держишь проект под Git, хранишь инструкции в CLAUDE.md и начинаешь с диагностики, а не с правки. Перед каждой задачей изучай текущее состояние проекта, составляй план и вноси только одно изменение за раз.

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

Начни с перехода в папку проекта, проверь `pwd`, `git status` и `git diff`, затем попроси ИИ изучить структуру без изменений. После этого составь небольшой план и только потом переходи к редактированию.

В 2026 подход позволяет собирать прототипы обычным языком, но цена ошибки остаётся связана с проверкой и внешними зависимостями. У проекта могут потребоваться SSO, API, секреты и учётные данные.

Это значит передать ИИ часть технической реализации и оставить за человеком описание результата, ограничений и критериев готовности. Ответственность за проверку проекта при этом не исчезает.

Да, в фактуре есть примеры сайтов и каталогов, которые можно запускать локально. Для полного повторения YAAL нужен базовый опыт с Node.js и Next.js, а отдельные проекты могут зависеть от внешних сервисов.

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

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

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

На практике ты описываешь задачу, ИИ изучает проект, меняет файлы и запускает проверки. Рабочий процесс надёжнее, когда он разделён на `Explore → Plan → Implement → Commit`.

Можно собрать прототип, простой сайт, каталог или интерфейс с данными. Возможный результат зависит от проекта и его зависимостей: для части приложений нужны SSO, API, секреты и учётные данные.

- [Anthropic Economic Index: AI's impact on software development](https://www.anthropic.com/research/impact-software-development?s=03)
- [How Claude Code works](https://code.claude.com/docs/en/how-claude-code-works)
- [Best practices for Claude Code](https://code.claude.com/docs/en/best-practices)
- [Use Claude Code in VS Code](https://code.claude.com/docs/en/vs-code)
- [Checkpointing](https://code.claude.com/docs/en/checkpointing)
- [Common workflows](https://docs.anthropic.com/en/docs/claude-code/common-workflows)
- [Cleanlab Office Presence Dashboard](https://github.com/cleanlab/office-presence-dashboard)
- [YAAL](https://github.com/0xWelt/yaal)
- [Awesome-Vibe-Coding](https://github.com/0xWelt/Awesome-Vibe-Coding)
- [Рабочий процесс с неудачными попытками](https://www.reddit.com/r/ClaudeAI/comments/1reh0lb/i_tracked_30_coding_sessions_i_redo_tasks_from/)
- [Проблемы работы в неправильной папке или ветке](https://www.reddit.com/r/ClaudeCode/comments/1tnbo0a/am_i_using_worktrees_wrong_or_is_claude_code_just/)
- [Замена целого файла при исправлении](https://www.reddit.com/r/vibecoding/comments/1v0qirf/need_help_im_a_beginner_literally_zero/)