Por que minha construção com IA falhou? Causas e correção

Por que minha construção com IA falhou? Causas e correção

Quase sempre porque o prompt pediu mais do que cabe numa passada só, ou pediu algo que depende de uma integração ainda não conectada. Uma falha avisada é a verificação funcionando: todo projeto sobe numa sandbox antes da entrega, e a construção que não abriu é reportada como falha em vez de entregue como página em branco.

Ler essa frase do jeito certo muda o que você faz em seguida. A falha é informação sobre o pedido, não veredito sobre a ferramenta nem sobre você, e a maioria delas some quando o próximo prompt fica menor e mais específico.

O que uma construção falhada quer dizer, exatamente?

Que o projeto não subiu e não desenhou nada na sandbox, então não foi entregue. Essa verificação fica entre a geração e a entrega justamente para que uma página que não abre vire problema nosso, e não seu.

Vale ser claro sobre o que a checagem é e o que ela não é. Ela confirma que a construção carregou e desenhou algo. Ela não confirma que o comportamento é o que você tinha em mente, não revisa o código e não julga se o texto ficou bom. Ela reduz o risco de receber uma página quebrada, não o elimina.

Daí saem duas frustrações diferentes com correções diferentes. A construção que falhou não chegou, e o conserto é outro prompt. A construção que chegou torta é um projeto funcionando com o qual você discorda, e o conserto é uma edição. Confundir as duas é o que mais custa tempo.

Quais são as causas mais comuns?

Cinco, e as duas primeiras respondem pela maior parte do que aparece no dia a dia.

A linha do escopo é a mais interessante porque nem é bem um erro. Uma passada de geração tem orçamento, e um prompt que descreve uma plataforma inteira com onze telas, três perfis de acesso e um modelo de cobrança está pedindo mais raciocínio do que cabe numa passada. Dividir não é gambiarra, é o fluxo previsto.

As linhas de integração têm todas o mesmo formato: você descreveu um recurso que vive num serviço externo e o serviço não estava ligado. Nenhuma página cria seu projeto no Supabase sozinha, então a construção não tem onde guardar o dado que você mandou guardar.

Como reescrever um prompt que insiste em falhar?

Cortando até sobrar aquilo que precisa funcionar, e crescendo de novo a partir dali. Três passadas costumam render mais que uma tentativa heroica, e no total saem mais baratas que uma sequência de falhas.

Comece só com estrutura e conteúdo. Quais são as páginas, o que cada uma diz, o que o visitante deveria fazer. Sem contas, sem cobrança, sem dados. Essa é uma construção que o gerador termina com folga, e ela já te dá algo para olhar.

Depois acrescente uma capacidade por edição. Login numa passada. O painel que o usuário logado enxerga na seguinte. Cobrança depois. Cada edição é uma mudança pequena e conferível, e quando uma delas sai errada você sabe exatamente qual frase causou, coisa que nunca se sabe depois de um prompt gigante.

Descreva comportamento, não adjetivo. "Visitante deslogado que abre a página de pedidos é levado para o login" dá para construir. "Deixe seguro" não descreve nada. O tratamento completo está em como escrever um bom prompt.

E se a construção abriu, mas ficou errada?

Aí nada falhou, e a ferramenta certa é a edição, não a reconstrução. Vale interiorizar essa distinção, porque começar do zero joga fora as partes que já estavam certas.

A linha do meio é a única em que recomeçar vence, e o sinal é você estar descrevendo outro produto, não outra versão deste. A mecânica das edições sucessivas está em como editar depois de gerar.

Quanto custa mais uma tentativa?

Os preços por ação são publicados, então dá para planejar um caminho de várias passadas em vez de apostar tudo num prompt.

O Pro custa $25 por mês com 200 créditos, algo como 16 plataformas multipágina, 33 construções ou 66 edições, se editar for tudo o que você faz. O plano gratuito traz 5 créditos uma vez, menos que uma construção inteira. O Business custa $99 por mês com 800 créditos.

Leia esses números como argumento a favor do caminho incremental. Uma construção mais cinco edições custa vinte e um no total e produz um projeto que você entendeu passo a passo. Quatro tentativas de um prompt gigante custam vinte e quatro e produzem ou nada, ou algo que você não sabe consertar.

Quando o problema não é o prompt?

Quando o que você pede está fora do que o produto entrega, e nenhuma reescrita muda isso. Ser claro aqui poupa gente de culpar as próprias palavras por um limite da ferramenta.

Aplicativo nativo de loja. O resultado roda no navegador. Ele abre no celular e pode ir para a tela inicial, e isso não é uma publicação na App Store nem na Play.

Jogo em 3D. Os jogos são 2D e rodam no navegador. Isso é um alcance real e também uma borda real.

Regra de negócio muito específica. Rateio proporcional, matriz de permissões, integração com um sistema de gestão que não tem conector: essas coisas chegam por uma sequência de edições, e às vezes por um desenvolvedor trabalhando no código exportado. O Zugo não substitui um time de desenvolvimento num produto complexo.

Qualquer coisa que exija julgamento sobre o seu negócio. O gerador escreve o que você descreve. Decidir o que deve ser construído continua sendo seu trabalho.

Como evitar a próxima falha?

Cinco hábitos, todos baratos.

Conecte os serviços antes de descrever recursos que dependem deles, porque a integração é pré-requisito e não continuação. Construa a menor versão que já seria interessante e trate o resto como edição. Nomeie comportamento em vez de adjetivo. Mude uma coisa por edição, para saber qual mudança causou o quê. E abra o endereço publicado num aparelho de verdade depois de cada passada, em vez de acumular cinco mudanças sem conferência.

Juntos, esses hábitos transformam a construção num laço difícil de errar feio: descreve uma coisa pequena, olha, descreve a próxima coisa pequena. Sobre o tempo de cada passada, quanto tempo leva construir traz os números de construção simples e de plataforma multipágina.

Quando quiser experimentar a versão incremental, descreva a menor página útil em zugo.dev, publique e só acrescente a segunda coisa depois de ter olhado a primeira.