Os erros mais comuns de quem cria o primeiro app com IA (e como evitar)

Os erros mais comuns são construir antes de saber se alguém quer, pedir o app inteiro de uma vez, acreditar quando a IA diz que está pronto, não ter uma versão salva para voltar e deixar segurança e métricas para depois. Todos se evitam com hábitos de engenheiro: plano em fases pequenas, teste a cada fase, versão guardada, cuidado com chaves e medição do uso.

Construí três micro apps pedindo em português para a IA: o Cardápio no Zap, o Orçamento no Zap e o Preço Certo. Cada construção ficou registrada num diário, com cada pedido, cada teste e cada erro que apareceu. Relendo esses diários, os erros se repetem em padrões. Alguns foram da IA. Outros são os que quem está começando comete com ela.

Sou engenheiro de software há mais de cinco anos na Austrália e já fui mentor na General Assembly, ensinando gente a programar. A IA mudou quem escreve o código. Não mudou o que faz um app ficar de pé. Abaixo estão os erros mais comuns, com casos reais dos meus diários, e o hábito que evita cada um.

1. Construir antes de saber se alguém quer

Com IA, uma tela bonita aparece em minutos. É tentador ir direto para ela. O resultado clássico: duas semanas construindo, o app vai ao ar e ninguém usa. O app pode até estar bem feito. O que faltou foi alguém com aquele problema, do jeito que a pessoa imaginou.

A IA deixou a construção barata. Isso torna esse erro mais comum, não menos, porque a barreira que antes obrigava a pensar sumiu. O hábito que evita: antes de qualquer código, conversar com quem tem o problema sobre o que essa pessoa faz hoje. Escrevi um guia inteiro sobre como validar uma ideia de app antes de construir.

2. Pedir o app inteiro de uma vez

"Faz o meu app completo." A IA obedece, escreve muito código, alguma coisa não funciona, e você não sabe onde está o problema, porque tudo mudou ao mesmo tempo. Aí você pede para arrumar, ela mexe em mais coisas, e o que funcionava quebra.

Engenheiro não constrói assim. Antes de qualquer código, existe um documento do projeto que a IA lê sempre que começa a trabalhar, e um plano dividido em fases pequenas. Cada fase termina com algo que dá para ver funcionando e tem um jeito de testar. O Cardápio no Zap teve oito fases. A primeira era só o cardápio na tela, com lanches de exemplo. O carrinho veio depois. O WhatsApp, depois do carrinho. Quando algo quebra, você sabe onde: na última fase.

O plano também protege o tamanho do app. No Orçamento no Zap, sete funções ficaram fora de propósito, de pagamento online a logotipo do profissional. Cada uma delas teria trazido telas novas, testes novos e lugares novos para a IA errar.

Ensinando gente a programar, esse é o tropeço que eu mais vejo em quem está começando. A pessoa tem a ideia inteira na cabeça e quer ver tudo pronto no primeiro dia. Quando trava, não sabe se o problema está no login, na tela ou na conta, e a vontade é desistir. A virada costuma vir quando ela aceita uma meta bem menor, tipo "hoje, só a lista de itens aparece na tela". Uma parte pequena funcionando dá mais ânimo do que um app inteiro quebrado.

3. Acreditar quando a IA diz que está pronto

A IA termina e diz "pronto, está funcionando". Ela não está mentindo de propósito. Ela confere o que achou que devia conferir. Só que quem vai usar o app é uma pessoa, num celular, com pressa.

No Cardápio no Zap, todos os testes do plano da fase de finalizar o pedido passaram. Mesmo assim, havia dois erros. No primeiro, o cliente escolhia entregar, tentava enviar sem endereço, aparecia o aviso vermelho, e depois de escrever o endereço o aviso continuava lá. No segundo, o carrinho abria rolado para baixo, com o título cortado 73 pixels acima da tela. Nenhum dos dois impedia o pedido de chegar. Os dois iam irritar um cliente de verdade. Quem pegou foi olhar a tela.

Teve um caso pior. Depois de um redesenho do Cardápio, uma faixa verde passou a cobrir o topo do cartão branco no carrinho, na finalização e na tela de sucesso. Os oito testes automáticos passaram com o defeito na tela, porque eles conferem a conta e a mensagem, não a aparência. O erro só apareceu no teste do link publicado. O hábito que evita: usar o app como o seu cliente usaria, no celular, depois de cada fase e de novo depois de publicar.

4. Confiar só no olho para as contas

O erro oposto também existe. Tem coisa que o olho não pega. No Preço Certo, a calculadora de preço para confeiteiras, um teste automático falhou com esta mensagem: esperava 46,875 e recebeu 46,88. Com um rendimento quebrado, como uma receita que rende 2,5 unidades, o preço da receita caía no meio do centavo. Na tela, com rendimentos inteiros, tudo parecia certo. Só o teste pegou.

Teste automático é uma pequena conferência que a IA escreve e que roda sozinha em menos de um segundo. Para quem não programa, a regra é simples: as partes que não podem errar nunca, como o total de um pedido ou o preço de um produto, ganham testes. O resto você confere com as mãos. E um teste que sempre passa não prova nada. No Cardápio, a IA estragou a conta de propósito para ver se os testes reclamavam, e dois acusaram na hora. Só depois disso dá para confiar neles.

5. Dizer só "não funcionou"

"Não funcionou, arruma." A IA não sabe o que você viu nem o que você esperava, então ela adivinha. E quando ela adivinha, mexe no que estava bom.

O pedido que corrigiu o aviso vermelho do Cardápio não tinha nenhuma palavra técnica. Contava exatamente o que eu fiz na tela, o que apareceu e o que eu esperava que acontecesse. E pedia para corrigir só aquilo. A IA respondeu que o aviso só sumia quando a pessoa clicava em enviar de novo e mudou para sumir assim que a pessoa mexe no formulário. Um erro por pedido. Testa, e só então o próximo.

Quem não programa tem uma vantagem aqui: descreve o que vê, sem tentar adivinhar a causa. A causa é trabalho da IA. Descrever bem é trabalho seu.

Ensinando programação, eu aprendi que essa é uma das habilidades que mais aceleram um iniciante, e quase ninguém fala dela. Quem aprende a descrever um erro em três partes (o que eu fiz, o que apareceu, o que eu esperava) passa a resolver os problemas bem mais rápido. Vale para pedir ajuda a um colega e vale, mais ainda, para pedir à IA. Um exemplo de pedido bem descrito: "Na tela de finalizar, escolhi Entregar, toquei em Enviar sem endereço e apareceu o aviso vermelho. Depois escrevi o endereço e o aviso continuou. Eu esperava que ele sumisse. Corrija só isso."

6. Não ter como voltar atrás

Você pede uma mudança, ela fica ruim, e o app que funcionava de manhã não existe mais. Sem uma versão guardada, o caminho é pedir para a IA "desfazer", e ela tenta lembrar como era. Às vezes consegue. Às vezes piora.

No Cardápio, eu fiz isso de propósito para a aula: pedi para trocar todo o verde por rosa-choque e deixar os botões bem pequenos. O botão de adicionar caiu para 20 pixels de altura, difícil de acertar com o dedo. Pedi para voltar à última versão guardada, e o app voltou exatamente como estava, com o botão de 49 pixels, sem eu mexer em uma linha. Isso funciona porque cada fase testada foi guardada como uma versão com nome, usando o Git, um programa que guarda fotos do seu projeto. É a coisa que mais dá coragem de mexer no app.

7. Deixar a segurança para depois

"É só um app pequeno, ninguém vai mexer." Os diários mostram três sustos reais, e nenhum deles foi exótico.

O primeiro: o modelo de projeto que a IA usou para criar o app não vinha configurado para esconder o arquivo onde ficam as chaves. Sem um cuidado explícito, a chave poderia ir parar no histórico do projeto. O segundo: no serviço de banco de dados, o cadastro público vem ligado de fábrica. Com ele ligado, qualquer pessoa com a chave pública poderia criar uma conta, ficar logada e alterar o cardápio da lanchonete. E a primeira regra do banco deixava qualquer pessoa logada alterar os dados; o certo era só o dono.

O terceiro foi no Orçamento no Zap, e foi um erro real de privacidade, achado num teste. Quando o profissional A saía da conta e o profissional B entrava no mesmo celular, os dados de A subiam para a conta de B. A correção foi apagar o rascunho e os dados do aparelho ao sair. Ninguém teria percebido sem um teste com duas contas.

Para um app pequeno, um mínimo bem feito e conferido resolve a maior parte dos problemas. E nunca cole senha no chat, nem para a IA: ela não precisa da sua senha para nada.

8. Deixar a IA inventar

A IA quer agradar. Sem uma regra clara, ela coloca "mais de mil clientes satisfeitos" na sua página, ou um depoimento de alguém que não existe. Isso é mentir para quem vai usar o seu app.

Nos três apps, a regra "nunca inventar dados" ficou escrita no documento do projeto desde o primeiro dia. Por isso os lanches, o brigadeiro e os orçamentos que aparecem nas telas vêm marcados como exemplo. Nas páginas de venda, depoimento só entra se for de uma pessoa real, com nome e autorização. Até lá, quem convence são as telas do próprio app funcionando.

9. Achar que todo aviso em inglês é erro

Esse é o erro mais comum de quem nunca viu um terminal. Aparece "Done. Now run", seguido de comandos, e a pessoa acha que precisa digitar alguma coisa. Não precisa: quem roda é a IA. Aparece "LF will be replaced by CRLF" em vinte arquivos, e parece que quebrou tudo. É só um aviso sobre o jeito que o Windows marca o fim das linhas.

O oposto também acontece. No Cardápio, a pasta preparada para publicar foi gerada no Windows com caminhos no formato errado, e o site teria quebrado no ar. Isso foi visto antes de publicar. O hábito: quando não entender uma mensagem, pedir para a IA explicar em linguagem simples se é aviso ou erro, e o que fazer.

Esse medo é muito comum em quem está começando. Um texto vermelho ou amarelo em inglês parece sempre uma bronca, e muita gente para tudo e fica esperando alguém dizer se pode continuar. Na maioria das vezes, era só um aviso. A regra que eu sugiro é ler a última linha da mensagem: se ela diz "error" ou "failed", é erro. Se diz "warning" ou "done", quase sempre dá para seguir. Na dúvida, a IA explica.

10. Publicar e não medir, ou medir errado

O app vai ao ar, você manda o link para algumas pessoas e fica sem saber se alguém usou. Ou pior: abre o painel, vê números e comemora.

Um cuidado que pouca gente lembra: a ferramenta de métricas conta os seus próprios testes como uso real se você não disser a ela quem é interno. Enquanto você constrói, quem mais abre o app é você, testando cada fase. Sem descontar isso, o painel mostra mais movimento do que existe, e você toma decisão em cima de um número inflado.

Medir é decidir antes quais poucas ações importam (no Cardápio: abrir o cardápio, adicionar um item, enviar o pedido) e olhar onde as pessoas desistem. Mil visitas sem ninguém fazendo a ação principal não significam nada.

O que esses erros têm em comum

Repare que nenhum deles pede código melhor. Todos pedem organização: saber se alguém quer, planejar em pedaços pequenos, testar cada pedaço com as mãos e com testes automáticos, guardar versões, cuidar do mínimo de segurança e medir o que importa. É o jeito de um engenheiro de software, e dá para aprender sem programar.

A IA escreve o código. Quem decide como ele é construído é você. Se quiser ver esse jeito aplicado do começo ao fim, com os erros reais aparecendo e sendo corrigidos, é o que eu ensino no Método Micro App. E se você ainda está na fase da ideia, comece pelas 30 ideias de micro apps para negócios locais.

Perguntas frequentes

A IA vai errar no meu app?

Vai. Nos três apps que construí, a IA errou em contas, em telas e até numa regra de privacidade. O que muda o resultado é você ter um jeito de pegar o erro cedo e de voltar atrás quando precisar.

Preciso saber programar para corrigir os erros da IA?

Não. Você precisa ver o erro usando o app, descrever com clareza o que aconteceu e pedir a correção de uma coisa por vez. Quem escreve o código é a IA.

Teste automático serve para quem não programa?

Serve, para as partes que não podem errar nunca, como a conta do total. Você pede que a IA escreva os testes e explique o resultado em linguagem simples. Mas eles não substituem usar o app com as próprias mãos.

Um app pequeno precisa se preocupar com segurança?

Precisa do mínimo. Num dos meus apps, o padrão do serviço de banco de dados permitia que qualquer pessoa com a chave pública criasse uma conta e alterasse o cardápio. Isso só foi fechado porque estava no plano conferir.