O que um construtor de IA não consegue construir?
O que um construtor de IA não consegue construir?
Ele não constrói o que depende de regra de negócio profunda, de integração rara ou de plataforma fora do navegador. Aplicativo nativo de celular, jogo 3D, sistema com anos de lógica acumulada e cálculo tributário completo ficam de fora. Site, aplicativo web e jogo 2D ficam dentro, e é uma fronteira bem definida.
Vale conhecer essa fronteira antes de começar, e não no meio de um projeto que já consumiu dinheiro e paciência. O resto deste texto separa o que está fora, o que está dentro e o que está na área cinzenta que confunde quase todo mundo.
Onde exatamente fica a fronteira?
Do lado de dentro está tudo que é uma página em um navegador. O Zugo monta site, aplicativo web e jogo 2D a partir de uma descrição em texto, publica em um endereço no formato seuprojeto.zugo.run e aceita domínio próprio por cima.
Do lado de fora está tudo que exige outro ambiente de execução ou outra disciplina de engenharia. Aplicativo nativo distribuído nas lojas, jogo tridimensional, integração com equipamento físico, processamento pesado no servidor e sistema que já existe há anos com regra escrita por dezenas de pessoas.
Entre os dois há uma faixa larga que confunde. Ela é feita de coisas que o construtor alcança, mas em várias etapas: lógica de negócio incomum, fluxo com muitas condições, permissão por perfil de usuário. Nada disso sai de um prompt só, e tudo isso sai de uma sequência de edições descritas com clareza.
A regra prática é curta. Se você consegue explicar o comportamento em uma página de texto, provavelmente dá. Se explicar o comportamento exige um documento com exceções numeradas, prepare orçamento de tempo.
O que fica de fora e o que fazer em cada caso?
Cada linha abaixo é um pedido que aparece com frequência e não termina bem se for tratado como uma frase no chat.
| O que fica de fora | Por que | O que fazer no lugar |
|---|---|---|
| Aplicativo nativo publicado nas lojas | A saída roda no navegador, não é um pacote de loja | Aplicativo web publicado, salvo na tela inicial do celular |
| Jogo 3D | Os jogos gerados são 2D e rodam no navegador | Jogo 2D com direção de arte forte, ou um motor dedicado |
| Cálculo tributário completo | Regra muda por produto e por região, e errar custa caro | Serviço externo que faça a conta e uma tela que leia o resultado |
| Sistema antigo com anos de lógica | Não existe descrição curta que contenha essa lógica | Migração por partes, com engenheiros no time |
| Integração com serviço sem conector | Os conectores oficiais cobrem uma lista definida | Exportar para o GitHub e integrar fora do construtor |
| Processamento pesado em servidor | O projeto é uma página, não uma fila de trabalho | Serviço próprio, com o site apenas consumindo o resultado |
A coluna da direita é a parte útil. Quase nada nessa lista é impossível de construir: é impossível de construir apenas descrevendo. O caminho existe, ele só passa por mais gente ou por mais ferramenta do que uma conversa de chat.
Por que regra de negócio específica trava um prompt?
Porque descrição em linguagem natural comprime, e regra de negócio vive nas exceções. "Desconto para cliente antigo" cabe em quatro palavras e esconde umas quinze decisões: a partir de quantos meses, se acumula com promoção, se vale no frete, o que acontece quando o cliente cancela e volta.
O construtor precisa preencher cada uma dessas lacunas para gerar alguma coisa. Ele preenche com o palpite mais razoável, que é exatamente o que você quer quando não tem preferência, e exatamente o que você não quer quando a resposta certa está num contrato.
O jeito de sair disso não é escrever um prompt gigante. É construir a base primeiro e depois pedir uma regra por edição, conferindo o resultado antes da próxima. Cada edição custa 3 créditos, então cinco regras específicas são um gasto pequeno e previsível.
O que não funciona é o caminho do meio: um pedido longo com sete condições enterradas no quarto parágrafo. Ou você separa, ou aceita que a metade do meio veio por palpite.
Jogo 3D entra? E jogo de celular?
Jogo 3D não entra. Os jogos gerados são 2D e rodam no navegador, e essa é uma decisão de escopo, não uma limitação temporária que some no mês que vem. Se o seu projeto depende de câmera tridimensional, o lugar dele é um motor de jogo.
Jogo de celular entra pela porta do navegador. Um jogo 2D publicado abre no telefone pelo link, funciona no toque se você pedir controles de toque, e pode ser salvo na tela inicial. O que ele não é: um pacote assinado nas lojas de aplicativo.
Dentro do 2D o alcance é maior do que as pessoas imaginam. Plataforma, quebra-cabeça, corrida vista de cima, defesa de torre, jogo de cartas, jogo da memória e quiz são gêneros que se descrevem bem em texto, e a galeria já traz 5 modelos de jogo entre os 25 disponíveis. O passo a passo está em a IA consegue fazer um jogo.
O construtor substitui um time de desenvolvimento?
Em produto complexo, não, e essa é a fronteira mais importante de todas. Um sistema com muitos perfis de acesso, integração com o financeiro da empresa e requisito de auditoria é trabalho de engenharia, e chamar isso de outra coisa custa caro para quem acredita.
O que o construtor faz é encurtar o começo. A versão que valida a ideia, o site que sustenta a campanha, o painel interno que resolve uma dor específica: tudo isso sai em horas em vez de semanas, e boa parte dos projetos nunca precisa passar disso.
Quando precisa, o caminho de saída existe desde o primeiro dia. O código exporta para o GitHub, o deploy sai na sua conta da Vercel, e o banco fica na sua conta do Supabase. A transição para gente contratada é discutida em dá para contratar um desenvolvedor depois.
O que ele faz bem e as pessoas subestimam?
Aplicativo com banco de dados atrás. Cadastro, listagem, filtro, formulário que salva, painel que lê o que foi salvo: essa família resolve bem e cobre uma fatia enorme dos pedidos internos de empresa pequena, como está detalhado em a IA consegue fazer um app com banco de dados.
Reescrita de página existente. Trocar estrutura, ordem de blocos e texto de uma página que já funciona é barato e rápido, e é onde o retorno por crédito gasto costuma ser mais alto.
Primeira versão de algo que você ainda não sabe explicar direito. Construir uma versão errada e olhar para ela ensina mais do que outra reunião de alinhamento, e refazer custa 6 créditos em vez de duas semanas de alguém.
Como descobrir de que lado o seu projeto cai?
Escreva a descrição inteira antes de gastar qualquer coisa. Se ela couber em uma página e você conseguir ler em voz alta sem travar em nenhuma exceção, construa. O teste é bobo e acerta com uma frequência incômoda.
Se travar, marque onde travou. Aquele ponto é a regra de negócio de verdade do seu projeto, e ele decide o caminho: construir a base e resolver o ponto por edições, ou aceitar que esse ponto é engenharia e planejar de acordo.
O teste mais barato de todos é construir a versão sem a parte difícil. Uma construção custa 6 créditos, o plano gratuito dá 5 e o Pro custa $25 por mês com 200 créditos. Ver a base pronta na tela muda a conversa sobre a parte difícil mais do que qualquer estimativa.
Qual é o próximo passo?
Pegue o seu projeto e classifique em uma das três faixas: cabe em uma descrição, cabe em uma sequência de edições, ou precisa de engenheiros. Depois construa a parte que cabe hoje em zugo.dev e deixe o resto para quando ela existir. Fronteira conhecida antes do começo custa muito menos que fronteira descoberta no meio.