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.

Revisar identidade visual e defeitos a cada mudança

A revisão combina critérios observáveis com julgamento de design. Separe falhas de leitura, acessibilidade e funcionamento das preferências visuais do briefing.

Cor, fonte ou formato de cartão não demonstram se uma página foi criada por pessoa ou por inteligência artificial. Para avaliar a entrega, guarde a versão, o briefing, os dados de exemplo e as capturas nos tamanhos combinados.

Use sete dimensões como roteiro de observação: cor, tipografia, espaçamento, layout, componentes, decoração e conteúdo. Em cada uma, registre o elemento, o problema encontrado e a correção proposta.

Uma observação útil aponta algo que outra pessoa consegue conferir: “o título usa uma fonte fora do sistema” ou “o botão perde contraste no tema escuro”. Depois da correção, repita o mesmo cenário e compare a mesma região da tela.

Comece pela tarefa principal. A pessoa entende o que deve fazer? O título e o botão ajudam essa decisão? Só então avalie as escolhas de aparência. Uma paleta comum pode estar correta para a marca; uma composição original pode continuar ilegível.

Registre preferência e defeito em campos separados. “Prefiro outra fonte” pede uma decisão de design. “O texto foi cortado a 390 pixels” descreve um problema reproduzível.

Para testar se uma orientação melhorou o resultado, mantenha pedido, dados, largura e modelo constantes e altere uma condição de cada vez. Guarde todas as tentativas, inclusive as que falharam. Uma comparação visual só sustenta conclusões sobre os cenários e versões que foram avaliados.

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.

Um processo útil é repetir a avaliação com cenários fixos. No caso publicado em 31 de agosto de 2026, 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 revisõ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 revisão com captura, quando disponível, identifica o que merece ajuste. Remover um enfeite é uma sugestão de design, não uma regra de aprovação.

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 etapas de pedido ajudam a construir um painel voltado a uma pergunta, 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. As dez perguntas de triagem organizam a revisão antes de publicar; o resultado ainda precisa ser testado.

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 dos números certos em ordem: a decisão no topo e o detalhe embaixo. Número que não ajuda a decidir disputa atenção e sai.

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. As verificações exigidas são: responsivo até o celular, foco visível no teclado, menos movimento respeitado, contraste nos dois temas.

Nesse ponto, quando tem acesso ao navegador, o agente captura e revisa a aplicação. Se a captura não foi possível, registre a revisão visual pendente; não declare aprovação apenas pela leitura do código. 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: conteúdo de busca pede atenção ao HTML entregue e à renderização, 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 que você aprendeu a dar 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.

O que mudou de agosto a outubro de 2026

Em 31/08/2026, o time de design da Vercel publicou como seus agentes constroem páginas que precisam parecer Vercel. A skill de design interna só funciona dentro dos repositórios, e relatórios, propostas e páginas avulsas ficavam de fora. A resposta foi um arquivo design.md público, que qualquer agente carrega. A Impeccable, ferramenta usada aqui, deu nome aos defeitos típicos da tela gerada.