Construir o projeto final, medir a cara de IA e revisar

Um gráfico que some no tema escuro e um filtro que volta ao padrão a cada recarga são defeitos que a demonstração esconde e o primeiro dia de uso revela.

Toda tela que sai de uma conversa com um agente (o assistente de inteligência artificial que escreve código por você) esconde o mesmo risco, o de parecer pronta sem estar. Um checklist por família de defeito nomeia o sintoma que aparece na tela, o antídoto que você pede ao agente e a contraprova do que a entrega boa tem antes de publicar.

Os defeitos de código vêm primeiro porque não aparecem na tela. A key pelo índice (o crachá que o React dá a cada item) prende a marcação ao lugar: ordene a lista e o destaque cai em outro produto. O antídoto é o identificador do próprio dado como crachá.

A biblioteca inventada (o pacote pronto que o agente importa) soa real e não existe no registro público: roda na sua máquina e quebra na reinstalação do zero. O terceiro é aceitar código sem ler: funcionou, mas ninguém explica por quê. Peça a explicação de cada trecho que não for óbvio e confirme cada dependência nova no registro do npm.

A escolha insegura é frequente. A Veracode publicou, em julho de 2025, um teste com mais de 100 modelos e 80 tarefas montadas para admitir uma saída segura e uma insegura. O código gerado trouxe falha do OWASP Top 10 em 45% dos casos. A injeção de conteúdo na página, o XSS, passou de 85% de falha. Todo trecho que injeta conteúdo dinâmico entra na revisão manual.

As famílias de dado e gráfico são as que mais enganam quem aprova, porque a tela impressiona. Um painel com 40 indicadores e nenhuma decisão é bonito na demonstração e ninguém abre na segunda semana. Drill-down (abrir o número em partes) infinito no relatório de conselho e métrica sem fonte, meta, base de comparação ou dono são a mesma doença.

Velocímetro para tudo, pizza com muitas fatias e 3D decorativo impressionam sem esclarecer. No relatório de marketing, faltar custo de aquisição, prazo de retorno, incrementalidade e qualidade do funil transforma o relatório em enfeite. O BI embutido (o painel de outro sistema colado na sua tela) sem camada de narrativa deixa o leitor sozinho com os gráficos.

As famílias técnicas dão sintoma na tela. Markdown cru (texto com marcas de asterisco e cerca) dentro do HTML quebra no celular; peça pre ou tabela. Gráfico em caixa oculta ou de largura zero aparece em branco, sem erro; SVG chamado como imagem ignora as cores do tema e some no escuro.

Classe do Tailwind (as classes utilitárias de estilo) montada por concatenação some no build, porque o compilador só enxerga texto literal. Conexão aberta sem fila de mensagens trava a tela quando o servidor acelera. PDF gerado de forma síncrona derruba o servidor em produção, e fonte remota num documento confidencial avisa o Google de que ele foi aberto.

O rótulo de menu de aplicativo numa navegação simples confunde o teclado. Aba, filtro e paginação fora do endereço da página se perdem ao recarregar, e a rolagem infinita apaga o rodapé que buscador e leitor de tela precisam.

A contraprova é o que a entrega boa tem, pelas regras de ouro do manual. O relatório de conselho é um painel de decisão e o de marketing, um painel de crescimento, nunca a mesma tela. Quem lê descobre fonte, definição, data e dono de cada número em dois cliques, e a lógica da métrica vive em código versionado.

A parte visual do checklist são as cinco caras de tela gerada que a skill frontend-design (o roteiro de design do agente) lista para se calibrar. Nenhuma é proibida; todas são padrão em vez de escolha.

Se o seu pedido fixou o visual, ele vence; se deixou o eixo livre, a liberdade não pode ir para um padrão. Você confere procurando os cinco sinais na tela e os dois hexadecimais no código.

Antes de publicar qualquer tela construída por vibecoding, confira cada pacote novo no registro do npm e abra a tela a 390 pixels nos dois temas. Procure os cinco sinais de paleta padrão no código e corrija cada linha marcada com o antídoto da tabela. Só aprove quando um número qualquer da tela chegar à fonte, à definição e ao dono em dois cliques.

Medir a cara de IA: sete dimensões e o laço de avaliação

Uma varredura de mil sites declarados como feitos com inteligência artificial, entre janeiro e março de 2026, deu nota média de 61,4 em 100 na cara de IA. Os 200 sites desenhados por agências e marcas ficaram em 24,8, e nota alta é o lado ruim da escala. A distância mede sete dimensões: cor, tipografia, espaçamento, layout, padrões de componente, decoração e estrutura de conteúdo.

Uma tabela com número em cada dimensão mede o quanto uma tela ainda parece gerada antes de ela ir ao ar. Um laço de avaliação, a rotina que repete o mesmo teste a cada mudança, como a prova do forno, confirma se a correção pegou.

A distância é maior onde o olho bate primeiro. Em tipografia, a média dos sites gerados foi 66,7 contra 19,4 dos profissionais; em cor, 68,3 contra 22,1. Em estrutura de conteúdo a diferença encolhe (44,3 contra 25,1). O modelo acerta o HTML semântico (a marcação que diz o que cada trecho é) e erra o visual.

Os padrões andam em bando: o site mediano trazia nove dos 20 sinais mais frequentes, e a média piorou de 58,2 para 61,4 em seis meses. As cinco caras da aula anterior seguem como primeira olhada; a tabela põe número em cada dimensão e diz o que pedir.

A ferramenta pesa menos que a restrição. Em março de 2026, o mesmo pedido (a landing page de uma ferramenta de commit) rodou em seis ferramentas, cinco vezes cada.

A mediana foi 92 no v0, 88 no Bolt, 84 no Lovable, 76 no Cursor e 69 no Claude Code. O último lê a skill de design (o roteiro visual do agente) e foi o menos marcado.

Um gerador com sistema procedural ficou em 24. O que separa 92 de 24 é a restrição que tira o modelo do atrator, a saída mais provável para onde ele volta se ninguém o segura. A capacidade era a mesma.

O contraste é a falha que a máquina deixa passar. O WebAIM Million de fevereiro de 2024 mediu um milhão de páginas iniciais. Delas, 95,9% tinham falha detectável da WCAG (a norma de acessibilidade da web), com média de 56,8 erros por página. Baixo contraste apareceu em cerca de 81%.

Ferramenta automática cobre de 30% a 40% dos critérios de sucesso. Os 57% que a Deque publica medem volume de problemas encontrados, que é outra conta, e somar os dois números é o erro mais comum em relatório de conformidade.

Meça na página renderizada, e não na folha de estilo. O que importa é o contraste que sobrou depois da cascata (a soma das regras de estilo que a página aplica). Texto corrido pede 4,5:1, e componente de interface, como a borda do campo, pede 3:1 pelo critério 1.4.11. Gere e depois verifique, nessa ordem.

A defesa que dura é o laço de avaliação com cenários congelados. A Vercel mantém sete cenários fixos: mesmo pedido, mesmos dados falsos, mesma janela. Todos rodam a cada mudança do design.md (o sistema de design escrito para o agente ler), em Claude Opus 4.8 e em Codex com GPT-5.5.

Pessoas julgam hierarquia, composição e se a página entrega o que o leitor veio buscar. Checagens automáticas pegam a falha mecânica, como a tabela que ignora a largura.

Cada correção aceita vai para o lugar mais estreito: julgamento vira prosa no design.md, mecânica repetível vira CSS, o que dá para checar vira teste. Pedido novo vira cenário novo. O arquivo nomeia os padrões gerados que a empresa nunca quer ver, porque o nome faz o agente reconhecê-los.

Duas medições cabem antes do código. A skill frontend-design manda revisar o plano contra o briefing com o teste do prompt vizinho. Se um pedido parecido daria o mesmo plano, o plano era default. Depois da tela pronta, a autocrítica com print e a regra de tirar um acessório fecham a rodada.

Montar componentes de um sistema é o que a IA já faz. Gosto curado, pesquisa e julgamento são o que resiste, e o laço guarda isso em cenário, nota e correção registrada.

Escolha três telas reais do seu projeto e guarde o pedido completo e os dados de exemplo de cada uma num arquivo fixo. Ajustar o pedido a cada rodada esconde se a melhora veio do sistema ou da sorte.

Gere as três sem retoque manual e marque os sinais das sete dimensões e o contraste na página renderizada, nos dois temas. Registre cada correção no lugar mais estreito, prosa no sistema de design, regra mecânica no CSS, checagem repetível em teste, antes de regenerar e comparar as contagens.

O projeto final em três pedidos, com plano, revisão e autocrítica

Três pedidos ao agente (o assistente de inteligência artificial que codifica por você) bastam para um painel responder a uma pergunta só, como quantas turmas abrem no próximo semestre. Plano, revisão contra o briefing e construção com autocrítica são as três etapas.

A revisão é o que pega o fundo creme com terracota que qualquer briefing genérico daria e o troca pela cor da marca. Uma tela que passa pelas dez perguntas de triagem antes de publicar nasce dessa mesma sequência de três pedidos.

A regra de ouro é uma decisão por tela. Antes do primeiro pedido, escreva qual decisão aquela tela ajuda a tomar. Um painel que existe para responder "vou bater a meta do mês" precisa de poucos números certos; cada número a mais disputa atenção com a decisão.

Escreva também o briefing (o pedido com o que a tela faz, para quem e com que conteúdo real). A skill frontend-design (o roteiro de design do agente) manda identificar assunto, público e trabalho principal da tela antes de desenhar, e confirmar com você. Tela desenhada com conteúdo de mentira vira template.

O primeiro pedido produz só o plano compacto, sem código. Cor: quatro a seis hexadecimais com nome, cada um deles um token (o valor da cor guardado com nome, como a etiqueta na lata de tinta). Tipografia: uma ou duas famílias e o papel de cada uma.

Layout: o conceito numa frase, um wireframe em texto (o esboço em caixas, como a planta baixa da loja) e o alinhamento, à esquerda, centrado ou justificado. Princípios: o que torna esta tela diferente de qualquer outra. Pedir o gráfico antes desse plano obriga a refazer o gráfico depois, porque a cor e a grade mudam.

O segundo pedido revisa o plano contra o briefing com uma pergunta: um briefing parecido daria o mesmo resultado? O agente refaz o exercício com um pedido semelhante e, onde chega ao mesmo lugar, aquela parte é padrão em vez de escolha. Ele troca essa parte e diz o que mudou e por quê.

Onde o seu briefing fixou o visual, ele vence, mesmo quando pede uma das cinco caras genéricas da aula anterior. Onde deixou o eixo livre, a liberdade não pode ir para um padrão. Só depois dessa revisão o agente escreve código, seguindo o plano revisado e cuidando da especificidade dos seletores de CSS para uma regra não anular a outra.

O terceiro pedido constrói e se autocritica. Ousadia num lugar só: um elemento memorável, tudo ao redor quieto, e um enfeite a menos antes de entregar. O piso de qualidade entra sem anúncio: responsivo até o celular, foco visível no teclado, menos movimento respeitado, contraste nos dois temas.

O agente tira o print da tela e olha para ele antes de responder, porque uma imagem vale mil tokens de descrição. Dentro desse pedido ficam as três partes do painel.

A fundação traz as cores dos dois temas e a pergunta; os cartões, a tendência marcada por ícone e por palavra. O gráfico tem largura e altura definidas no contêiner e cor própria em cada texto, porque caixa de largura zero aparece em branco, sem erro.

A régua final é o checklist de dez perguntas do manual, antes de publicar. Cada resposta aponta uma ferramenta: SEO real (aparecer na busca) pede meta-framework, poucos elementos ricos pedem SVG, milhares de redesenhos pedem Canvas. A décima é a mais esquecida: orçamento e medição entram no primeiro sprint, e a tela que chega sem eles volta ao plano.

Antes de escrever o primeiro pedido, fixe a pergunta que a tela responde e o briefing com conteúdo real. Peça o plano compacto sem código, depois a revisão com a pergunta do briefing parecido, e só então a construção com print e autocrítica. Passe as dez perguntas de triagem e volte ao plano em qualquer resposta que aponte para outra ferramenta.