Можно ли забрать исходный код из AI-билдера в GitHub

Да. Zugo выгружает исходники сгенерированного проекта в репозиторий под вашим аккаунтом на GitHub, и проект принадлежит вам. Вместе с кодом не уезжает то, что кодом никогда не было: история чата, кредиты, хостинг на zugo.run и аккаунты коннекторов, которые и так изначально ваши.

Это разделение и есть полезная часть ответа. Вопрос «можно ли забрать код» на самом деле про то, что останется у вас, если вы перестанете пользоваться билдером. Дальше разбираем, что вы держите в руках после экспорта и что придётся организовать самому.

Что вообще значит «экспорт кода»?

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

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

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

Что именно оказывается в репозитории?

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

Ожидания стоит выставить по объёму. Экспорт это приложение, а не ваша инфраструктура. Если сборка обращается к Supabase, код этих обращений лежит в репозитории, а сам проект Supabase продолжает жить в вашем аккаунте Supabase, ровно там, где и был.

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

Нужно ли платить, чтобы получить свой код?

Экспорт не устроен как платный выход. Тарифы покупают генерацию, и форма этой цены важнее любого отдельного числа. Free даёт 5 кредитов единоразово, Pro стоит $25 в месяц и даёт 200 кредитов, Business стоит $99 в месяц.

Кредиты тратятся на действия. Сборка стоит 6 кредитов, правка 3, а многостраничная платформа 12 за первые три страницы и по 3 кредита за каждую следующую. Режим Hi-Fi удваивает сборку и правку: 12 и 6 соответственно.

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

Считать честнее по проектам, а не по месяцам. Лендинг, который вы собрали один раз и выгрузили, это горстка кредитов. Платформа, которую вы две недели доводите, состоит в основном из правок, а 200 кредитов дают 66 правок, если тратить их только на них.

Что сделать с репозиторием в первый час?

Четыре вещи, и они занимают меньше времени, чем чтение про них.

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

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

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

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

Что делать с кодом после выгрузки?

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

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

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

Где честные границы экспортированного проекта?

Их четыре, и знать о них заранее значит не разочароваться в момент выгрузки.

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

Ничего из этого не является особенностью именно AI-билдеров. Так всегда выглядит владение софтом, и ровно в этом смысл того, чтобы держать код у себя.

Когда выгружать, а когда подождать?

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

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

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

Значит ли экспорт, что собранное можно продавать?

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

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

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