Que stack de tecnologia sai de um construtor de IA?

Que stack de tecnologia sai de um construtor de IA?

O Zugo entrega projeto web: marcação para a estrutura, CSS para a aparência e JavaScript para o comportamento, tudo rodando no navegador. Capacidade externa chega por conector em vez de ser reimplementada, então banco é Supabase e pagamento é Stripe. O projeto inteiro exporta para o GitHub, e ler o código é a forma mais rápida de confirmar isso.

"Qual é o stack" são três perguntas usando o mesmo casaco: um desenvolvedor consegue manter isso, eu consigo hospedar onde eu quiser, e eu consigo ir embora. O resto deste texto responde as três e ensina a verificar as respostas em vez de acreditar nelas.

Por que a pergunta sobre stack importa mesmo?

Porque ela decide quem pode trabalhar no resultado. Um projeto no formato que desenvolvedores reconhecem pode ser entregue a qualquer um deles. Um projeto em formato proprietário só pode ser entregue a quem topar aprender aquele formato antes, o que é um grupo bem menor e uma conversa bem mais chata.

Ela também decide onde a coisa pode morar. Saída que o navegador abre direto pode ser servida de quase qualquer lugar. Saída que depende de um ambiente específico fica presa a quem oferece aquele ambiente, e essa amarra acompanha o projeto pelo resto da vida dele.

E ela decide quanto custa sair. Essa é a pergunta que está embaixo das outras duas. Plataforma visual em que você monta telas numa lousa é um compromisso, porque as telas não são arquivos. Arquivo de texto é portátil por natureza, e nenhuma lista de recursos substitui essa propriedade.

No Brasil isso tem um peso extra em trabalho de agência. Quem entrega para cliente precisa poder dizer o que fica com o cliente no fim do contrato, e a resposta "fica dentro da minha ferramenta" costuma travar a proposta antes do preço.

O que sai de fato de uma construção no Zugo?

Um projeto web que funciona. A página publicada é marcação, estilo e script que o navegador carrega e executa, e é por isso que uma construção abre em seuprojeto.zugo.run na hora, sem nenhum passo de provisionamento do seu lado.

Uma página simples sai como um documento só. Uma plataforma multipágina sai como um conjunto de arquivos de origem que é compilado antes de você ver a prévia, e cada construção passa por uma sandbox: a que não abre não é entregue. O tipo de projeto muda o formato, e não muda o fato de que o destino final é o navegador.

Quando você conecta o Supabase, a página gerada conversa com o seu projeto do Supabase a partir do navegador, usando uma versão fixada do cliente oficial. Fixar a versão importa mais do que parece: código rodando no seu domínio publicado, ao lado dos dados dos seus visitantes, não deveria mudar sozinho porque um terceiro lançou uma atualização.

O que não sai é um repositório pronto no padrão que o seu time já usa. Se a sua empresa padroniza em um framework específico e o plano de contratação assume isso, saiba disso antes de começar, e não depois de três semanas de trabalho.

Como conferir o stack com as suas próprias mãos?

Lendo, o que leva um minuto e vale mais que qualquer afirmação deste texto ou de qualquer página de vendas.

A terceira linha é a que vale fazer antes de planejar qualquer coisa em cima de busca. Se as suas seções dividem um endereço só, o buscador enxerga uma página só, o que está ótimo para uma landing page e limita um site de conteúdo. Isso é tratado em site feito com IA é bom para SEO.

A quarta linha é o teste honesto de toda promessa de propriedade que qualquer construtor faz, incluindo o nosso. Faça a exportação em um projeto descartável antes de precisar, e não no dia em que você estiver de saída.

O que esse formato facilita?

Quatro coisas, e elas são a razão da escolha.

Qualquer pessoa consegue ler. Marcação, estilo e script são a língua comum da web. Um desenvolvedor não precisa aprender uma abstração proprietária antes de te ajudar, o que encurta a primeira conversa e derruba o orçamento.

Roda em qualquer lugar. O projeto pode ser servido pela hospedagem do Zugo em seuprojeto.zugo.run, publicado na sua própria conta da Vercel pelo conector, ou servido de onde você quiser depois que o repositório estiver no GitHub.

Nada fica entre você e o resultado. O que você lê no código é o que o navegador executa. Depurar vira olhar a página, e não raciocinar sobre uma esteira de compilação que você não controla.

A superfície de falha é pequena. Menos peças móveis entre a sua descrição e a página renderizada é parte do motivo de uma construção simples ficar pronta em cerca de um minuto e uma plataforma multipágina levar alguns.

O que esse formato custa?

Três trocas reais, e construtor que não nomeia isso não está sendo franco com você.

Não é o repositório que o seu time espera abrir. Portátil e legível não é a mesma coisa que familiar. Se o padrão interno é outro, haverá um trabalho de adaptação, e ele é menor que reescrever do zero e maior que zero.

Um projeto grande demais chega no teto. Aplicação muito grande é exatamente o formato em que um time de desenvolvimento e um código convencional justificam o custo. Em produto complexo o Zugo não substitui esse time, e dizer o contrário seria vender o que não existe.

Não há um ecossistema de componentes prontos. Não existe loja de blocos para instalar. O que for incomum é gerado para você ou construído por edições sucessivas. Às vezes isso é melhor que caçar plugin. Quando já existe um plugin maduro para o problema, não é.

Onde entram os serviços externos?

Ao lado da página, e não dentro dela, o que é a parte que muda o jeito certo de fazer a pergunta sobre stack.

Leia isso como um segundo stack embaixo do primeiro. A página gerada é pequena porque as peças pesadas e sensíveis ficam com serviços feitos para elas. Um app gerado nunca guarda número de cartão, porque o Stripe guarda, e nunca cria hash de senha, porque o Supabase cria.

Esse arranjo é também o que um desenvolvedor competente teria montado. A diferença interessante é que aqui isso são três cliques em vez de três tardes de trabalho.

Quanto custa testar o stack no seu projeto?

Por ação, publicado antes, para a conta acontecer no papel e não na fatura. Uma construção custa 6 créditos, uma edição custa 3, e uma plataforma multipágina custa 12 nas três primeiras páginas mais 3 por página depois. O modo Hi-Fi dobra os dois primeiros números.

O plano gratuito dá 5 créditos, menos que uma construção nova, então avaliar a saída na sua própria ideia exige um plano pago. O Pro custa $25 por mês com 200 créditos, algo como 16 plataformas ou 33 construções, e o Business custa $99 por mês com 800 créditos.

Para avaliar stack, uma construção basta. Gaste 6 créditos em algo pequeno, publique, leia o código-fonte, exporte e abra o repositório. Essa sequência diz mais sobre a saída que qualquer documentação, e é a mesma sequência que um desenvolvedor contratado vai rodar no primeiro dia, como está descrito em dá para contratar um desenvolvedor depois.

O que perguntar para qualquer construtor de IA?

Quatro perguntas, nessa ordem, porque cada uma torna a seguinte significativa.

Eu consigo ver o código de uma página publicada sem pedir permissão. Eu consigo exportar para um repositório que eu controlo. A exportação traz o projeto inteiro ou só um retrato do que estava visível. E eu consigo rodar e mudar isso sem o construtor no meio.

Ferramenta que responde sim às quatro tornou a pergunta sobre stack quase acadêmica, porque qualquer que seja a resposta, você pode ir lá conferir. Ferramenta que responde não à segunda ou à terceira tornou essa a pergunta mais importante da sua avaliação, qualquer que seja o stack.

Qual é o próximo passo?

Se você prefere conferir a ler, o caminho é curto. Descreva algo pequeno em zugo.dev, publique, veja o código-fonte do resultado e depois exporte. As práticas da exportação estão em dá para exportar o código, e o que você vê nesse repositório vale mais que qualquer promessa escrita.