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 anti-padrões: soluções que parecem certas e cobram o preço depois. A demonstração esconde os dois, e o primeiro dia de uso revela os dois.

Toda tela que sai de uma conversa com um agente esconde o mesmo risco: o de parecer pronta sem estar. Agente é o assistente de inteligência artificial que escreve o código por você.

Um checklist por família de defeito resolve isso. Ele nomeia o sintoma que aparece na tela, o antídoto que você pede ao agente e a contraprova do que a entrega boa tem.

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.

Outro defeito frequente é a escolha insegura. A Veracode publicou, em julho de 2025, um teste com mais de 100 modelos, em situações montadas para admitir uma saída segura e uma insegura.

O código gerado trouxe falha do OWASP Top 10 em 45% dos casos, e a injeção de conteúdo na página, o XSS, passou de 85% de falha. Por isso 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.

No lado visual, o checklist traz 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. Depois abra a tela a 390 pixels de largura, nos dois temas, e procure os cinco sinais de paleta padrão.

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.

Tirar a cara de IA da tela e medir a cada mudança

O checklist pega o defeito família por família, e a impressão de tela feita por máquina ainda pede medida própria, em dimensões fixas, repetida a cada mudança.

Uma varredura de mil sites declarados como feitos com inteligência artificial deu nota média de 61,4 em 100 na cara de IA. A nota mede o quanto a tela parece saída de máquina, e alta é o lado ruim da escala. Os 200 sites desenhados por agências e marcas ficaram em 24,8.

A distância entre os dois grupos 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.

Deu mediana de 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. 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.

Construir o painel final em três pedidos e conferir antes de publicar

Com a medida e o laço de avaliação de pé, o projeto final pode ser pedido em três etapas: plano de tokens, revisão contra o briefing e construção com autocrítica.

Três pedidos ao agente bastam para um painel responder a uma pergunta só, como quantas turmas abrem no próximo semestre. O agente é o assistente de inteligência artificial que escreve o código por você. 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.

Vale a regra de ouro de 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 plano 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.

Nesse ponto 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.

Por fim, a régua é 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 monte o briefing com conteúdo real. Peça o plano compacto sem código, depois a revisão com a pergunta do briefing parecido.

Só então peça 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.

Guia prático: rodar um detector de antipadrões na página publicada

A nota de cara de IA deste capítulo depende de alguém olhar a tela. Um detector determinístico, programa que aplica sempre as mesmas regras e devolve sempre o mesmo resultado, faz a parte mecânica dessa conferência em segundos e sem gastar crédito de modelo. A skill Impeccable, pacote de instruções de design para agentes como o Claude Code, traz um com 60 regras e roda por linha de comando, sem chave de API.

As regras se dividem em duas famílias. As de qualidade medem o que tem número: contraste abaixo de 4,5 para 1, linha com mais de 80 caracteres, entrelinha abaixo de 1,3, texto de interface menor que 11 px. As de padrão genérico apontam os vícios de tela gerada: cartão dentro de cartão, gradiente ciano ou roxo, borda colorida grossa num lado só, rótulo pequeno em caixa alta acima do título.

O detector entrega evidência, e a decisão continua sendo sua. Rodado na página deste curso em 06/10/2026, ele devolveu 307 achados. Dos 104 de contraste, 96 repetiam a mesma leitura: texto e fundo com a mesma cor, 1,0 para 1. Aberta no navegador, a página não tinha nenhum elemento com aquele cinza de fundo. O programa leu o fundo errado 96 vezes, e quem aceitasse o total sem conferir sairia corrigindo um defeito que não existe.

Na página deste curso, a triagem ficou assim. Entraram na pilha de defeitos os 49 parágrafos com linha acima de 80 caracteres, as etiquetas de 10 px e o texto justificado sem hifenização do bloco do e-book, que abre buracos entre as palavras em tela estreita. O bloco do e-book ganhou hifenização automática no mesmo dia e continuou justificado, como o restante do portal. O gradiente ciano e os rótulos acima dos títulos ficaram na pilha de estilo, e os 96 contrastes de 1,0 para 1 na de leitura errada.

Guia prático: auditor que não editou e nada na tela sem aprovação

Quem fez a página não enxerga os próprios erros, e com agente acontece o mesmo. No curso de edição de vídeo estudado em 07/10/2026, a primeira entrega do vídeo longo saiu com 150 erros. A partir daí, cada capítulo passou por um auditor independente, um agente que não editou nada, só lista o problema com prova e gravidade e propõe a correção. Ele encontrou de 9 a 17 erros por capítulo que o editor tinha dado como prontos.

A regra de conteúdo do mesmo curso vale para página: nada na tela que a pessoa não disse ou não aprovou. Número, nome e marca só aparecem se vieram dela. Quando o tema é de terceiros, entra o material real, como o logo oficial ou o número consultado na fonte, e a origem de cada item vai para um arquivo de entrega junto do trabalho, que lá se chama EDICAO.md.

O terceiro hábito é conferir por script o que o lint não vê. Um verificador abre a página, avança a animação de 0,2 em 0,2 segundo e mede cada caixa: texto cortado, caixa sobre caixa, texto pequeno demais. O material registra o tropeço que motivou isso: um ajudante marcou todo bloco como sobreposição permitida e deixou a checagem cega.