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

Передавать нужно не папку с исходниками, а управляемый проект

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

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

1. Зафиксируйте текущий результат

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

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

2. Передайте репозиторий и историю изменений

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

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

3. Сделайте понятную инструкцию запуска

Минимальная инструкция должна отвечать на вопросы:

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

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

4. Опишите архитектуру простыми словами

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

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

5. Отдельно передайте данные и миграции

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

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

6. Составьте реестр внешних сервисов

Сервис	Что зафиксировать
Хостинг	Проект, окружения, домен, откат и владелец
База данных	Среды, резервные копии, миграции и роли
Платежи	Сценарии, статусы, вебхуки, возвраты и тестовый режим
Почта и уведомления	Отправитель, лимиты, шаблоны и обработка ошибок
Файлы и медиа	Хранилище, публичность ссылок, размер и удаление
Аналитика и мониторинг	Владелец, доступ, события и срок хранения

7. Передайте не только доступ, но и ответственность

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

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

8. Начните с маленькой задачи

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

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

Что не нужно делать

• не переписывать приложение до того, как зафиксирован текущий результат;
• не удалять старые миграции и историю без плана;
• не передавать секреты в открытом чате;
• не считать скриншоты документацией;
• не скрывать известные ограничения от нового исполнителя;
• не давать Production-доступ, если задачу можно выполнить на Preview.

Итог

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