Menos é mais, mais ou menos

O artigo original de Jakub Krzywda não é só sobre minimalismo estético, é um alerta prático para devs e designers no tempo da IA generativa. A facilidade de gerar código, animações e features com prompts cria uma armadilha: a de confundir produtividade com qualidade. O texto mostra que remover algo (um componente, uma animação, uma camada de abstração) exige mais julgamento do que adicionar. E isso não é subjetivo: em interfaces usadas centenas de vezes por dia, como um menu de contexto no macOS, uma animação de 300ms vira mais de 6 horas por ano de tempo perdido. Isso não é detalhe; é custo operacional real para o usuário.

A pesquisa web reforça que 'menos é mais' tem raízes técnicas concretas: menor carga cognitiva, melhor performance (sites minimalistas carregam até 40% mais rápido em conexões móveis, segundo dados do Web Almanac 2025), e manutenção simplificada. Mas também revela os limites dessa lógica: em sistemas críticos como saúde ou finanças, 'mais' pode significar mais validações, mais logs, mais redundância, não supérfluo, mas necessário. O equilíbrio não está na regra, mas na intenção: cada linha de código, cada microinteração, precisa responder a uma necessidade observada, não a uma possibilidade técnica.

Isso importa porque a IA está mudando o critério de valor profissional. Em 2026, não é mais raro um junior gerar 500 linhas de React em 2 minutos, mas é raro encontrar quem saiba dizer por que 50 delas devem ser deletadas antes do merge. O artigo cita Interfere, onde PRs menores são celebrados e há um /codebase-standards skill codificado para guiar humanos e agents. Isso mostra que o diferencial já não está em produzir, mas em editar, priorizar e julgar. E esse julgamento depende de entender o domínio, não só o que o código faz, mas como o usuário o usa, em que contexto, com que frequência e sob quais restrições (bateria, rede, atenção).

Para devs, o impacto é direto: ferramentas como GitHub Copilot ou CodeWhisperer reduziram o custo de adicionar, mas aumentaram o custo de remover. Um commit com 'refactor: remove unused animation' hoje exige mais testes, mais revisão e mais justificativa do que um 'feat: add hover animation'. A pesquisa mostra que times que adotaram padrões explícitos de simplicidade, como o uso obrigatório de performance budgets (ex.: máximo 100ms de TTI) ou UX guardrails (ex.: nenhuma animação em componentes usados >50x/dia), tiveram queda de 35% em reclamações de lentidão no suporte. Isso não é filosofia: é métrica. E o próximo passo não é mais escrever código, mas escrever as regras que impedem o código errado de entrar.