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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изучи проект и раздели найденные проблемы на две группы:
1. интерфейс и отображение;
2. данные, загрузка и внешние зависимости.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

git diff > failed-attempt.patch

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

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

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

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

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

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

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

1. Изучи текущее состояние.

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

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

   Исследование проектаСкопировать промпт

   Изучи текущую папку без изменений.
   Покажи:
   - текущую директорию и git-ветку;
   - git status и git diff;
   - структуру проекта;
   - файлы, связанные с проблемой;
   - внешние сервисы, секреты и учётные данные, от которых зависит запуск.
   
   Опиши, что сейчас работает, что сломано и какие факты это подтверждают.
   Ничего не редактируй.

2. Составь план малых шагов.

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

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

   План восстановленияСкопировать промпт

   На основе изученного состояния составь план из маленьких шагов.
   Для каждого шага укажи:
   - конкретные файлы;
   - минимальное изменение;
   - что должно измениться для пользователя;
   - проверяемый критерий результата;
   - возможную зависимость от внешнего сервиса.
   
   Не редактируй файлы.

3. Проверь план до работы.

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

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

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

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

   • Anthropic, Best practices for Claude Code

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

   Подтверждение первого измененияСкопировать промпт

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

4. Внеси одно небольшое изменение.

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

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

   Точечное исправлениеСкопировать промпт

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

5. Зафиксируй рабочий результат.

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

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

   bash

   Скопировать

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

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

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

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

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

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

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

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

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

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

Создай или обнови PROGRESS.md:
- что уже сделано;
- какие файлы изменены;
- какие проверки прошли;
- какая ошибка осталась;
- какой следующий конкретный шаг.

Ничего больше не меняй.

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

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

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

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

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

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

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

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

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

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

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

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

/rewind

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

Esc Esc

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

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

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

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

git status
git diff

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

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