As Skills de Agente de AI Ajudam Mais os Modelos Mais Fracos? Nós Medimos

Em um post anterior fizemos uma afirmação e admitimos que não a havíamos testado: a de que nossas skills de agente de front-end deveriam ajudar mais os modelos mais fracos e mais baratos do que um modelo de fronteira. A lógica era sólida — conhecimento que já vem pronto vale menos para um modelo que já o conhece — mas lógica não é evidência. Então rodamos o experimento. É isto que os números dizem.

A configuração

Rodamos novamente as mesmas tarefas de build com dois executores mais fracos — Haiku 4.5 e Sonnet 4.6 — com as skills e sem elas, e avaliamos com os mesmos instrumentos que usamos no modelo de fronteira (Opus 4.8). O número que importa é o ganho: o quanto a skill melhora o resultado, medido em cada nível de modelo.

Dois testes: as sete skills de conhecimento (avaliadas por correção objetiva) e a skill de processo de "polimento visual" (julgada às cegas pela qualidade).

Resultado 1: quanto mais fraco o modelo, maior o ganho

Em correção, o padrão é claro e monotônico:

A skill puxa todos os níveis até 100% — mas quanto mais fraco o modelo, maior a diferença que ela fecha. O ganho praticamente triplica do modelo de fronteira ao menor deles. Os modelos fracos sem auxílio continuavam derrubando exatamente as convenções que as skills codificam (uma estratégia de dimensionamento consistente, breakpoints que respeitam a acessibilidade, o estado da navegação mobile, sinais de desempenho); a skill as restaurava todas as vezes. Hipótese confirmada.

Resultado 2: o bom gosto se transfere para baixo — a verificação não

A skill de qualidade foi mais interessante. Julgado às cegas, o resultado com skill venceu 3 de 4 comparações diretas nos modelos mais fracos (o modelo de fronteira, rodando o loop completo de renderização, havia vencido as duas comparações dele). O avaliador novamente apontou as versões sem auxílio como o padrão genérico de AI e as versões com skill como "desenhadas sob medida".

"Os designs vencedores apostam em paletas confiantes e tipografia editorial; os perdedores se apoiam nos padrões genéricos — gradientes roxo/índigo, texto de título com gradiente, cards uniformes e centralizados."

Mas a única derrota é o resultado mais útil de todo o estudo. O menor modelo, mesmo com a skill, perdeu uma comparação — não por parecer genérico, mas por entregar uma chamada para ação com contraste quebrado (texto branco sobre fundo branco). Esse é precisamente o tipo de defeito de execução que o loop de renderizar-e-refinar da skill foi projetado para capturar ao olhar para a página renderizada — e um modelo mais fraco e sem navegador não conseguiu rodar esse loop de forma confiável.

Então as duas metades da skill se comportam de forma diferente conforme os modelos ficam mais fracos: o bom gosto entregue (um design system validado, guarda-corpos contra antipadrões) se transfere para os níveis inferiores e evita que o resultado pareça genérico. A verificação (renderizar, criticar, corrigir) não — ela precisa tanto de um navegador quanto de capacidade suficiente para julgar uma captura de tela.

O que mudamos

As descobertas têm uma correção clara: se um modelo fraco não consegue rodar o loop de olhar-e-refinar, dê a ele um piso de verificação que não dependa do julgamento do modelo. Então adicionamos à skill de polimento:

• Um portão de qualidade automatizado e sem dependências — um script que sinaliza os defeitos determinísticos (estados de foco ausentes, falta de proteção para reduced-motion, tag de viewport ausente, conteúdo escondido até o JS carregar, a paleta genérica de AI, sombras chapadas, falhas óbvias de contraste) e que precisa passar antes da entrega. Nos testes, ele reprovou corretamente as versões genéricas de base e aprovou a página de referência.
• Uma matriz de cenários — qual verificação rodar para cada combinação de força do modelo e disponibilidade de navegador, com o portão automatizado como a constante que se mantém em todos os casos.

O portão é uma heurística, não um renderizador — ele não consegue enxergar o contraste real dos pixels — então, quando um navegador está disponível, a verificação completa de renderização ainda é executada. Mas ele transforma o "acho que está bom" em um resultado verificado, independentemente de quão capaz o modelo seja.

O que isso significa para as equipes

• As skills de conhecimento são um ganho maior nos modelos mais baratos — indiscutivelmente seu melhor caso de uso. Se você roda um modelo pequeno ou econômico em produção, é de skills bem construídas que vem boa parte da sua qualidade.
• Não espere o mesmo em um modelo de fronteira — ele já conhece as convenções, então uma skill de correção mal o move.
• O bom gosto entregue viaja; a autoverificação não. Um design system eleva o resultado de qualquer modelo; o loop de olhar-e-corrigir precisa de capacidade e de um navegador.
• Dê a cada nível um portão automatizado. É assim que você impede um modelo barato de entregar o bug que ele mesmo não consegue ver.

Como a SplatDev aplica isso

Construímos sistemas de desenvolvimento aprimorado por AI ajustados ao modelo que você realmente usa — de fronteira ou econômico — com as skills, os guarda-corpos e os portões automatizados que tornam o resultado confiável naquele nível. E medimos isso: onde estão os ganhos, onde não estão e o que adicionar para fechar a lacuna.

Roda um modelo sensível a custo e quer mais qualidade dele?

Fale com a SplatDev — Construa Melhor com AI

Ou envie um e-mail para [email protected]