Frontends com Vibecoding · Capítulo 2 de 30 · 15 min
Dirigir o prompt e avaliar a entrega do agente
Você sai com uma entrega que integra referência, primeira versão, comparação e aceite.
Este capítulo faz parte do curso gratuito Frontends com Vibecoding. Para marcar como concluído e salvar o progresso, abra este capítulo na página do curso.
Escrever "um cartão bonito e moderno" deixa o agente de IA escolher por você, e ele escolhe a média de tudo que já viu. Uma âncora, a referência concreta anexada ao pedido, troca esse adjetivo por evidência e corta rodadas de correção.
Sobre o briefing já escrito, o pedido ganha uma âncora e uma lista de escolhas exigida antes do código. A entrega só é aceita com um print conferido e uma conferência final feita por lista fixa de itens.
A captura mostra o arranjo, nunca as regras. Escreva ao lado dela quatro linhas curtas: o dado que muda, o estado que faltou, a cor certa e o que ignorar, como a barra do navegador.
Antes do código, peça ao agente a lista das escolhas: paleta, tipo de letra, arranjo e o motivo de cada uma. A skill frontend-design (o roteiro de projeto visual que o agente lê) manda comparar esse plano com o briefing. Toda escolha que ele faria para qualquer página parecida é trocada, e ele diz o que trocou e por quê.
A lista é o seu ponto de veto barato. Uma cor errada custa uma linha de resposta; a mesma cor espalhada em 20 arquivos custa uma tarde.
Exija o print da tela antes da entrega. A mesma skill manda o agente tirar a captura e criticar o próprio trabalho, porque uma imagem vale mil tokens (as unidades de texto que ele cobra). Na captura ele enxerga o botão cortado e o cinza ilegível que o código sozinho esconde.
Peça dois prints, celular e computador, nos temas claro e escuro, e a frase do que ele tirou depois de olhar. O conselho de Coco Chanel, citado na skill, resume o gesto: antes de sair de casa, olhe no espelho e tire um acessório.
Um ajuste por vez é a regra dos pedidos seguintes: contraste, depois estado, depois densidade. Pedidos juntos voltam num bloco grande, difícil de conferir, e um erro numa parte derruba a confiança no conjunto inteiro. Cada resposta negativa da conferência vira um pedido de uma linha sobre o ponto exato que faltou.
O contraste tem dois pisos, e o segundo é o esquecido. O critério 1.4.3 da WCAG pede 4,5:1 no texto normal e 3:1 no texto grande, que começa em 18 pontos, ou 14 em negrito.
O critério 1.4.11 pede 3:1 no componente de interface e no elemento gráfico essencial: a borda do campo, o anel de foco e o ícone que carrega sentido. Medir só o texto aprova uma tela em que ninguém acha onde clicar.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Lista de conferência de quem aprova: o que abrir, onde clicar, o que medir
| O que conferir | O que abrir | Onde clicar | O que medir ou ver |
|---|---|---|---|
| Os quatro estados | A tela no navegador do celular | Sem dados, com a internet desligada, durante o carregamento e no fim | Uma mensagem própria em cada estado, sem tela branca |
| Contraste do texto e do componente | A ferramenta de inspeção do navegador (F12), aba de acessibilidade | No preço, no texto menor, na borda do campo e no anel de foco | 4,5:1 ou mais no texto normal e 3:1 na borda, no anel e no ícone com sentido |
| Teclado | A mesma tela, sem mouse | Tab até o botão principal e Enter | O foco aparece em todo elemento e chega ao botão de comprar |
| Fidelidade à âncora e ao briefing | A captura de referência ao lado da tela nova | Nos eixos fixos: cor, fonte e fundo | Nenhum eixo fixo trocado; nenhum padrão genérico nos livres |
| Print e lista de escolhas | A resposta do agente | Na captura enviada e na lista de motivos | Print nos dois temas e um motivo por escolha; a falta de um dos dois devolve a entrega |
Confira na ordem da tabela; cada linha reprovada vira um pedido de uma linha.
Fonte: Lista do autor; contraste e teclado herdados da versão de 27/08/2026 desta aula, print e lista de escolhas vindos da skill frontend-design.
A regra de dizer o que ignorar na âncora aparece na vitrine online de uma loja de roupas. A foto de referência traz sombra, cursor e barra do navegador, e o agente copia os três quando o pedido não os exclui.
A mesma foto só mostra o estado de sucesso, com a arara cheia, e por isso o pedido nomeia à parte o estado "sem estoque".
Antes de enviar o pedido, anexe uma captura de referência com as quatro linhas do que muda. Peça a lista de escolhas com motivo e vete por escrito o que parecer feito para qualquer página.
Exija o print nos dois temas e a frase de autocrítica do agente, depois confira na ordem da tabela: estados, contraste de 4,5:1, teclado, fidelidade ao briefing e print. Libere a publicação só com cinco respostas positivas, e peça os ajustes um de cada vez.
O critério de aceite quando o agente confere a própria tela
O agente abre a própria página, testa em vários tamanhos de tela e corrige antes de devolver. Essa rotina reduz a revisão humana a quatro itens sem medição pública: contraste, teclado, tela estreita e fidelidade ao real.
Essa mudança desloca o que você escreve no briefing, do como implementar para o resultado observável, e redefine o que continua sendo sua responsabilidade na aprovação.
Dar ao modelo uma ferramenta de navegador aumenta muito a chance de a entrega vir polida e completa. Ele inspeciona a página renderizada, percorre fluxos, detecta erro de estado e compara com a referência que você anexou.
A consequência prática é que o pedido deixa de ser sobre código e passa a ser sobre resultado observável. Escreva o que precisa estar funcionando, e não como implementar.
Três instruções mudam mais o resultado que qualquer outra. A primeira é o viés para a ação: trate um pedido como ordem de executar e siga até o objetivo, sem parar para pedir confirmação em passo reversível.
A segunda define o que é pronto. A terceira diz onde o modelo pode agir sozinho e onde precisa da sua aprovação, que deve chegar sobre um resultado concreto já revisável.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Arquivo de instrução longo virou peso. Quem trabalha na ferramenta de desenvolvimento da OpenAI publicou em 4 de setembro de 2026 que receita rígida passo a passo prende o modelo novo.
Lembrete do tipo seja cuidadoso e teste tudo de novo gera trabalho redundante, porque ele já testa por conta própria. O que ajuda é definir o resultado esperado e a fronteira de autonomia.
Há um sinal simples de que o seu briefing envelheceu. Se o agente pede permissão para corrigir um erro de digitação, a instrução ainda está escrita para o modelo anterior. O que era proteção virou trava, e o conserto é apagar a linha.
O que o agente não confere continua com você, e a lista é curta. Não existe medição pública de contraste, de leitor de tela ou de comportamento em tela estreita para páginas geradas por esses modelos.
Fidelidade também é sua. Quando a peça representa algo real, um imóvel, um produto ou um equipamento, alguém confere contra a fonte. O modelo preenche lacuna com o que é plausível, e plausível às vezes é falso.
Esses quatro itens cabem numa folha e numa reunião de dez minutos. Escreva cada um como pergunta de sim ou não, para que a aprovação pare de depender de gosto.
Trocar de modelo não resolve o que sobra com você. A Veracode comparou dois anos de modelos no relatório GenAI Code Security, de julho de 2025, e os mais novos e maiores melhoraram sintaxe e taxa de compilação sem melhorar segurança.
O corte que interessa a quem faz tela vem do mesmo relatório. Foram mais de 100 modelos e 80 tarefas, cada uma construída para permitir uma escolha segura e uma insegura. O código saiu com falha do OWASP Top 10 em 45% dos casos, e o cross-site scripting passou de 85% de falha. É a classe que aparece justamente em interface que injeta conteúdo na hora.
Há um ponto de calibragem que surpreende quem vem do modelo anterior. Em página simples, pedir o esforço máximo piora o resultado.
Num teste de tela de acesso publicado em setembro de 2026, o esforço no topo produziu rótulos repetidos e comandos duplicados numa tela que pedia simplicidade. Mais raciocínio virou mais elemento, e a clareza caiu.
Comece em esforço baixo ou médio para página de formulário, de acesso e de listagem. Guarde o esforço alto para tela em que a aparência decide a venda, e mesmo assim compare as duas saídas antes de aprovar.
Uma clínica que vai refazer a página de agendamento escreve o aceite em quatro linhas. O horário aparece em três toques no celular e o formulário envia só com o teclado. O contraste passa na ferramenta e o telefone da recepção confere com o cadastro. Com as quatro escritas, a aprovação deixa de ser conversa.
Antes de aprovar a próxima tela, escreva uma frase que descreva o resultado observável sem citar tecnologia. Dê ao agente a ferramenta de navegador e declare o que ele faz sozinho, o que exige sua aprovação e o que nunca deve fazer sem você.
Corte do briefing a receita passo a passo e o lembrete de cuidado, e confira pessoalmente os quatro itens sem medição pública: contraste, teclado, tela estreita e fidelidade ao que existe de verdade.
Todos os capítulos de Frontends com Vibecoding
- 01Projetar o briefing, o repertório da marca e o custo de manter
- 02Dirigir o prompt e avaliar a entrega do agente
- 03Escolher a stack e projetar suas dependências
- 04Investigar uma stack e priorizar atualizações
- 05Construir a identidade com tokens, CSS moderno e DESIGN.md
- 06Construir componentes, usar o registro e publicar o catálogo
- 07Projetar uma linguagem de ícones e ilustração
- 08Projetar menus, popovers e modais acessíveis
- 09Adaptar o layout ao celular e ao contêiner
- 10Projetar movimento, assinatura e narrativas por rolagem
- 11Preparar imagens, ícones e vídeo para a web
- 12Construir profundidade e dirigir a montagem de vídeo
- 13Construir formulários e estados de interação
- 14Publicar conteúdo encontrável em vários idiomas
- 15Projetar gráficos e painéis pela decisão
- 16Dimensionar tabelas e organizar o cálculo das métricas
- 17Escolher mapas, diagramas e cenas espaciais
- 18Comparar direção visual em Stripe e Apple
- 19Avaliar busca, conversão e padrões de comércio
- 20Auditar acessibilidade e contraste nos dois temas
- 21Validar desempenho, autenticação e segurança
- 22Planejar a modernização e publicar com reversão
- 23Construir o projeto final, medir a cara de IA e revisar
- 24Comparar modelos e interpretar benchmarks
- 25Calcular custo por tarefa e definir governança
- 26Supervisionar o modelo que opera o computador
- 27Configurar ambiente, skills e o contêiner de contexto
- 28Aplicar direção de arte, UX writing e padrões de código
- 29Construir um aplicativo instalável e resiliente
- 30Produzir apresentações e PDF com critérios de entrega