Skills de Agentes de IA para Front-End: Os Ganhos, as Lacunas e uma Comparação Honesta

Em um artigo complementar, mostramos que as skills de agentes de IA podem tornar o resultado de front-end mensuravelmente mais bonito em um teste cego. Este artigo é a outra metade da história — aquela que a maioria dos posts do tipo "a IA melhorou nosso código" ignora: onde as skills não ajudaram, quanto custaram e como sabemos que a diferença é real. Se você está decidindo se vale a pena investir em skills de agentes, as lacunas importam tanto quanto os ganhos.

Construímos oito skills e as testamos de duas maneiras diferentes. O resultado mais importante é que as oito skills não são uma coisa só — elas se dividem claramente em dois tipos que se comportam de formas opostas.

Dois Tipos de Skills

É tentador tratar as "skills de agentes" como uma única alavanca. Mas não são.

Skills de conhecimento (sete delas)

Essas codificam o que é um bom front-end: arquitetura de CSS, um design system, layout responsivo, HTML semântico e acessibilidade, animação, CSS moderno e suporte a navegadores, e desempenho. São material de referência que o agente carrega sob demanda.

Uma skill de processo

A oitava, o "Visual Polish", codifica como um designer trabalha: construir, renderizar em um navegador real, tirar um screenshot, criticar em relação a uma rubrica, corrigir os pontos mais fracos e repetir — além de uma biblioteca de ativos de design system validada e uma "definição de pronto" rigorosa. Ela muda o comportamento do agente, não apenas o seu conhecimento.

Essa distinção acabou explicando todos os resultados abaixo.

Como Medimos

Duas avaliações, cada uma comparando a mesma tarefa construída com skills versus sem auxílio (sem skills):

• Avaliação de correção — sete tarefas de construção, avaliadas por verificações objetivas: usa unidades relativas, HTML semântico, estados de foco acessíveis, breakpoints baseados em em, lazy-loading nativo, e assim por diante.
• Avaliação de qualidade — duas tarefas novas (uma seção de preços e uma landing page de finanças), julgadas às cegas: um revisor independente pontuou apenas os screenshots renderizados, sem saber qual era qual, e os rótulos foram randomizados para que não fosse possível identificar padrões.

Os Números

Leia esses dois blocos em conjunto e a história completa aparece: em correção, skills e ausência de skills empatam; em apuro técnico, as skills vencem de forma decisiva — mas custam mais.

Onde as Skills Vencem (os ganhos)

1. Apuro técnico e estética — a vitória decisiva

Com a skill de processo, o resultado passou do reconhecível "padrão genérico de IA" para algo genuinamente com direção de arte — e venceu uma comparação às cegas em ambas as tarefas com alta confiança. O revisor, sem ideia de qual design era qual, apontou de forma independente as marcas registradas das versões sem auxílio: o gradiente roxo escuro e o texto de título com gradiente.

"Um tem direção de arte e é claramente um design personalizado — material de mood board. O outro se apoia nas duas maiores marcas registradas de IA genérica ao mesmo tempo. A diferença é clara, não marginal."

2. Ela detecta defeitos reais

Como a skill de processo força o agente a renderizar e olhar, ela detectou dois bugs de nível de produção que uma revisão de código não pegou: conteúdo que ficava invisível sem JavaScript e um layout que transbordava horizontalmente no mobile. Uma geração de uma única passada não pegou nenhum dos dois — porque nada a fez olhar o resultado.

3. Ela impõe suas convenções, sempre

As skills injetam de forma confiável decisões específicas do projeto que um modelo não escolheria por padrão: uma estratégia de dimensionamento consistente, media queries baseadas em em, CSS moderno condicionado a dados reais de suporte de navegadores, segurança de reduced-motion e sombras em camadas (não achatadas). Essa consistência ao longo de centenas de execuções é, por si só, uma entrega.

Onde Elas Não Vencem (as lacunas)

A parte honesta. Essas lacunas são reais e vale a pena planejar em torno delas.

As skills de conhecimento mal superam um modelo forte

Um modelo de ponta já conhece unidades relativas, HTML semântico e o básico de acessibilidade. Então, na avaliação de correção, as sete skills de conhecimento essencialmente empataram com o modelo sem auxílio — e em uma tarefa o avaliador até as pontuou um pouco abaixo. Seu valor está na consistência e em ajudar modelos mais fracos ou mais baratos, não em um ganho bruto em um modelo de primeira linha.

Elas custam mais

As execuções com skills usaram cerca de 24% mais tokens e 33% mais tempo nas tarefas de conhecimento; o ciclo completo de renderizar e iterar é ainda mais pesado (dezenas de etapas de construção e verificação, em vez de um punhado). Você está comprando qualidade com poder de computação — vale a pena quando a qualidade importa, e é desperdício quando o objetivo é "código correto, rápido".

A melhor alavanca precisa de um navegador

O superpoder da skill de processo é renderizar em um navegador real. Em um ambiente sem um, ela se degrada a uma skill de conhecimento e a maior vantagem desaparece. Planeje o toolchain de acordo.

Qualidade é difícil de medir de forma barata

Nossas verificações objetivas de correção foram ruins para julgar qualidade — elas em geral aprovaram as duas versões e produziram falsos negativos na tarefa de design. Uma avaliação genuína de qualidade exigiu um juiz cego no estilo humano. E nossa avaliação de qualidade foi pequena: duas tarefas, um revisor. Convincente, mas ainda não estatisticamente robusta.

O Insight que Une Tudo

Uma frase resume:

"Correção é um problema resolvido. Apuro técnico não é. A distância entre um front-end competente e um excepcional não é conhecimento que o modelo não tem — é bom gosto aplicado por meio de iteração, e a recusa em entregar o padrão genérico."

É por isso que adicionar mais conhecimento mal moveu a agulha, enquanto adicionar um processo — renderizar, criticar, refinar, contra um bom gosto embutido — moveu bastante. Uma instrução em texto não consegue tornar uma única passada pixel-perfect. Uma skill que força o agente a olhar seu próprio trabalho e corrigi-lo, consegue.

O que Isso Significa para as Equipes

• Não espere um ganho de correção de um modelo forte. Se sua avaliação só verifica correção, as skills vão parecer inúteis — porque você está medindo justamente aquilo que o modelo já faz.
• Invista em processo, não apenas em prompts. Os ganhos duradouros vêm dos ciclos de verificação que o agente é obrigado a executar, não de arquivos de instruções mais longos.
• Entregue bom gosto, não princípios. Padrões validados e opinativos vencem conselhos abstratos toda vez.
• Meça a qualidade da forma como os usuários a experimentam — renderize, olhe, compare às cegas. Verificações booleanas não conseguem enxergar beleza.
• Faça o orçamento para isso. Um resultado de qualidade custa mais tokens e tempo; gaste-os onde a qualidade é o objetivo.

Recomendações: Fechando as Lacunas

As descobertas apontam para uma lista de tarefas concreta — para a nossa própria suíte de skills e para qualquer equipe que esteja construindo uma:

• Escale a avaliação às cegas. Duas tarefas e um revisor comprovam a direção, não a magnitude. Expanda para mais de dez tarefas em diferentes tipos de página, adicione um segundo juiz de IA e inclua ao menos um revisor humano. Acompanhe a taxa de vitória e a confiança, não um único veredito.
• Ajuste o acionamento, não apenas o conteúdo. Uma skill que não dispara é inútil, e uma que dispara na tarefa errada é pior ainda. Execute uma passada automatizada de otimização de descrições para que cada skill seja ativada quando deve e fique quieta quando não deve.
• Faça a skill de processo degradar com elegância. Quando não houver navegador disponível, ela deve detectar isso e recorrer ao seu conhecimento e checklist, em vez de supor que pode renderizar — para que nunca perca silenciosamente sua maior alavanca.
• Consolide o conhecimento sobreposto. Oito skills carregam alguma superfície duplicada — CSS moderno, responsividade e desempenho tocam no mesmo terreno. Fronteiras mais nítidas significam menos coisas para manter à medida que a plataforma evolui.
• Roteie por intenção. Use o pesado ciclo de renderizar e iterar quando a qualidade for o objetivo; pule-o para "produzir código correto, rápido". O maior desperdício é pagar por computação de nível artesanal para uma ferramenta interna descartável.
• Meça novamente em um modelo mais fraco. As skills de conhecimento deveriam ajudar mais onde o modelo base é menos capaz; confirmar isso quantifica seu real valor para implantações sensíveis a custo.

Como a SplatDev Aplica Isso

Este é o trabalho que fazemos para os clientes: não apenas apontar uma IA para uma base de código, mas engenheirar as skills, as salvaguardas e os ciclos de verificação que tornam seu resultado consistentemente excelente — e então comprovar o resultado com uma avaliação honesta, em vez de presumi-lo. Medimos a qualidade, não apenas a velocidade, e dizemos a você onde estão os ganhos e onde eles não estão.

Quer uma IA que entregue um trabalho digno de portfólio — e um relato honesto de seus limites?

Fale com a SplatDev — Construa Melhor com IA

Ou envie um e-mail para [email protected]