Frontends com Vibecoding · Capítulo 4 de 35 · 27 min
Dirigir o prompt e avaliar a entrega do agente
A entrega é um pedido com referência anexada, uma primeira versão comparada ao briefing e o critério de aceite que o próprio agente aplica antes de devolver a tela.
Este capítulo faz parte do curso gratuito Frontends com Vibecoding.
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 duas exigências: a âncora e a lista de escolhas antes do código. A entrega só é aceita com o print, a foto da tela como ela ficou, e com uma conferência por lista fixa.
Você sai sabendo conferir a primeira versão que o agente devolveu contra o briefing, antes de aprovar, e sabendo onde ficam a prévia e o histórico de cada mudança. Tempo de leitura: cerca de 27 minutos, e a conferência de uma entrega real, mais 15.
A captura mostra o arranjo, nunca as regras, e por isso ela sozinha engana. 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.
Ver como texto
O ponto de veto barato. Antes do código, o agente lista paleta, letra, arranjo e o motivo de cada escolha. Se alguma serviria a qualquer página, ele troca e diz o que trocou; senão, escreve o código. Vetar na lista custa uma linha de resposta; depois, com a cor espalhada em 20 arquivos, custa uma tarde.
Peça capturas da aplicação renderizada antes da entrega. A skill frontend-design recomenda inspecionar a tela quando o ambiente permite; essa inspeção ajuda a encontrar cortes e problemas de leitura que o código sozinho não revela. Se o agente não consegue abrir a aplicação, registre a revisão visual como pendente.
Para uma página com dois temas, confira quatro combinações: celular e computador, cada um em claro e escuro. Registre a largura e a versão avaliada. Depois, peça que o agente explique uma correção feita a partir das imagens e confira o resultado novamente.
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. Contraste é a diferença de claro e escuro entre texto e fundo, e a régua pede 4,5:1 no texto normal e 3:1 no texto grande.
Esse segundo piso vale para o que não é texto. A borda do campo, o anel que marca onde você está com o teclado e o ícone com sentido pedem 3:1. Medir só o texto aprova uma tela em que ninguém acha onde clicar.
Ver como texto
Fluxograma de revisão: a tela voltou da IA, confira os quatro estados, o contraste e o teclado; cada resposta negativa vira um pedido pequeno de ajuste
| 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 apareceu na vitrine online de uma loja de roupas. A foto de referência trazia sombra, cursor e barra do navegador, e o agente copiou os três porque o pedido não os excluía.
O dono reescreveu o pedido com uma linha dizendo o que ignorar, e a tela voltou limpa. Como a mesma foto mostrava só a arara cheia, o pedido passou a nomear à 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, teclado, fidelidade ao briefing e print. Libere a publicação só com as cinco respostas positivas, e peça os ajustes um de cada vez.
Diga o que conta como pronto agora que o agente testa
A conferência manual da entrega tem limite de tempo, e o passo seguinte é escrever o aceite que o próprio agente executa abrindo e testando a 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.
Ver como texto
O pedido muda de eixo. Antes, ele descrevia como implementar, passo a passo. Com a ferramenta de navegador, o agente testa sozinho, e o pedido passa a dizer o resultado observável, o que precisa estar funcionando, numa frase que se responde com sim ou não.
Ferramenta de navegador é a permissão para o modelo abrir a própria página num navegador, como você faria. Com ela, o agente vê a página montada, percorre os caminhos do usuário, acha erro de estado e compara o resultado 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 conta como pronto, numa frase que se responde com sim ou não. A terceira diz onde o modelo age sozinho e onde precisa da sua aprovação, que chega sobre um resultado concreto já revisável.
Ver como texto
Divisão do critério de aceite entre o que o agente confere sozinho e o que continua sendo conferência humana. Do lado esquerdo, com uma ferramenta de navegador ligada, o agente abre a página que construiu, testa em vários tamanhos de tela, percorre os fluxos, detecta erro de estado e de navegação e compara o resultado com a referência anexada. Do lado direito, permanecem com a pessoa quatro itens que não têm medição pública para páginas geradas por modelo: contraste de cor, navegação apenas por teclado e leitor de tela, comportamento em tela estreita e fidelidade ao que existe de verdade, como imóvel, produto ou equipamento. A leitura é que a revisão humana encolheu, mas não desapareceu, e que ela agora cabe em quatro itens nomeados.
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.
Ver como texto
A fronteira de autonomia em três zonas encaixadas. Na maior, o agente age sozinho em passo reversível, como corrigir um erro de digitação. Na do meio, pede sua aprovação sobre um resultado já revisável. Na menor, fica o que ele nunca faz sem você, declarado no briefing.
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ê. Uma comparação de dois anos de modelos mostrou que os mais novos escrevem código que compila melhor sem escrever código mais seguro.
No mesmo levantamento, o código saiu com falha de segurança conhecida em 45% dos casos. A falha mais comum é a que aparece justamente em tela: o conteúdo escrito pelo visitante exibido sem limpeza.
Por isso o pedido leva uma linha fixa: todo texto que vem do visitante entra na página como texto, nunca como código.
Ver como texto
O que o visitante escreve num campo segue um de dois caminhos. Exibido sem limpeza, vira código na página, a falha mais comum. Tratado como texto, aparece como foi digitado e não faz nada. No levantamento citado, o código gerado saiu com falha de segurança conhecida em 45% dos casos.
Há um ponto de calibragem que surpreende quem vem do modelo anterior. Esforço é o ajuste que manda o modelo pensar mais antes de responder, e em página simples pedir o máximo piora o resultado.
Num teste de tela de acesso, 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 em uma frase 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. Confira pessoalmente os quatro itens sem medição pública: contraste, teclado, tela estreita e fidelidade ao que existe de verdade. A tela está aprovada quando as quatro perguntas têm resposta sim.
Guia prático: landing page de campanha, do gerador ao repositório
Gerador de tela no navegador serve para testar a oferta em horas. A página que recebe verba de mídia precisa de mais três coisas: código no seu repositório, evento de medição e conferência no celular. O roteiro abaixo usa o briefing e a âncora que você montou acima e vale para v0, Lovable e Bolt.
| Ferramenta | O que mudou entre julho e setembro de 2026 | Uso na campanha |
|---|---|---|
| Bolt | Edição visual direta na prévia, fila de até 20 pedidos e auditoria de segurança no menu Publish | Ajustar texto e cor da oferta sem gastar tokens até salvar |
| Lovable | Rascunhos em cópia separada do projeto, design system em todos os planos pagos e arquivo do Figma anexado no chat | Testar uma segunda versão do topo sem mexer na página publicada |
| v0 | Instala pacotes privados do npm com a credencial guardada em variável de ambiente compartilhada, desde 18/09 | Gerar a página já com o design system interno da empresa |
Analista de marketing de uma escola de idiomas, sozinha na campanha de matrículas de janeiro
Educação, captação de alunos por mídia paga
Dor
A agência pediu três semanas para a landing page. A verba de mídia começa em dez dias e a oferta ainda vai mudar duas vezes.
Solução
Ela gerou a primeira versão no Bolt com o briefing de uma tela e uma captura de referência, ajustou título e cor pela edição visual, exportou para o GitHub e pediu ao agente de código o formulário e o evento de medição.
Resultado do exemplo
A página entrou em prévia no quarto dia, com o mesmo título do anúncio no topo e um envio de teste registrado. A leitura de resultado ficou marcada para depois de duas semanas de tráfego.
Cenário construído para fins didáticos. Números não correspondem a cliente específico.
Landing page de campanha em sete passos
Do pedido no gerador até a prévia conferida. O que decide é a mesma promessa do anúncio no topo, o formulário curto e o celular.
Passo 1: Escreva o briefing de uma tela e anexe a âncora
Promessa do anúncio, público, uma única ação, campos do formulário (no máximo quatro) e o que é proibido: pop-up na entrada, vídeo em reprodução automática, carrossel no topo. Anexe a captura de referência com as quatro linhas do que muda.
Deu certo quando: O gerador devolve um plano ou uma lista de seções antes de construir.
Erro comum: Colar só o texto do anúncio e receber seis seções genéricas com três cartões iguais.
Passo 2: Peça a lista de escolhas antes do código
Paleta, tipo de letra, arranjo e o motivo de cada um. No Bolt e no Lovable, use o modo de plano; no v0, peça o plano na primeira mensagem.
Deu certo quando: Você veta por escrito o que serviria para qualquer página parecida, e o gerador diz o que trocou.
Erro comum: Aceitar o roxo em degradê e a fonte padrão porque a primeira tela já parece pronta.
Passo 3: Ajuste texto e cor pela edição visual
No Bolt, ative a ferramenta Select na caixa de conversa, clique no elemento da prévia, altere texto, cor, tamanho e alinhamento e junte as mudanças num lote. Editar é gratuito; os tokens só são cobrados ao salvar.
Deu certo quando: O lote aparece acima da caixa de conversa e um clique em Save changes atualiza o código.
Erro comum: Gastar uma rodada de conversa para trocar uma palavra do título.
Passo 4: Teste a segunda versão numa cópia
No Lovable, abra um rascunho para comparar a tela sem alterar a página publicada. O rascunho compartilha os dados do projeto: teste envios somente com destino didático separado e contatos fictícios.
Deu certo quando: As duas versões do topo existem lado a lado e só a escolhida volta ao projeto.
Erro comum: Pedir a variação na conversa principal e perder a versão que já estava aprovada.
Passo 5: Leve o código para o seu repositório
Conecte o GitHub na própria ferramenta e continue no Claude Code, no Cursor ou no Codex. Rode a auditoria de segurança do menu Publish do Bolt antes de sair.
Deu certo quando: O repositório tem histórico de commits e a página sobe com o comando de desenvolvimento na sua máquina.
Erro comum: Deixar a página só no gerador e descobrir, na semana da campanha, que não há como instalar a medição.
Passo 6: Instale formulário e medição no código
Siga o guia do capítulo "Construir formulários e estados de interação": validação nos dois lados e o evento generate_lead no envio.
Deu certo quando: Um envio de teste aparece uma vez no modo de depuração.
Erro comum: Medir só a página de agradecimento e perder quem fecha a aba antes do redirecionamento.
Passo 7: Confira a prévia no celular antes de trocar a URL do anúncio
Peça os dois prints, celular e computador, e percorra a ordem da tabela de conferência: estados, contraste, teclado e fidelidade ao real. Preço, prazo e nome do curso conferem com a fonte.
Deu certo quando: O título do topo repete a promessa do anúncio e o formulário envia com o teclado do celular aberto.
Erro comum: Aprovar pelo computador e pagar clique para uma página que corta o botão em tela estreita.
No fim você tem: Uma landing page no seu repositório, com a oferta do anúncio no topo, formulário curto, medição instalada e prévia conferida em tela estreita.
Aplicar o Lovable à revisão de uma campanha antes de comprar tráfego
No caso fictício da Escola Horizonte, o anúncio promete uma aula experimental de inglês, mas a página abre com a história da escola. O laboratório corrige esse desencontro e prepara a descoberta pela busca. Reaproveite a página construída no guia; a entrega será uma prévia revisada e uma ficha de aceite, sem campanha real.
O Lovable anunciou Growth tools em 14/10/2026: a conversa passa a ajudar na oferta, na busca e na preparação de campanhas. A documentação operacional consultada em 17/10/2026 coloca a revisão em More > Analytics > SEO & AI. Ela verifica aspectos técnicos; aprovação no diagnóstico não comprova posição no Google nem aumento de inscrições. As etapas abaixo são uma aplicação didática desses recursos.
Construir e revisar a página da aula experimental
Use um projeto didático com nomes e contatos fictícios. Faça a construção primeiro e a revisão numa mensagem seguinte.
Passo 1: Fixe a oferta no topo e o destino do botão
No chat do projeto, peça o título Aula experimental de inglês e o botão Solicitar aula experimental. O botão leva ao formulário de nome e e-mail. Confira se a chamada do anúncio continua verdadeira na página.
Deu certo quando: Título, botão e confirmação descrevem a mesma solicitação, sem promessa de vaga garantida.
Erro comum: O agente inventa descontos ou depoimentos para preencher a tela. Retire o material sem comprovação.
Passo 2: Peça uma revisão de crescimento com escopo fechado
Use o modelo abaixo para avaliar clareza da oferta e barreiras ao envio. Escolha uma alteração sugerida e confira a prévia. Neste exercício, mantenha contas de anúncio desconectadas.
Deu certo quando: A sugestão aponta um trecho visível da página e uma mudança que você consegue conferir.
Erro comum: A resposta vira um plano genérico de marketing. Peça o elemento exato da página que sustenta a recomendação.
Passo 3: Execute a revisão técnica no local certo
Abra More > Analytics > SEO & AI. Na revisão, use Scan project quando disponível; em projeto publicado, Run SEO scan. Examine título, descrição, estrutura e endereço canônico, que indica a versão principal da página.
Deu certo quando: A ficha registra URL, data, achado e ação. Falta de tráfego fica como não medido.
Erro comum: A aba não aparece: confira se o acesso ao site está restrito. Faça o exercício em projeto didático separado; mantenha aplicações internas restritas.
Passo 4: Corrija um achado e valide a versão atual
Use Try to fix no achado escolhido, revise a alteração e rode Scan again. Compare também a prévia: título e descrição precisam continuar fiéis à aula experimental.
Deu certo quando: O relatório corresponde ao código atual. Fix applied ainda pede nova verificação.
Erro comum: Uma correção técnica muda a oferta. Restaure o texto aprovado e repita a revisão.
Passo 5: Feche a passagem da prévia para a página pública
Conclua o laboratório de formulário antes de publicar o projeto didático. Depois, abra a URL publicada e repita Scan again para os checks que dependem do site no ar. Registre separadamente preparo técnico e resultado comercial.
Deu certo quando: A URL pública mostra a oferta aprovada e o relatório foi executado depois da publicação.
Erro comum: Usar o relatório da prévia como prova da página publicada. Confira novamente o endereço que receberá o anúncio.
No fim você tem: Uma página coerente com a oferta, com revisão técnica datada e pendências que têm responsável. A compra de tráfego continua fora deste exercício.
Avaliar se a página pode seguir para o teste de formulário
Critério de pronto da Escola Horizonte
0/3Na próxima campanha, a equipe da Escola Horizonte usa essa ficha para aprovar a página que receberá os visitantes. O próximo trabalho é testar se a solicitação sobrevive a erro de campo, falha de rede e tela pequena. Growth tools usa os custos normais da conversa no Lovable; eventual verba de anúncio pertence à conta do Google ou da Meta e exige orçamento próprio.
Ver como texto
Tela de um projeto de exemplo no Bolt com a ferramenta Select ativa. Três balões numerados indicam a ordem: ligar a ferramenta Select na caixa de conversa, fazer as edições como trocar cores e juntá-las num lote, e ver o lote de três mudanças visuais com o botão Save changes.
Guia prático: revisar a entrega como diretor, com nota que o agente consegue executar
"Não gostei do meio, melhora" é a nota mais cara que existe: o agente adivinha, refaz o que estava certo e você revisa tudo de novo. O curso de edição de vídeo estudado em 07/10/2026 ensina a revisar como diretor, com três regras que servem igual para uma página.
Primeiro, assista ou percorra a entrega inteira uma vez sem anotar. Na segunda passada, anote com posição: no vídeo, o tempo (aos 0:15); na página, a seção e a largura de tela (no topo, a 390 px). Segundo, uma nota por linha, todas mandadas juntas, para o agente refazer uma vez só. Terceiro, diga o que quer ver, e não como fazer: "o botão visível sem rolar" é executável; "aumenta o padding do container" amarra o agente a uma solução que pode estar errada.
O quarto hábito fecha o ciclo: ajuste que se repete vira regra no arquivo de instruções. No material estudado, cada erro corrigido duas vezes passou para a lista de armadilhas da skill, e um deles virou aviso automático no script que monta os planos. Na página, a nota que você deu em dois projetos vai para o CLAUDE.md ou para o DESIGN.md.
O mesmo vale para o pedido de personalização de um template. O pedido sugerido pela galeria estudada manda ler os dois arquivos, adaptar mantendo a estrutura e rodar o projeto. Faltam o plano antes de editar, os dados reais do negócio, a varredura de dados de exemplo e o teste em 390 px. Escreva o seu pedido com as suas palavras e peça um piloto pequeno antes do todo.
PEDIDO DE PERSONALIZAÇÃO
Leia CLAUDE.md e DESIGN.md. Não edite nada ainda.
Negócio: [nome, cidade, o que vende, para quem]
Dados reais: [telefone ou WhatsApp, registro profissional, endereço, horários]
Serviços: [lista com uma linha cada]
1. Me devolva o plano: arquivos que vai tocar e o que muda em cada um.
2. Depois do meu ok, faça só o topo e a primeira seção como piloto.
3. Liste todo dado de exemplo que ainda sobrou no projeto.
4. Abra em 390 px e 1440 px e me diga como ver o resultado.
NOTAS DE REVISÃO (uma por linha, todas juntas)
- topo, 390 px: título em no máximo duas linhas
- serviços, 1440 px: os quatro cartões na mesma altura
- depoimentos: tira o terceiro, ainda não tenho autorização
- rodapé, 390 px: telefone tocável, com área de toque maiorUma rodada de revisão que o agente executa de primeira
Cinco passos para cada entrega que chegar.
Passo 1: Percorra a entrega inteira uma vez sem anotar
Abra a página no celular e no computador e role do topo ao rodapé. A primeira passada é para ver o conjunto; detalhe anotado cedo desvia a atenção do problema maior.
Deu certo quando: Você sabe dizer em uma frase se a página cumpre a tarefa dela.
Erro comum: Começar a corrigir o primeiro botão e não perceber que falta uma seção inteira.
Passo 2: Anote com posição e largura
Na segunda passada, cada nota começa pelo lugar: seção, largura de tela e, se houver animação, o momento. Sem posição, o agente procura e às vezes acha o lugar errado.
Deu certo quando: Toda nota diz onde está o problema.
Erro comum: Escrever "o botão está estranho" numa página com seis botões.
Passo 3: Diga o resultado, não a técnica
Troque "muda o flex para grid" por "os quatro cartões na mesma altura". Você descreve o que quer ver; o agente escolhe como chegar lá e você confere o resultado.
Deu certo quando: Cada nota pode ser conferida olhando a tela.
Erro comum: Ditar a solução técnica e receber exatamente ela, mesmo quando não resolve.
Passo 4: Mande todas as notas numa mensagem
Uma por linha, no formato do bloco acima. O agente refaz uma vez, e você confere uma vez. Peça a lista de arquivos alterados junto.
Deu certo quando: A rodada inteira sai de uma mensagem e volta com a lista do que mudou.
Erro comum: Mandar nota a nota e ver a terceira desfazer a primeira.
Passo 5: Promova a nota repetida a regra
Ao fim da rodada, pergunte quais notas você já tinha dado em outra entrega. Essas entram no CLAUDE.md, se forem de conduta, ou no DESIGN.md, se forem de aparência.
Deu certo quando: O arquivo de instruções ganhou ao menos uma regra nova com data.
Erro comum: Corrigir o mesmo título quebrado em todo projeto novo porque a regra ficou só na conversa.
No fim você tem: Revisões que saem numa mensagem, voltam certas na primeira vez e deixam o arquivo de instruções mais esperto a cada projeto.
A conferência ganhou lugar fixo nas ferramentas
Em 01/09/2026 o v0 passou a publicar com um botão que cria a solicitação de mudança no GitHub, junta o código e põe no ar, sempre passando antes por uma prévia; as proteções do repositório continuam valendo. Em 09/09 o Lovable lançou rascunhos para testar mudanças em separado, e em 16/10 políticas que exigem aprovação antes de publicar.
Ver como texto
Página What's new do v0 aberta na seção October 2026. A primeira nota, de 19/10/2026, se chama Connect Slack to v0 e explica a integração MCP com o Slack, disponível em todos os planos; abaixo começa a nota de 16/10/2026 sobre downloads na aba Code, novos seletores no iOS e correções na prévia.
Ver como texto
Página Lovable changelog na documentação do Lovable, com as notas mais recentes: ver a adoção por departamento sem SCIM, agrupar espaços de trabalho numa organização e pedir ao Lovable que crie o projeto no Supabase, cada uma com um parágrafo de explicação.
Ver como texto
Página do Figma Make com o título Prototype. Polish. Ship. Your ideas get real in Figma Make, uma caixa de texto What do you want to make? e três sugestões: Onboarding flow, Data dashboard e Gradient gallery.
| Item do briefing | Pergunta de conferência | Onde olhar |
|---|---|---|
| Objetivo e público | A tela cumpre a tarefa nomeada, para o público nomeado? | Prévia, lendo o briefing em voz alta |
| Estados | Erro, lista vazia e carregamento aparecem? | Prévia, enviando um formulário vazio |
| Celular | Tudo cabe e funciona numa tela estreita? | Prévia aberta no celular |
| Mudança | Quem aprovou e o que mudou desde a última versão? | Histórico de versões ou solicitação de mudança |
Faça agora: avalie a primeira entrega em 15 minutos
Passo 1: Abra a prévia da entrega no celular e no computador.
Deu certo quando: Você tem o link da prévia, e não só um print.
Passo 2: Leia o briefing item por item e marque o que a tela cumpre.
Deu certo quando: Cada uma das sete partes tem um sim ou um não.
Passo 3: Force um erro: envie o formulário vazio ou com e-mail errado.
Deu certo quando: A tela explica o erro em português, perto do campo.
Erro comum: Testar só o caminho feliz.
Passo 4: Escreva a nota de correção citando o item do briefing e o que você esperava ver.
Deu certo quando: Cada nota tem item, situação atual e resultado esperado.
Erro comum: Nota vaga como "melhora o meio".
Passo 5: Peça ao agente que confira a própria tela contra o critério de pronto antes de devolver.
Deu certo quando: A nova entrega volta com a lista de critérios conferidos.
No fim você tem: Uma lista de correções ligada ao briefing, que o agente consegue executar sem adivinhar.
Antes de aprovar uma tela feita com agente
Conferência
0/4Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Estude antes
- CursoClaude Code: do zero à prática
- Agent Skills e SKILL.md: instruções reutilizáveissugerido pelo grafoApresenta o conceito “Skill (Agent Skill)”, usado em “Dirigir o prompt e avaliar a entrega do agente”.
- CursoSíntese e didática com IAsugerido pelo grafoDepois de escolher a informação essencial e desenhar hierarquia, gráficos e fluxos compreensíveis, o aluno pode aplicar esses critérios às interfaces do curso de frontend. A ponte conecta clareza da mensagem, acessibilidade e decisões de apresentação.
- CursoNode.js: JavaScript no Servidorsugerido pelo grafo9 capítulos de “Frontends com Vibecoding” usam conceitos apresentados em “Node.js: JavaScript no Servidor”.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Escrever bem com IAMontar o pedido completo e os critérios que a IA confereExaminar conexões de Montar o pedido completo e os critérios que a IA confere
- Síntese e didática com IAPeça ao agente de código para enxugar uma página sem quebrá-laExaminar conexões de Peça ao agente de código para enxugar uma página sem quebrá-la
- Modelo de trabalho com agentes de IAO que escrever no pedido antes de delegar?Examinar conexões de O que escrever no pedido antes de delegar?
- MCP e Chrome: agentes de IA no navegadorOnde a consulta vira uma ação com consequênciaExaminar conexões de Onde a consulta vira uma ação com consequência
Terminou a leitura?
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.
Laboratórios ao vivo deste curso
Cada laboratório monta a biblioteca real dentro da aula, com controles para você mexer e o código do exemplo para copiar. O texto de reserva descreve a demonstração para quem lê sem JavaScript. O link abre o capítulo já no ponto do laboratório.
Base UI
Prenda o foco num diálogo sem escrever o comportamento
Abra a janela Agendar visita, percorra os campos com Tab, feche com Esc e acompanhe no painel onde o foco está e para onde ele volta.
Pacote
Abrir no capítuloConstruir componentes, usar o registro e publicar o catálogo@base-ui/reactLucide e Iconify
Mantenha uma família de ícones coerente e nomeie cada botão
Mude tamanho, traço e cor da barra, veja o símbolo do Iconify acompanhar o Lucide e rode a auditoria de nomes acessíveis.
Pacote
Abrir no capítuloProjetar uma linguagem de ícones e ilustraçãolucide-react, @iconify/reactMotion
Testar os três sinais que autorizam o terceiro degrau
Reproduza a entrada em sequência, aperte o botão com mola e arraste o cartão; ajuste rigidez e amortecimento e veja o que muda.
Pacote
Abrir no capítuloProjetar movimento, assinatura e narrativas por rolagemmotionVidstack
Ver o que separa um player de um vídeo cru
Dê o play, troque a velocidade e ligue a legenda; o painel ao lado mostra o estado que o player publica e que a etiqueta crua esconde.
Pacote
Abrir no capítuloProjetar movimento, assinatura e narrativas por rolagem@vidstack/reactcmdk
Achar um destino entre quarenta digitando três letras
Abra a paleta, digite fat e escolha um item só pelo teclado; o painel embaixo conta o que o filtro deixou passar e quanto tempo levou.
Pacote
Abrir no capítuloConstruir formulários e estados de interaçãocmdknumber-flow
Animar indicadores que mudam ao vivo com formato pt-BR
Veja três indicadores fictícios rolarem a cada troca e compare com o número em texto puro. Pause, reinicie e observe o separador de milhar.
Pacote
Abrir no capítuloProjetar gráficos e painéis pela decisão@number-flow/reactApache ECharts
Medir o custo de desenhar 200 mil pontos com o ECharts
Troque o tipo de gráfico e o volume de pontos, leia o tempo de desenho e alterne o eixo em zero. Mude o tema do site e veja as cores refazerem.
Pacote
Abrir no capítuloProjetar gráficos e painéis pela decisãoechartsApache ECharts
Painel grande com visões coordenadas
Clique num canal para filtrar todas as visões, troque a densidade entre 6, 9 e 12 visões, alterne tema e movimento e abra a tela cheia.
Pacote
Abrir no capítuloProjetar gráficos e painéis pela decisãoechartssharp e svgo
Escolher a variante certa da imagem e conferir o teto de 150 KB
Arraste a largura da tela simulada, troque a densidade entre 1x e 2x e veja qual arquivo o navegador escolhe, quanto ele pesa e se cabe no orçamento.
Pacote
Abrir no capítuloValidar desempenho, autenticação e segurançasharp, svgoReact Flow (xyflow)
Disparar um pedido e ver o orquestrador distribuir, conferir e responder
Alterne paralelo e sequencial, ligue e desligue a verificação e use a medição real; observe o tempo de parede em cada combinação.
Pacote
Abrir no capítuloConstruir as cenas do orquestrador, do paralelismo e do robô@xyflow/reactGSAP, Web Workers e number-flow
Dividir mil tarefas entre trabalhadores reais e correr três ritmos de geração
Execute com um trabalhador, depois com quatro e oito, e compare o tempo; em seguida percorra a corrida e separe a espera inicial do ritmo.
Pacote
Abrir no capítuloConstruir as cenas do orquestrador, do paralelismo e do robôgsap, @number-flow/reactThree.js com React Three Fiber, drei, Rapier e XR
Carregar o braço robótico, ver a física trabalhar e entrar na cena com o visor
Carregue a cena pelo botão, inicie o ciclo, mostre os ângulos das juntas, troque a câmera e a velocidade; com visor, entre em realidade virtual.
Pacote
Abrir no capítuloConstruir as cenas do orquestrador, do paralelismo e do robôthree, @react-three/fiber, @react-three/drei, @react-three/rapier, @react-three/xrMotion
Ver quatro agentes em raias trocando mensagens e a revisão devolvendo um trecho
Reproduza os 60 s de modelo, percorra o tempo pelo controle e esconda as mensagens para comparar a leitura; repare no tempo de parede contra a soma.
Pacote
Abrir no capítuloEspecificar, medir e produzir as cenas da máquinamotionMediaRecorder, Canvas 2D e Long Animation Frames (plataforma)
Medir o quadro da cena e gravar seis segundos dela em vídeo
Suba as partículas, force um bloqueio de 300 ms e leia o medidor; depois grave seis segundos, veja o codec escolhido e baixe o arquivo.
Pacote
Abrir no capítuloEspecificar, medir e produzir as cenas da máquinasem pacotesigma.js, graphology com ForceAtlas2 e cosmos.gl
Ver o grafo real do curso e um grafo de milhares de nós se organizarem em aglomerados
Rode o layout no grafo real, passe o mouse pelos nós e busque uma entidade; troque para 20 mil nós e leia o medidor; depois carregue o modo massivo na placa de vídeo.
Pacote
Abrir no capítuloAnimar um grafo de conhecimento amplo em movimentosigma, graphology, graphology-layout-forceatlas2, graphology-generators, @cosmos.gl/graph