Case 05 · Ferramentas de IA
Ensinando um agente a enxergar como designer
Um agente que reproduz telas reais do produto em protótipos, reduzido a um só agente e ensinado a parar em vez de adivinhar.
Cliente fictício · NDA
O produto real está sob NDA (acordo de confidencialidade), então esta página não mostra nenhuma tela dele. O cenário, os nomes e os dados são fictícios. As decisões e as lições são minhas.
- 9 para 1agentes, do primeiro pipeline ao agente empacotado
- 0,4 pxde diferença de tinta no pior de quatro ícones da barra, contra 7 px antes
- 69falhas registradas como regras
Problema
Trabalho novo na plataforma começa de telas que já existem. O protótipo de uma mudança só é honesto se tudo em volta dela bate com o produto real.
Quando um agente de reprodução não consegue ver a página, ele adivinha, e um palpite parece pronto. Meu primeiro pipeline, em junho, recorria a chamadas diretas à API quando o navegador falhava, e eu tinha pedido que ele dissesse qual modo usou. A versão com um agente só, em julho, caía do navegador para um script e daí para a API direta. Pelas anotações do próprio agente, fazia isso em silêncio e entregava palpites de baixa fidelidade.
Restrições
- Uma página muda conforme o papel. Reproduzida com quem estava logado, uma lista tinha um botão a menos no cabeçalho e dados diferentes dos do papel que precisávamos.
- O destino é o framework de prototipação interno do nosso time, com componentes e ícones próprios. Os valores copiados são traduzidos para os componentes e tokens do framework, exceto a cor, que fica exata.
- O contexto é finito. O agente relia o manual inteiro a cada retomada, então cada linha a mais custava algo em toda execução.
Decisões-chave
-
01
Um agente só, e parada obrigatória quando o navegador falha
A primeira versão era um pipeline de agentes. A que empacotei em agosto é um agente só, que para quando não há navegador e diz por quê, em vez de degradar.
- 9 agentesjunho. Um pipeline, com fallback para a API direta.
- 2 agentesjulho. Um agente com modos de copiar e sincronizar, mais um ajudante de captura.
- 1 agenteagosto. Empacotado. Sem navegador, sem execução.
Definições de agente no repositório a cada passo. O fallback foi cortado, não ajustado. -
02
Paridade se mede, não se julga
No fim de julho, a paridade virou uma verificação mecânica, montada sobre o pipeline de testes de navegador que uma pessoa do time criou. Probes nomeiam os elementos, um comparador com testes unitários lê 47 propriedades de estilo dos dois lados, e um elemento ausente bloqueia a execução. Mesmo assim, deixou passar ícones da barra de ferramentas que eu via errados. Agora cada ícone é dimensionado pela parte visível do ícone, que é o que o olho compara.
Antes · a mesma caixa para todos
7 pxno pior caso (27%)
Depois · pela parte visível do ícone
0,4 pxno pior caso
Formas genéricas, não os ícones do produto. Tracejado: o ícone no app. Contorno cheio: o ícone do protótipo. Esquemático; as diferenças são medidas. -
03
Ver se renderiza antes de medir
Duas verificações rodam antes de qualquer passada de paridade: a página renderiza? E funciona? A paridade só registrou a tabela ausente como duas linhas de tamanho entre 181.
- CapturarA página real, num navegador de verdade, com o papel certo.
- ConstruirCom os componentes do próprio framework.
- Renderiza?Olhar um screenshot antes de qualquer número.
- Funciona?Todo controle visível faz alguma coisa.
- ParidadeProbes e relatório. Só na reprodução completa.
Tracejado: só roda quando pedido, depois das duas verificações. -
04
Rascunho rápido por padrão
Uma passada pela tela inicial e pelo que abre a partir dela. Termina com o app e o protótipo lado a lado e uma pergunta: já dá para mostrar, ou continuo? Uma reprodução completa declara o custo antes e espera um sim.
Padrão
Rascunho rápido
Uma passada. Meta: minutos.
A tela inicial, mais os modais, drawers e tooltips que ela abre.No máximo duas perguntas, o papel primeiro; o resto vira premissa declarada.Sob pedido
Reprodução completa
Cada estado, medido. Horas.
Outras rotas, probes completas e um relatório de paridade.Uma página: cerca de 1,1 milhão de tokens, uns 40% deles o manual reenviado (número informado pelo agente).Tracejado: número do próprio agente, sem log de uso por trás. -
05
Cada falha vira uma regra
Cada falha real vai para o registro com o custo e a regra que a evita. O agente só lê a tabela quando uma execução dá errado, para ela não pesar em todas.
Falha Consequência Regra Cadeia de fallback: navegador, script, API direta. Quase sempre rodava o passo mais fraco, em silêncio. Um modo só, navegador de verdade. Sem navegador, parada. Procurou overlays clicando por aí. Um popover e alguns tooltips ficaram de fora. Listar overlays pelo código e pela página; conferir as contagens. Leu um elemento, não o que havia dentro dele. Uma cor de status foi adivinhada por screenshot. Usar o elemento mais profundo que carrega o visual. Três linhas, parafraseadas.
Na sala
Uma reprodução completa · como administrador do sistema
O agente reproduziu uma página com uma tabela de 29 colunas no modo completo, na época o padrão. Só as fases cronometradas somam 115 minutos, sem contar uma etapa de aprovação com 8 perguntas e 3 execuções de paridade. O relatório listou 181 defeitos de estilo e 2 linhas estruturais; as duas eram estados de hover que ele não conseguia medir. O primeiro screenshot que vi não tinha tabela: um bug de especificidade de CSS tinha zerado a altura dela. Eu disse ao agente que estávamos nisso havia horas, por um resultado aquém do esforço.
Um relatório pode ser preciso sobre uma página que não existe.
Camada de IA
Onde a IA ajudou
- Escrever o código. Construí o agente com um agente de código de IA, incluindo um conjunto de comparação de cerca de 3.300 linhas, mais 84 testes. As decisões de design são minhas. O agente rascunhou a maioria das regras a partir das execuções que falharam.
- Capturar páginas, rodar probes e rastrear cada diferença até a origem.
- Manter o log de falhas.
Onde eu corrigi
- Cor. Numa reprodução, as cores exatas do app vencem: "fidelidade em tudo, cor também".
Onde eu questionei
- Tarefas de setup. Quando o agente pediu que eu rodasse scripts no meu terminal, perguntei: "você não consegue fazer isso por aqui?". Conseguia, menos em uma etapa.
- Nomes. Li uma contagem de linhas "seguras" como coisas que estavam certas; o agente renomeou essa categoria para "defeito".
Onde eu errei
- Começar com 9 agentes. Dois orquestradores (copiar e sincronizar) repetiam a mesma preparação. Um agente com dois modos substituiu os dois.
- Reprodução completa como padrão. Pelas contas do próprio agente, foram cerca de 55 minutos em estados que ninguém tinha pedido.
- Confiar na contagem de paridade. Os 181 defeitos de estilo descreviam uma página sem tabela.
Resultado
- 9 para 1agentes, do primeiro pipeline (junho) ao agente empacotado (agosto); 2 entre julho e agosto
- 164 para 0linhas de paridade bloqueantes na primeira página ajustada, em 6 rodadas. No mesmo dia, notei ícones errados que nenhuma probe media; apertar a verificação trouxe de volta 16 defeitos.
- 69falhas registradas como regras. Uma pessoa do time as transformou em 57 regras gerais de reprodução, e hoje o próprio page tracer, com todas as lições, é usado pelo time de design: como ele chegou lá.
Nenhuma das páginas reproduzidas chegou à paridade completa com probes.
Não medido: tempo economizado, duração de um rascunho rápido, se os testes passam hoje, ou uso depois de agosto. Os números de tokens vêm do próprio agente. Não há log de uso.
O que eu faria a seguir
- Registrar o uso de tokens por execução, para que o custo declarado seja medido, não só informado.
- Rodar os 84 testes numa cópia limpa e cronometrar um rascunho rápido.
- Mostrar a um stakeholder um rascunho rápido ao lado do app, para entender o que "já dá para mostrar" significa para essa pessoa.