Сможет ли программист потом доработать проект от ИИ

Да. Код проекта выгружается в репозиторий на GitHub под вашим аккаунтом, и дальше разработчик работает привычными инструментами: клонировать, ветка, ревью, деплой. Логин в Zugo ему для этого не нужен. Готовиться стоит к одному: сгенерированный код это работающая отправная точка, а не результат инженерного проектирования.

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

Что именно вы передаёте разработчику?

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

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

Вместе с кодом не уезжает то, что кодом не было. История чата с генерацией, кредиты и опубликованный адрес на zugo.run остаются в билдере. Данные остаются в вашем Supabase, платежи в вашем Stripe. Что именно попадает в репозиторий, разобрано в статье можно ли забрать исходный код.

Что подготовить до разговора с разработчиком?

Пять вещей, и на них уходит один вечер, а не неделя.

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

Отдельно решите вопрос доступа к аккаунтам. Отдавать пароль от аккаунта в билдере не нужно: коннекторы это ваши аккаунты в Supabase, Stripe и Vercel, и в каждом из них есть свои приглашения. Как это устроено в команде, разобрано в статье можно ли работать вдвоём над проектом.

Что разработчик увидит в коде?

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

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

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

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

В какой момент звать разработчика?

Когда правки перестают решать задачу. Это довольно чёткий сигнал, и его легко пропустить, если считать только деньги.

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

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

Есть и денежный ориентир. Правка стоит 3 кредита, сборка 6, многостраничная платформа 12 за первые три страницы и по 3 кредита за каждую следующую. Pro стоит $25 в месяц и даёт 200 кредитов, то есть 66 правок, если тратить их только на доводку. Когда вы регулярно упираетесь в потолок не по кредитам, а по смыслу («это правкой не объяснить»), значит, задача переросла формат.

От чего зависит цена доработки?

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

Ясность требований. Разработчик, которому объяснили задачу на одну страницу обычными словами, оценивает её быстро. Разработчик, которому показали проект и сказали «доделай», закладывает запас на неизвестность, и запас этот всегда больше реальной работы.

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

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

Кто отвечает за результат дальше. Разовая доработка и постоянная поддержка стоят по-разному, и договариваться об этом лучше в начале, а не когда что-то сломалось.

Что происходит с проектом после передачи?

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

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

Инфраструктура при этом не переезжает никуда. База остаётся в вашем Supabase, платежи в вашем Stripe, письма в вашем Resend, а деплой можно вести в ваш аккаунт Vercel. Ни одна из этих вещей не была внутри билдера, поэтому передача разработчику их не затрагивает. Как выглядит проект с экспортом на практике, разобрано в статье AI-сайт с экспортом в GitHub.

Какие вопросы задать разработчику на первой встрече?

Пять, и они экономят больше, чем любая экономия на ставке.

• Ты будешь дорабатывать это или переписывать? Ответ определяет и срок, и цену, и он должен прозвучать до подписания чего-либо.
• Что здесь придётся трогать в первую очередь? Хороший ответ конкретен и называет части проекта, а не общую оценку качества.
• Что мне не стоит менять в билдере после сегодняшнего дня? Обычно ответ «всё», и лучше услышать это заранее.
• Как ты будешь выкатывать изменения? У проекта уже есть работающий адрес, и переезд деплоя это отдельная задача, а не побочный эффект.
• Что из этого можно оставить как есть на год? Отделяет реальную необходимость от вкусовой переработки.

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

С чего начать подготовку?

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

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

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