Skills de front-end contra a cara de IA

front-end

Peça uma página de apresentação a um modelo sem falar de design. Quase sempre, ele entrega algo parecido: gradiente roxo e azul, cartões arredondados com sombra suave e botão que brilha ao passar o mouse. Funciona, mas parece o site de todo mundo.

Vejo isso como problema de configuração, não de talento. Se ninguém escolhe, o modelo usa a opção mais provável. Em CSS, essa opção costuma ser o mesmo conjunto de estilos.

Escolha o visual antes de escrever o primeiro estilo

Nos meus projetos, o LUMEN cuida das interfaces. LUMEN é o agente de front-end. Antes de escrever estilos, ele carrega skills de design, guias que ajudam a escolher como a interface deve parecer. Instalei duas em 15 de julho. A ui-ux-pro-max reúne estilos, paletas, combinações de fontes e orientações de UX, ou experiência de uso. O agente pode pesquisar essas referências. A high-end-visual-design, que uso localmente, acrescenta uma direção estética e um conjunto de tokens e componentes.

Tokens são nomes para valores de cor, espaço e formato que a interface reutiliza. Em 8 de agosto, acrescentei as skills glassmorphism, bento-ui e neomorphism. Configurei todas para carregar antes de qualquer CSS, a linguagem que define a aparência da página. Também trouxe nove skills de movimento de um repositório externo e fixei a versão em um commit, uma versão registrada do código. Assim, elas não mudam sem meu controle. Algumas não podem ser ativadas pelo modelo sozinho. Só rodam quando eu peço.

A ordem importa mais que a lista. Se o agente lê uma skill depois de escrever CSS, ela só serve como comentário de revisão. Se lê antes, a skill orienta o trabalho desde o começo. O agente usa uma paleta, uma combinação de fontes e tokens escolhidos, em vez de repetir a média da internet.

O que muda e o que continua igual

Muda o visual. Sai o gradiente automático; entram escolhas de tipografia, espaço e profundidade. Na minha avaliação, a camada de tokens ajuda: cor, canto arredondado e espaço vêm de um só lugar, e os componentes reutilizam esses valores. Sem ela, cada tela inventa o roxo outra vez. A skill também funciona como uma lista de perguntas para o modelo consultar.

Mas isso não garante que o código esteja correto. Uma skill não faz o compilador apontar erros. Dois problemas de setembro mostram isso.

Uma classe que não cria CSS

Em 16 de setembro descobri que o Tailwind, uma ferramenta que gera CSS a partir de classes no código, aceita valores fora da escala sem gerar CSS nem avisar. A classe utilitária duration-180 apareceu 61 vezes em 20 arquivos. O build, a etapa que prepara o projeto, terminou em 7,70 s.

O Tailwind lê os textos no código, compara cada um com a escala do tema e só gera CSS para os valores que encontra. Um texto desconhecido em className continua sendo texto. Por isso não há erro. A classe estava no código, mas não no arquivo de estilos. O build não mostrou problema. A correção é declarar o valor na escala do tema ou usar um valor arbitrário, escrito diretamente na classe.

A ordem no arquivo CSS decide

No dia seguinte apareceu outro problema. Quando duas classes utilitárias entram em conflito, vence a que o Tailwind escreve por último no arquivo CSS. A posição das classes em className não conta. Pôr a classe correta por último naquela lista não resolve. O código parece certo na revisão porque a leitura de cima para baixo dá essa impressão.

Uma skill de design não detecta isso. O erro não é visual: há uma diferença entre o que className diz e o CSS que o build gera.

Confira o resultado, não só o código

A lição foi conferir o resultado. Depois de mudar um estilo, abra o CSS gerado. Veja se a regra está lá e se é ela que prevalece. Isso leva mais tempo que ler a mudança no código, mas teria encontrado as 61 ocorrências antes de o build terminar.

Skills ajudam a evitar o visual genérico de IA. Só o CSS gerado mostra o que elas não conseguem ver. Uma busca por duration-180 no arquivo final não teria encontrado nada. Isso teria revelado o problema que o build deixou passar.