Criador de apps com IA e GitHub: como exportar o código

Criador de apps com IA e GitHub: como exportar o código

Dá. O Zugo exporta o código-fonte do projeto para um repositório seu no GitHub, e a exportação não consome créditos: créditos são a moeda da geração e das edições. A partir do momento em que o código está no seu repositório, o projeto deixa de depender da ferramenta que o escreveu.

O que exatamente vai para o repositório?

Vai o código-fonte do projeto que o Zugo montou, ou seja, os arquivos que rodam quando alguém abre o seu link. Não é um pacote fechado nem uma exportação de imagens. É o mesmo material que um desenvolvedor abriria no editor dele numa segunda-feira qualquer.

Essa diferença é maior do que parece. Enquanto o projeto vive apenas dentro da ferramenta, ele é um serviço que você assina. Depois de exportado, ele é um arquivo que você guarda. A distinção só aparece no dia em que você quer trocar de fornecedor, contratar alguém ou entender o que foi feito.

O que não viaja junto é tudo aquilo que nunca foi código. As suas contas em serviços externos continuam nos serviços externos, as chaves de acesso continuam onde você as configurou e os dados já cadastrados pelos seus usuários continuam no banco. A exportação copia o projeto, não o mundo ao redor dele.

Exportar o código gasta créditos?

Não. Créditos pagam a geração e a edição, e a tabela abaixo tem todos os valores que existem.

Repare no valor da edição, porque é ele que decide a sua conta no fim do mês: cada ajuste custa 3, e não 1. O número 1 circula em materiais antigos e está errado hoje.

O plano gratuito dá 5 créditos, menos do que uma construção completa de 6, então serve para conhecer a ferramenta e não para terminar um projeto. O Pro custa US$ 25 por mês com 200 créditos, o equivalente a cerca de 16 plataformas multipágina, 33 construções ou 66 edições. O Business custa US$ 99 por mês com 800 créditos.

Em que momento vale a pena exportar?

Depois de o projeto parar de mudar de forma, não antes. Enquanto você ainda está descobrindo o que quer, a conversa dentro da ferramenta é mais rápida e mais barata: você pede um ajuste, paga 3 e vê o resultado.

O ponto de virada costuma ser a regra de negócio específica. Aquela condição do seu setor, aquele cálculo que só a sua empresa faz, aquele fluxo que nenhum modelo pronto prevê. Esse tipo de coisa se afina com edições sucessivas até certo ponto, e passado esse ponto sai mais barato abrir o código.

Outro momento clássico é a entrada de uma pessoa técnica no time. Quando alguém vai assumir a manutenção, o repositório é a forma normal de trabalhar: histórico, branches, revisão de mudanças. Você não pede a um desenvolvedor que trabalhe por chat, você entrega o código a ele.

O que acontece se eu editar o código no GitHub?

Você passa a ter duas versões vivas do mesmo projeto, e precisa decidir qual delas manda. Essa é a parte que mais gera confusão e a que menos se comenta quando o assunto é exportação de código.

Se as edições seguem acontecendo dentro da ferramenta, o repositório é uma cópia de leitura, útil para backup e para mostrar a um desenvolvedor. Se as edições passam a acontecer no repositório, ele vira a fonte da verdade e a conversa por chat sai de cena.

O erro caro é tentar manter as duas coisas ao mesmo tempo sem combinar nada com ninguém. Alguém corrige um texto pelo chat, outra pessoa corrige o mesmo texto no editor, e as duas correções deixam de conversar. Escolha o lado, escreva isso em algum lugar e avise quem trabalha com você.

Como o GitHub se encaixa nas outras integrações?

Ele é a peça que garante saída, enquanto as outras cuidam de funções do produto. Ver o conjunto inteiro ajuda a decidir o que ligar e em que ordem.

A dupla GitHub e Vercel merece atenção porque as pessoas confundem as duas. O GitHub guarda o código, a Vercel coloca o código no ar. Uma responde à pergunta "onde está o projeto", a outra responde "quem serve o projeto para os visitantes".

Se o seu objetivo é sair da dependência de qualquer fornecedor, a combinação é essa: código no seu repositório, deploy na sua conta, domínio no seu nome. Nenhuma dessas três coisas exige que você saiba programar para ser configurada, mas as três exigem que você tenha as contas em seu nome.

Quais erros aparecem com mais frequência?

Três, e todos custam tempo depois.

O repositório fica na conta pessoal de alguém do time. Funciona bem até essa pessoa sair da empresa ou perder o acesso ao e-mail antigo. Crie o repositório em uma conta ou organização que pertença ao negócio, mesmo que a operação do dia a dia seja de uma pessoa só.

Chaves de acesso acabam versionadas junto com o código. É o problema mais comum de qualquer projeto exportado, não só dos que nasceram com IA. Uma chave publicada em repositório público vale como chave vazada, e a correção é trocar a chave, não apagar o arquivo.

O código é exportado cedo demais, na expectativa de que exportar seja uma forma de salvar o trabalho. Backup é uma coisa, migração é outra. Enquanto o produto ainda muda toda semana, exportar a cada mudança só produz cópias que ninguém consegue comparar.

Onde estão os limites honestos?

O Zugo não substitui um time de desenvolvimento em um produto complexo, e ter o código no GitHub não muda isso. O que muda é quem pode ajudar você a partir dali: com o repositório na mão, qualquer desenvolvedor consegue continuar, sem depender da nossa ferramenta para nada.

A checagem em sandbox acontece antes da entrega, e é ela que garante que uma construção quebrada não chegue até você. Ela não cobre o que você escrever depois no seu repositório. A partir da exportação, testar é responsabilidade de quem edita.

Se o projeto é um jogo, vale lembrar que os jogos gerados são 2D e rodam no navegador. O código exportado é código de jogo web, e essa continua sendo a natureza dele depois da exportação.

Por onde começar?

Construa e ajuste primeiro, exporte depois. A ordem inversa parece mais segura e costuma render um repositório cheio de versões que ninguém revisita, porque o projeto ainda estava mudando de ideia quando cada uma delas foi salva.

Quando o formato estiver firme, conecte o GitHub e coloque o repositório no nome do negócio. A partir dali, trate as chaves de acesso com o mesmo cuidado que você trata a senha do banco.

Para ver o ciclo completo antes disso, como criar um aplicativo com IA mostra o caminho da primeira descrição até a publicação, dá para exportar o código responde às dúvidas de propriedade e criador de apps com IA e Vercel explica o deploy na sua própria conta.

Você começa em zugo.dev pelo plano gratuito, usa um dos 25 modelos prontos como ponto de partida e decide sobre o repositório quando já houver algo digno de ser versionado.