Confira seu App Feito com IA Antes de Receber Clientes

Comece pelo mesmo endereço público usado pelo cliente. Abra o app em uma nova janela anônima para que uma entrada antiga na conta não altere o teste. Visite a apresentação, a entrada da conta, a área do cliente, as telas de pagamento, os formulários, os arquivos e a ajuda. Use dados fictícios e seguros para acionar cada botão importante. Anote o que cada ação deveria mostrar, salvar, enviar, apagar ou cobrar. Assim, você cria um mapa visível antes de examinar como o app foi construído.

Por que isso importa? Ferramentas de IA podem deixar uma tela antiga, um formulário incompleto ou um botão que ainda executa uma ação real. Uma tela não fica inofensiva só porque saiu do menu. O nome técnico do conjunto de lugares onde alguém pode interagir com o app é superfície de ataque. Você não precisa decorar o termo. A ideia útil é que cada tela ou ação alcançável precisa ter uma finalidade, um resultado esperado e uma verificação de quem deveria poder usá-la.

Crie duas contas de teste, como Ana e Bruno, e coloque nelas agendamentos, documentos e perfis fictícios bem diferentes. Entre como Ana e tente cada ação comum: ver um cadastro, editar, apagar e baixar, quando houver essa opção. Saia, repita tudo como Bruno e confirme que os dados de Ana nunca aparecem. Tente também abrir uma tela administrativa usando uma conta comum. Trabalhe somente com informações inventadas, nunca com cadastros de clientes reais.

Entrar na conta mostra quem está usando o app, mas isso não prova automaticamente que a pessoa pode usar qualquer cadastro. O app precisa conferir a pessoa e o item solicitado juntos sempre que alguém consulta ou altera informações. O nome técnico dessa decisão é autorização. Esconder um botão não basta, pois a mesma ação pode ser alcançada de outra maneira. Peça à ferramenta de IA que explique a regra para cada cadastro, pedido, arquivo e tarefa administrativa e que crie testes repetíveis para essas regras.

Acompanhe o que acontece quando alguém inicia um pagamento, cancela, conclui, atualiza a tela ou fecha a janela. Use o modo de teste da empresa de pagamento, quando estiver disponível. Um recurso pago deve continuar bloqueado até essa empresa confirmar que o pagamento deu certo. O mesmo cuidado vale quando o app envia email, troca uma senha ou recebe um formulário: mensagens atrasadas ou repetidas não devem criar pedidos, recibos, créditos ou alterações de conta em duplicidade.

Empresas de pagamento e outros serviços costumam mandar um aviso automático ao app depois de um acontecimento. O nome técnico desse aviso é webhook. O app deve confirmar de onde ele veio e reconhecer com segurança um aviso já processado. O nome técnico da capacidade de receber a repetição sem duplicar o resultado é idempotência. Ações que custam dinheiro ou podem ser repetidas rapidamente também precisam de limites razoáveis de uso. O nome técnico de um desses limites é rate limit. Ele ajuda a reduzir repetições acidentais, cliques insistentes e uso automático indevido.

Confira os arquivos e as configurações enviados quando alguém abre o app público. Mesmo que o conteúdo não apareça na tela, o navegador pode recebê-lo e guardá-lo. Uma senha do banco de dados pode abrir informações de clientes. Uma chave de pagamento pode criar cobranças ou reembolsos. Um código de acesso ao serviço de email pode enviar mensagens pela sua conta. Um código de armazenamento pode abrir documentos enviados por clientes. Esses itens precisam ficar na parte protegida do app que trabalha longe do aparelho do visitante.

Uma senha ou chave que prova que o app pode usar outro serviço tem um nome técnico: credencial. Alguns profissionais também chamam credenciais muito poderosas de segredos. Configurações públicas, como o nome exibido da empresa, são diferentes, mas peça à ferramenta de IA que classifique cada item em vez de adivinhar. Se uma senha poderosa, chave de pagamento ou código de acesso chegou aos arquivos do visitante, apenas movê-lo não resolve tudo. Crie um substituto, atualize a configuração protegida, desative o item antigo e teste novamente o serviço relacionado.

Antes de pedir uma mudança, escreva o que precisa continuar verdadeiro. Por exemplo: clientes veem apenas os próprios agendamentos, o acesso pago depende de pagamento confirmado e visitantes não baixam uma senha do banco de dados ou chave de pagamento. Guarde uma versão que funciona e registre como voltar a ela. Peça uma mudança de cada vez. Quando a ferramenta de IA terminar, solicite uma explicação do que mudou, das telas ou ações que podem ter sido afetadas e das verificações anteriores que precisam ser repetidas.

Mantenha uma anotação curta com data, mudança pedida, contas de teste, telas conferidas e resultados. O nome técnico de repetir verificações que já funcionavam é teste de regressão. Essa rotina deve continuar enquanto o app mudar. O VibeCodeWall confere o app público por fora e acompanha mudanças importantes ao longo do tempo. Ele não precisa acessar o código que não é entregue publicamente. Essa visão externa complementa, mas não substitui, seus testes com duas contas, pagamentos, senhas, chaves e códigos de acesso.