Como revisar um site feito com IA antes de publicar

Uma IA cria em minutos uma landing page ou um formulário que parece pronto. Essa velocidade é a vantagem do vibe coding, mas também facilita confundir uma boa prévia com um produto pronto. Um site pode estar impecável e ainda ter links errados, dados que somem, erros sem explicação ou uma ação de servidor que confia em valores alteráveis.

Este controle de publicação usa como exemplo a inscrição num workshop. A pessoa escolhe uma sessão, escreve nome e e-mail e recebe uma confirmação. Sete controles separam o rascunho gerado de uma versão que você pode publicar com responsabilidade. Cada um exige uma prova observável, não a frase «deveria funcionar».

1. Fixe o resultado e o escopo antes de testar

Escreva uma frase com o resultado obrigatório: «No celular e no desktop, uma pessoa interessada consegue escolher um workshop disponível, enviar dados de contato válidos e receber uma confirmação inequívoca». Acrescente o que não faz parte desta versão, por exemplo pagamentos, conta de usuário ou sincronização de calendário.

Esse limite evita que a IA acrescente funções durante a revisão e altere o que já funcionava. Um prompt bem delimitado também indica a área afetada, o que deve permanecer igual e os critérios de aceitação. Guarde o estado inicial no controle de versões ou como uma prévia nomeada para identificar exatamente o que foi testado.

2. Percorra o caminho principal num navegador real

Abra o site como visitante, não só como quem lê o código. Comece na entrada pública, navegue até a inscrição, escolha uma sessão, preencha o formulário e confira o resultado. Repita depois de recarregar e com uma tela estreita. Links, foco, espera e confirmação fazem parte do percurso.

O Playwright recomenda testar o comportamento visível para quem usa. Localize um botão pelo seu papel e nome acessível e verifique a mensagem de sucesso visível. Uma classe CSS interna não prova que alguém consegue encontrar ou entender a ação.

O caso correto não basta. Teste no mínimo um estado vazio, uma entrada inválida e uma falha técnica:

• Sem sessões: a página explica a situação e oferece um próximo passo útil.
• E-mail incorreto: o campo recebe uma explicação compreensível e mantém o foco.
• Clique duplo ou rede lenta: a inscrição não é salva duas vezes.
• Servidor sem resposta: os dados não somem em silêncio nem se finge sucesso.

3. Proteja os dois lados do formulário

Tipos de campo do HTML, required, limites razoáveis e resposta imediata ajudam a corrigir erros. A MDN lembra que a validação no cliente não é uma medida de segurança completa, porque uma requisição pode contornar a interface. O servidor precisa impor separadamente os mesmos limites de negócio.

Na inscrição, o servidor aceita apenas identificadores de sessões reais, limita o tamanho dos campos, normaliza o e-mail de forma consciente e recusa dados inesperados. Ele também confirma que ainda há vaga. Um valor oculto no formulário não é uma autorização.

Desenhe o caminho dos dados: o que sai do navegador, onde é guardado, quem pode ler e quando é apagado. Se a IA não conseguir tirar uma resposta clara do código e da configuração, ainda existe um risco em aberto.

4. Verifique teclado, semântica e mensagens

O WCAG oferece um padrão comum para conteúdo web mais acessível. Você não precisa decorá-lo inteiro para uma publicação pequena, mas o percurso principal precisa ser compreensível e utilizável sem mouse. Navegue com Tab, Shift+Tab, Enter e Espaço. O foco não pode sumir nem ficar atrás de um diálogo.

Confira rótulos visíveis, ordem dos títulos, contraste, alternativas de imagem e mensagens de estado. Amplie para 200 por cento e use uma tela estreita. Uma auditoria automática encontra muitos problemas básicos, mas não substitui o teste de teclado nem uma revisão breve com leitor de tela ou com pessoas.

5. Inspecione os limites de segurança

A OWASP agrupa riscos web recorrentes como controle de acesso quebrado, má configuração, falhas na cadeia de suprimentos e injeção. Transforme essas categorias em perguntas concretas. Alguém consegue ler inscrições de terceiros? Há um segredo dentro do pacote do navegador? O servidor confia num papel enviado pelo formulário? Pacotes externos e variáveis de ambiente estão sob controle?

Peça à IA que aponte primeiro provas e locais antes de mudar qualquer coisa. Autenticação, pagamentos, informação de saúde ou outros dados sensíveis merecem uma revisão experiente. Código gerado não é inseguro por definição, mas sua aparência convincente pode esconder suposições não verificadas.

6. Meça o desempenho em dispositivos relevantes

O web.dev apresenta LCP, INP e CLS como Core Web Vitals estáveis para carregamento, resposta e estabilidade visual. São sinais úteis, não um botão universal de aprovação. Meça a página real, com imagens, fontes, scripts e serviços externos de produção.

Teste ao menos um celular representativo, uma conexão limitada e um navegador de desktop usado pelo seu público. Observe a imagem principal, scripts que bloqueiam, controles lentos e saltos durante o carregamento. Defina um orçamento pequeno, como tamanhos máximos de imagem e nenhuma dependência externa bloqueante sem justificativa.

7. Prepare aprovação, observação e reversão

Antes de publicar responda três perguntas: quem aprova? que sinais mostrarão uma falha? como a versão anterior é recuperada? Uma prévia controlada serve para a última revisão quando o público e os dados do formulário são escolhidos conscientemente.

Publique uma versão concreta e testada, não um vago «estado atual». Depois confira a URL pública, o percurso principal, os erros de servidor e os eventos reais de envio. A volta atrás só é confiável quando a versão de destino, a pessoa responsável e o procedimento são conhecidos.

Lista compacta para publicar

• Objetivo, exclusões e versão testada estão registrados.
• Caso correto, estado vazio, entrada inválida e falha de servidor foram testados no navegador.
• Cliente e servidor validam; permissões e caminho dos dados são compreensíveis.
• O percurso funciona com teclado, ampliação e um celular relevante.
• Segredos, variáveis de ambiente, dependências e pontos públicos foram revisados.
• O desempenho foi medido com recursos reais e regressões críticas foram corrigidas.
• Aprovação, observação e volta atrás têm uma pessoa responsável.

Estes controles não existem para tirar a velocidade do trabalho assistido por IA. Eles protegem a vantagem real dela: ir rápido de uma ideia a um produto útil cujo comportamento você consegue explicar e assumir. Quando faltar uma prova, transforme essa ausência na próxima tarefa delimitada. A iteração continua rápida sem transformar a publicação numa aposta.