1
Centelha
7 min de leitura ·

Quando design, código e IA entram no mesmo loop, o review não pode parar no PR

O problema não é o agente gerar uma tela errada.

Tela errada a gente costuma perceber rápido. O build quebra, o botão aparece no lugar absurdo, o layout desmonta no mobile, alguém olha o preview e fala "não era isso".

O problema mais perigoso é a tela quase certa.

Ela passa no build. O screenshot fica bonito. O PR parece pequeno. Só que o agente trocou um estado vazio por uma copy genérica, ignorou um breakpoint, inventou um espaçamento fora dos tokens do design system ou assumiu um contrato de API que ninguém combinou.

E aí o review tradicional começa a ficar curto demais.

O agente deixou de ser só chat

Durante muito tempo, usar IA no frontend parecia uma conversa lateral: você pedia um componente, copiava o resultado, colava no editor e revisava o diff.

Esse fluxo ainda existe, mas já não descreve bem o que está acontecendo nas ferramentas mais recentes. O agente agora aparece como sessão de trabalho. Ele abre tarefa em paralelo, mexe em branch isolada, conversa com o editor, lê contexto, propõe mudança, gera preview, interage com design, prepara PR e tenta fechar o ciclo com alguma evidência.

No VS Code, no Copilot App, no Figma e em ferramentas de API, o movimento é parecido: o agente está saindo da caixinha de texto e entrando no lugar onde a decisão acontece.

Isso é ótimo para velocidade. Também muda o tipo de erro que chega até você.

Quando uma pessoa implementa uma tela, ela costuma lembrar das pequenas escolhas que fez: "usei esse componente porque o outro não tinha estado disabled", "mantive esse padding porque o card precisa bater com a lista", "não tratei erro ainda porque o endpoint está instável".

Um agente pode até registrar parte disso, mas não dá para assumir. Se o seu review só olha o PR final, você está revisando o rastro mais pobre do trabalho.

O PR mostra código, mas não mostra intenção suficiente

Diff é importante. Eu não abriria mão dele.

Só que diff responde a uma pergunta limitada: quais arquivos mudaram?

Para UI, essa pergunta raramente basta.

Uma mudança de frontend também precisa responder:

  • qual intenção visual a tela deveria preservar;
  • quais estados foram considerados;
  • quais componentes e tokens foram tocados;
  • qual contrato de API o código assumiu;
  • como a tela se comporta em largura menor;
  • que evidência visual existe antes do merge;
  • de onde vieram os assets usados no fluxo.

Nada disso aparece de forma confiável quando você só olha linhas verdes e vermelhas.

Às vezes o agente troca um Button por uma div clicável porque ficou mais fácil montar o layout. Às vezes transforma um estado vazio em texto simpático demais e mata uma decisão de produto. Às vezes usa px-6 direto porque não achou o token certo. Às vezes deixa o loading lindo, mas esquece o erro 401.

O PR pode parecer limpo mesmo assim.

Um checklist pequeno já muda o jogo

Não acho que todo review com agente precise virar uma cerimônia pesada. Se a tarefa é um spike ou um protótipo descartável, um screenshot e uma nota curta podem bastar.

Mas se a tela vai para produção, eu pediria pelo menos estas evidências antes de aceitar:

  1. Objetivo visual em uma frase.
  2. Lista dos componentes alterados.
  3. Estados cobertos: loading, vazio, erro, sucesso e disabled quando fizer sentido.
  4. Screenshot ou preview do caminho principal.
  5. Uma checagem mínima de responsividade.
  6. O contrato de API assumido pela tela.
  7. Comandos de validação executados.
  8. Origem e versão dos assets finais.

Repara que isso não é burocracia. É só tornar visível o que um bom dev já costuma pensar durante a implementação.

O agente pode ajudar nisso também. Você pode pedir para ele deixar no PR uma seção curta de evidências:

## Evidência de UI

- Objetivo: ajustar o onboarding para mostrar o estado vazio antes da primeira integração.
- Componentes tocados: OnboardingPanel, EmptyStateCard, IntegrationButton.
- Estados revisados: vazio, loading e erro de autenticação.
- Preview: desktop 1440px e mobile 390px.
- Validação: pnpm test, pnpm lint, pnpm build.

Isso não substitui olhar a tela. Mas já evita aquele review em que todo mundo aprova porque o diff parece razoável.

Design não é print estático

O ponto mais interessante dessa nova leva de agentes de UI é que design e código estão ficando menos lineares.

Antes, o fluxo clássico era: alguém desenha no Figma, alguém implementa no código, alguém compara o resultado com o print. Se desse tempo, ajustava. Se não desse, ficava "bom o bastante".

Agora a ferramenta começa a ir e voltar. Código pode virar referência de design. Design pode alimentar implementação. O agente pode sugerir variação, mexer em componente, abrir preview e tentar reconciliar o que está no canvas com o que está no repo.

Isso melhora o handoff, mas também tira o conforto de tratar design como imagem congelada.

Se o agente cria uma variação visual, você precisa saber se ela respeita os tokens. Se muda um botão, precisa saber se ainda usa o componente certo. Se ajusta uma tela, precisa saber se o estado vazio e o estado de erro continuam coerentes com o resto do produto.

Em outras palavras: design system deixa de ser documento bonito e vira contrato de execução.

E contrato precisa ser revisável.

API ainda cobra a conta

Frontend gerado por IA costuma impressionar mais quando está isolado. Uma tela estática, com dados mockados e caminho feliz, pode ficar pronta muito rápido.

O problema aparece quando ela encosta no sistema real.

Autenticação falha. O endpoint demora. O payload vem parcial. O usuário não tem permissão. O plano gratuito não permite aquela ação. O estado vazio precisa explicar alguma coisa sem culpar a pessoa. O erro precisa ser útil sem vazar detalhe interno.

Esse é o tipo de coisa que separa "parece pronto" de "dá para colocar na mão de usuário".

Então, se um agente implementa uma UI que depende de API, eu não aceitaria o PR sem uma nota explícita sobre o contrato usado. Não precisa ser um tratado. Pode ser simples:

Contrato assumido:
- GET /projects/:id retorna name, status e integrations.
- integrations pode vir vazio.
- 401 redireciona para login.
- 403 mostra mensagem de permissão.
- erro 5xx mantém a tela com ação de tentar novamente.

Se essa nota parece chata, provavelmente é porque ela está revelando uma decisão que antes ficava implícita demais.

Assets também entram no rastro

Tem outro pedaço que costuma ficar perdido: imagens, thumbnails, previews e peças sociais.

Em produto pequeno, isso aparece o tempo todo. O dev ajusta uma landing page, gera uma imagem de preview, corta uma thumbnail, prepara um post para divulgar a feature e depois ninguém sabe exatamente qual arquivo foi aprovado.

Quando o agente participa desse fluxo, vale tratar asset como parte da entrega, não como anexo informal.

O mínimo saudável é registrar:

  • arquivo de origem;
  • versão aprovada;
  • tamanho exportado;
  • onde aquilo será usado;
  • se houve corte, padding ou redimensionamento.

Se a imagem aprovada precisa virar post, story ou preview social, uma etapa browser-local como Resize Image for Instagram pode ser só isso: uma forma prática de preparar o tamanho final sem transformar o review em uma discussão sobre ferramenta. O ponto principal é manter o rastro. Qual imagem entrou, qual formato saiu e onde ela será publicada.

Isso parece detalhe até alguém subir a imagem errada em produção.

O review ideal é mais visual, não mais pesado

O risco aqui é exagerar e criar um processo que ninguém usa.

Não precisa pedir relatório completo para cada alteração de CSS. Não precisa fazer reunião para cada card. Não precisa transformar agente em desculpa para dobrar o número de aprovações.

O que funciona melhor é calibrar pelo risco.

Para spike:

  • screenshot;
  • nota do que foi testado;
  • link para o branch ou preview.

Para tela interna simples:

  • estados principais;
  • responsividade básica;
  • validação local.

Para tela pública ou fluxo de conversão:

  • intenção visual;
  • contrato de API;
  • acessibilidade básica;
  • estados de erro e vazio;
  • evidência em desktop e mobile;
  • assets finais rastreados.

Isso deixa o review proporcional. O agente ganha espaço para acelerar o trabalho, mas não ganha permissão para esconder decisão de produto dentro de uma alteração que "parece funcionar".

O dev continua sendo o editor responsável

Eu gosto de agentes para frontend justamente porque eles removem muito trabalho repetitivo. Montar variação, conectar componente, ajustar layout, escrever teste inicial, abrir caminho para uma ideia. Tudo isso pode ficar mais rápido.

Mas a parte difícil do frontend nunca foi só digitar JSX ou CSS.

A parte difícil é decidir se a interface comunica a coisa certa, no estado certo, para a pessoa certa, sem quebrar o contrato técnico por trás.

O agente pode gerar uma tela inteira. O dev precisa transformar essa tela em uma entrega revisável.

Essa é a diferença.

Quem usa IA bem no frontend não é quem deixa o agente "fazer a UI" e torce para o PR passar. É quem cria um loop pequeno, visível e auditável entre design, código, API, browser e assets.

No fim, revisar menos código não deveria significar revisar menos produto.

Notas de fonte

Carregando publicação patrocinada...