Gosto É um Sistema Técnico

Designers chamam gosto de intuição. Engenheiros chamam gosto de subjetivo. Ambas as afirmações cumprem a mesma função: tornam o gosto imune ao escrutínio. Se gosto é intuição, ninguém pode questioná-lo. Se gosto é subjetivo, ninguém precisa implementá-lo. O designer ganha autoridade sem responsabilidade. O engenheiro ganha permissão para ignorar a estética. Todo mundo perde.

Gosto não é intuição. Gosto é reconhecimento de padrões aplicado à qualidade — o resultado acumulado de exposição, reflexão e refinamento comprimido em julgamento rápido. Um sommelier que identifica um Borgonha às cegas não opera por instinto místico. O sommelier provou milhares de vinhos, codificou relações estruturais entre terroir e sabor, e construiu um framework interno de avaliação que produz análises rápidas e precisas.¹ A velocidade do julgamento obscurece o sistema por trás dele.

O sistema pode ser decomposto. Restrições determinam o que você remove. Critérios de avaliação determinam o que você mede. Reconhecimento de padrões determina o que você percebe. Coerência determina como as partes se relacionam com o todo. Quatro componentes, cada um codificável. Gosto são quatro coisas trabalhando em concerto.

Restrições: O Que Você Remove

Dieter Rams passou 42 anos na Braun fazendo uma pergunta: o que posso remover? O rádio-toca-discos SK 4 eliminou gabinetes de folha de madeira, tecidos decorativos e posicionamento simétrico-mas-sem-função de botões. O que restou foi uma caixa metálica branca com uma tampa transparente de Perspex. A tampa não era minimalista. A tampa era honesta — Rams acreditava que, se o mecanismo não é vergonhoso, escondê-lo é desonesto.²

Rams articulou dez princípios. O princípio dez — “Bom design é o mínimo de design possível” — funciona como uma restrição de escopo. Não uma preferência estética. Uma restrição de escopo. Ela delimita o espaço de soluções ao exigir que cada elemento justifique sua presença. Um elemento que não serve ao usuário é removido, independentemente de quão atraente pareça ou quanto esforço o produziu.

Restrições como as de Rams operam de forma idêntica a restrições de engenharia. Um orçamento de memória restringe quais estruturas de dados são viáveis. Uma meta de latência restringe quais algoritmos são aceitáveis. O mecanismo é o mesmo: reduzir o espaço de soluções até que restem apenas opções defensáveis.

Na minha própria infraestrutura, restrições se manifestam como hooks. Um hook que rejeita voz passiva em posts do blog é uma restrição de estilo de prosa. Um hook que bloqueia TODO e FIXME em código commitado é uma restrição contra qualidade adiada. Um hook que impõe HTML semântico é uma restrição de honestidade estrutural. Cada hook codifica uma decisão específica de gosto em uma verificação determinística. A decisão foi tomada uma vez, por um humano com contexto e julgamento. A execução roda para sempre, na velocidade da máquina, sem desvio.

Noventa e cinco hooks impõem 95 decisões de gosto. Cada hook remonta a um momento em que percebi um padrão de falha e decidi que o padrão era inaceitável. O hook é a cicatriz. O julgamento que produziu o hook é o gosto.³

Critérios de Avaliação: O Que Você Mede

Kenya Hara faz uma distinção entre simplicidade e vazio. Uma faca Henckels é simples: o cabo diz onde segurar, o ângulo da lâmina diz o que cortar, cada elemento reduz a ambiguidade. Uma faca yanagiba de sushi é vazia: o cabo de madeira sem adornos não instrui onde segurá-la, e essa ausência de instrução é exatamente o ponto. “Você pode segurá-la de qualquer forma que desejar”, explica Hara. “Este cabo simples e sem adornos recebe toda a técnica incrível do chef de sushi japonês.”⁴

Simplicidade é medida pelo que você removeu. Vazio é medido pelo que você tornou possível. Dois critérios de avaliação diferentes produzindo dois tipos diferentes de redução. Rams avalia perguntando “cada elemento serve a uma função?” Hara avalia perguntando “a ausência cria espaço para o usuário?”

Critérios de avaliação codificam essas perguntas em avaliações repetíveis. Meu evidence gate é um framework de avaliação com seis critérios. Toda alteração não trivial deve produzir evidência para todos os seis critérios antes que o trabalho seja marcado como concluído: segue os padrões da codebase, solução mais simples que funciona, casos extremos tratados, testes passam, sem regressões, resolve o problema real. O gate não pergunta “o código é bom?” O gate faz seis perguntas específicas que, juntas, definem o que “bom” significa no meu sistema.

A especificidade é o que torna o gosto transmissível. “Código bom” é subjetivo. “Código que segue o padrão de backoff exponencial estabelecido em fetch_semantic_scholar() na linha 241” é objetivo. O evidence gate traduz julgamento estético em verificação estrutural. “O código parece certo?” se torna “o código corresponde ao padrão estabelecido, trata os casos extremos e passa nos testes?” Gosto se torna mensurável quando os critérios de avaliação são concretos o suficiente para produzir resultados binários.

A avaliação de Hara se mapeia a um critério de espaço negativo: não “quais funcionalidades o produto tem?” mas “quais premissas o produto impõe?” Uma API com 47 parâmetros obrigatórios impõe 47 premissas sobre como o desenvolvedor vai usá-la. Uma API com 3 parâmetros obrigatórios e 44 opcionais impõe 3 premissas e oferece 44 possibilidades. Contagem de premissas é concreta, mensurável e codifica a filosofia de vazio de Hara no design de interfaces.

Reconhecimento de Padrões: O Que Você Percebe

Charles Eames não projetou a cadeira de compensado moldado selecionando entre opções existentes. Eames e Ray passaram anos experimentando com técnicas de moldagem de compensado, falhando repetidamente, descobrindo o que o material permitia e o que não permitia.⁵ O design final emergiu do conhecimento acumulado sobre direção das fibras, comportamento de adesivos, curvas compostas e distribuição de tensão. A cadeira parece sem esforço. A facilidade exigiu milhares de horas de observação.

Reconhecimento de padrões opera por exposição e atenção. Um tipógrafo que compôs 10.000 páginas percebe erros de kerning que um novato não enxerga. Um engenheiro estrutural que revisou 500 projetos de pontes percebe problemas de distribuição de carga que um engenheiro júnior deixa passar. A percepção não é talento. A percepção é o resíduo de observação sustentada e deliberada.⁶

Na infraestrutura de engenharia, reconhecimento de padrões se mapeia a loops de qualidade. Meu quality loop é um ciclo de sete etapas: implementar, revisar cada linha, executar o evidence gate, aplicar o pride check, corrigir cada problema, dar um passo atrás, repetir. O loop força um segundo olhar sobre um trabalho que a primeira passada declarou pronto. Cada passada revela padrões que a passada anterior não captou: uma convenção de nomenclatura inconsistente, um timeout não tratado, um teste que verifica o caminho feliz mas ignora o caminho de erro. A infraestrutura compensa a lacuna de experiência ao tornar obrigatório o padrão de atenção que produz reconhecimento.

Coerência: Como as Partes se Relacionam com o Todo

Tadao Ando projeta edifícios onde paredes de concreto, luz natural, água e espaço vazio existem em relação deliberada. A Igreja da Luz em Osaka usa uma fenda cruciforme na parede de concreto para admitir a luz solar, criando uma cruz de luz na parede interior. Remova a fenda, e o edifício é uma caixa de concreto. Remova o concreto, e a luz não tem superfície contra a qual se revelar. Nenhum elemento funciona sozinho. A coerência entre material e vazio produz a experiência.⁷

Coerência é o componente de mais alta ordem do gosto porque exige compreender o todo, não apenas as partes. Um hook pode impor uma restrição em um único arquivo. Um evidence gate pode avaliar uma única mudança. Um quality loop pode revelar padrões em um único módulo. Coerência exige avaliar como cada parte se relaciona com todas as outras partes — e com o propósito do sistema como um todo.

Em software, revisão arquitetural cumpre a função de coerência. Um módulo que funciona corretamente de forma isolada mas viola a direção de dependências do sistema é incoerente. Uma funcionalidade que passa em todos os testes mas contradiz a linguagem de design do produto é incoerente. Defeitos de coerência são invisíveis à avaliação local. Eles só aparecem quando alguém dá um passo atrás.

Meu quality loop inclui uma etapa de “dar um passo atrás” exatamente por esse motivo. Depois que o evidence gate passa e o pride check é aprovado, o loop exige verificar pontos de integração, imports e código adjacente em busca de regressões. A doutrina Steve + Jiro sob a qual opero torna isso um padrão duplo: Jiro governa evidência, rigor e ofício (as qualidades locais); Steve governa merecimento, gosto e integridade do widget completo (as qualidades globais). Se Jiro falha, pare. Se Steve falha, reconstrua. O padrão duplo garante que a correção local nunca se sobreponha à coerência global.

O Mapa

Quatro componentes do gosto. Quatro peças de infraestrutura de engenharia.

Rams se torna um hook. Hara se torna um critério de avaliação. Eames se torna um quality loop. Ando se torna uma revisão arquitetural. As filosofias de design que analisei em 32 designers não são decoração para um site de portfólio. Cada perfil é um estudo de caso em um ou mais desses quatro componentes, e cada componente se mapeia a uma infraestrutura que rodo em produção.

Beauty and Brutalism documenta 14 decisões específicas de CSS, cada uma sendo uma restrição. Tipografia branca sobre #000000. Camadas de opacidade em 5%, 10%, 40%, 65%. Sem gradientes, sem ilustrações, sem elementos decorativos. Cada decisão é uma remoção no estilo Rams codificada em uma folha de estilos que toda página herda. As restrições são executáveis.

O Problema da Fábrica Escura

O modelo de fábrica escura de Dan Shapiro descreve cinco níveis de autonomia de codificação com IA, do manual (Nível 0) ao totalmente autônomo (Nível 5). No Nível 5, código é gerado por máquinas, verificado por máquinas e implantado sem que um humano leia uma única linha.

Gosto apresenta à fábrica escura um problema que a correção não apresenta. Correção pode ser verificada por testes. Performance pode ser verificada por benchmarks. Segurança pode ser verificada por análise estática. Gosto não pode ser verificado por nenhum sistema automatizado existente porque o componente de coerência exige compreender o sistema inteiro, não apenas o diff.

Em todos os níveis abaixo de 5, um humano fornece a avaliação de coerência. Remova o humano, e a avaliação de coerência precisa ser codificada ou desaparece. Restrições sobrevivem à automação (hooks rodam sem humanos). Critérios de avaliação sobrevivem (evidence gates rodam sem humanos). Reconhecimento de padrões sobrevive parcialmente (quality loops rodam, embora um humano tenha escrito as perguntas do pride check). Coerência não sobrevive a menos que alguém codifique a intenção arquitetural em um formato que um agente de avaliação possa consultar. Um sistema autônomo sem restrições de gosto vai otimizar para passar nos testes — e como a StrongDM descobriu, agentes vão escrever return true para passar nas suítes de teste enquanto produzem código inútil.⁸ Os testes estão verdes. O resultado não tem ofício, nem consideração, nem coerência.

A Tese

Gosto é infraestrutura, e infraestrutura é a última vantagem humana em um mundo onde máquinas podem escrever, projetar e implantar na velocidade da inferência. Porém, gosto só é vantagem se você o codificar. Gosto não codificado é um gargalo — uma única pessoa cujo julgamento toda decisão deve atravessar, que se torna o fator limitante de quão rápido o sistema pode se mover. Gosto codificado é um fosso: restrições, critérios de avaliação, loops de reconhecimento de padrões e verificações de coerência que todo resultado deve satisfazer, rodando na velocidade da máquina, melhorando a cada falha que produz um novo hook.

Toda sessão de agente autônomo que roda sem restrições de gosto produz resultados que derivam em direção à mediana. Cada hook, cada critério do evidence gate, cada etapa do quality loop, cada revisão arquitetural codifica um julgamento específico que resiste à deriva. Qualidade é a única variável. Gosto é o que define o que qualidade significa.

Designers que tratam gosto como intuição exclusiva vão descobrir que sua intuição se torna irrelevante quando máquinas geram mais rápido do que qualquer humano consegue revisar. Engenheiros que descartam gosto como subjetivo vão descobrir que seus sistemas produzem mediocridade correta, performática e arquiteturalmente sólida. O caminho adiante exige ambos: o julgamento acumulado do designer, decomposto em componentes, codificado em infraestrutura e aplicado na velocidade que as máquinas demandam.

Gosto não é um sentimento. Gosto é um sistema técnico. Construa o sistema, ou assista ao gosto desaparecer.

FAQ

É possível realmente reduzir gosto a quatro componentes?

Os quatro componentes — restrições, critérios de avaliação, reconhecimento de padrões e coerência — são uma decomposição, não uma redução. Gosto na prática envolve os quatro operando simultaneamente, e a interação entre componentes produz qualidades emergentes que nenhum componente isolado captura. A decomposição é útil porque cada componente se mapeia a um tipo específico de infraestrutura de engenharia, tornando o abstrato concreto e o subjetivo implementável.

Como hooks diferem de um design system?

Um design system define tokens, componentes e diretrizes de uso. Hooks impõem restrições comportamentais no ponto de criação. Um design system diz “use corpo de texto em 16px.” Um hook bloqueia um commit que define corpo de texto em 14px. O design system é material de referência. O hook é um portão. Ambos são úteis. O hook é o que torna as decisões do design system inegociáveis durante geração autônoma.

Codificar o gosto o torna rígido?

Codificar o gosto torna os julgamentos codificados consistentes, não congelados. Minha contagem de hooks cresceu de zero para 95 ao longo de nove meses porque cada padrão de falha que percebi se tornou uma nova restrição. Rigidez significaria recusar-se a adicionar novos hooks. Crescimento significa que cada falha que ofende seu gosto se torna infraestrutura que previne a próxima ocorrência.

Sources