Você não consegue testar gosto com testes unitários
Será que o “gosto” subjetivo em design de software ou UX pode ser capturado em testes ou código, especialmente quando agentes de IA estão fazendo mais da implementação? Os comentadores argumentam que, embora alguns aspectos de qualidade possam ser formalizados por guias de estilo, linters, testes de snapshot ou modelos de ML treinados com dados de aprovação/reprovação, permanece um grande resíduo contextual de julgamento que resiste a ser externalizado em regras ou testes unitários. Isso levanta questões mais amplas sobre os limites do TDD e da avaliação automatizada, o papel dos humanos como árbitros finais de design e arquitetura, e até onde os LLMs podem realmente ir além de serem colaboradores inteligentes, porém inexperientes.
Natureza de “gosto” e se ele é testável
- Muitos argumentam que você não pode testar completamente gosto com testes unitários porque:
- Gosto é a parte da especificação que você esqueceu ou não consegue articular.
- Regras precisam de exceções, cujas exceções são julgamento contextual; o que sobra é “gosto”.
- Você só consegue externalizar uma pequena fatia, parecida com regra; o resto permanece implícito.
- Outros contra-argumentam que partes podem ser codificadas:
- Comparações pareadas de “bonito ou não” podem treinar funções de pontuação de ML.
- Guias de estilo, linguagens de padrões e diretrizes de UI capturam alguns padrões compartilhados.
- Linters e scripts podem impor convenções (nomes, cores da marca, limites entre camadas).
IA, LLMs e gosto pessoal/organizacional
- LLMs são descritos como poderosos, mas presos ao nível de um “novo contratado inteligente”:
- Sem memória persistente e individualizada de longo prazo.
- RL / feedback tende a nivelar para um estilo genérico, e não para o gosto de uma pessoa.
- Modelos frequentemente tomam decisões confiantes, mas sem gosto ou arriscadas, a menos que sejam rigidamente governados.
- Abordagens propostas:
- Treinar modelos de preferência separados por pessoa/equipe; falhar quando discordarem.
- Usar agentes mais “portões” humanos ou tickets de validação antes de encerrar o trabalho.
- Tratar LLMs como devs juniores; registrar decisões em ADRs/documentação e deixá-los seguir isso.
Filosofia de testes e os limites do TDD
- Testes são vistos como uma forma de garantir que as coisas “não estejam erradas”, e não de torná-las “boas” ou de bom gosto.
- TDD pesado e testes unitários de baixo nível são criticados:
- Correção não se compõe de forma limpa; comportamento emergente aparece em níveis mais altos.
- Excesso de mocks e metas de 100% de cobertura reduzem a confiança e tornam a mudança mais lenta.
- Outros defendem TDD quando aplicado nos níveis apropriados de abstração e para bugs.
- Testes de snapshot e regressão visual são sugeridos para gráficos/UI, mas não capturam o “parece certo”.
UX, visuais e “sensação”
- Muitos observam que UIs/imagens geradas por IA frequentemente parecem baratas ou estranhas.
- Alguns acham que redes neurais conseguem reconhecer qualidades como “cafona”, dado exemplos rotulados suficientes.
- Ferramentas podem testar aspectos objetivos (cores, consistência de layout), mas o atrito subjetivo de UX ainda exige humanos.
Intuição, antropomorfismo e pragmatismo
- A intuição humana (por exemplo, sentir falha estrutural) é comparada a gosto: baseada em experiência, mas difícil de codificar.
- O uso de “nós” com colaboradores de IA levanta preocupação com uma antropomorfização sutil.
- Várias vozes defendem aceitar o “bom o suficiente”, usando IA como ferramenta de apoio enquanto humanos mantêm o gosto final e a governança.