Abstração excessiva multiplica por cinco o custo de mudanças simples

{ "resumo": "## A tese: abstração em excesso tem preço mensurável\n\nO desenvolvedor Ondrej Velisek argumenta que o excesso de abstrações - um anti-padrão conhecido e já descrito por Dan Abramov ("The WET Codebase") e Sandi Metz ("duplication is far cheaper than the wrong abstraction") - deixou de ser apenas um custo de legibilidade humana. Como a IA aprendeu a programar a partir de código escrito por humanos, ela herdou e repete o hábito de abstrair demais, e esse hábito aparece na fatura de quem usa agentes de código. Sua estimativa central: desenvolver em uma base de código sobre-abstraida custa cerca de 30% a mais em conta de agentes de IA e tempo do que em uma base colocalizada - um número conservador, derivado por extrapolação, não por medição direta.\n\n## Por que abstraímos demais\n\nAbstração é a fronteira entre duas partes do código: o que ela esconde e o que a usa via interface. Ela é essencial para esconder complexidade, nomear e reutilizar código - sem ela, sistemas grandes seriam inviáveis. Mas o autor aponta quatro razões para o uso excessivo: o custo acumula lentamente e é difícil de perceber; o medo de mexer em uma camada existente leva a empilhar outra por cima (muitas vezes sob pressão de tempo); juniors são ensinados a abstrair por mentores, cursos e princípios consolidados como DRY, SOLID e separação de responsabilidades; e, numa cultura pró-abstração, é difícil aprender a enxergar o excesso e falar sobre isso em equipe.\n\n## O experimento\n\nPara sair do campo das impressões, o autor construiu duas calculadoras científicas idênticas em funcionalidades (Vite, React, Tailwind, SPA): uma colocalizada (~2.000 linhas) e outra com 12 camadas extras de abstração (~3.500 linhas). Usando o modelo Sonnet 5, a tarefa de trocar a cor de um botão custou 5 vezes mais em dinheiro e tempo na versão sobre-abstraida - resultado repetido 10 vezes com mais de 95% de confiança estatística.\n\nPara isolar a variável, ele igualou os tamanhos das bases em quatro variantes: mesmo assim, o custo seguiu 3x maior, com 2,2x mais idas e vindas do modelo (round trips), confirmando que a causa são as camadas de abstração, não o tamanho do código.\n\n## O custo depende da tarefa\n\nAo desenhar sete tarefas diferentes - de trocar um valor em uma folha até reformular o estilo de doze botões - o intervalo foi de 0,8x a 5x. Tarefas que atravessam fronteiras de arquivos (mudar um valor, enviar um valor pelo view model, editar uma string) penalizam fortemente a base abstraida. Já "encontrar e reparar um defeito" ficou 10% mais barato nela, porque abstrações bem nomeadas funcionam como índices de busca para o agente. A tarefa de reformular doze chaves favoreceu a base colocalizada (0,8x) - mas só porque o acesso ao bash foi desabilitado; com bash, o agente usava sed e a colocalizada vencia de novo (1,3x mais barata).\n\nAnalisando 394 execuções, o autor concluiu que o aumento de tamanho dos arquivos pouco importa (provavelmente por cache de contexto); o que pesa são os arquivos lidos e os round trips. Abstrações dentro do mesmo arquivo são quase gratuitas para agentes; as que cruzam arquivos são as caras.\n\n## Quando não abstrair\n\nCom exemplos práticos, o autor lista casos em que abstrair não compensa: constantes para valores simples (deixe o TypeScript guardar a validade), mapeamento de JSX sobre arrays estáticos, funções fábrica que apenas repassam parâmetros para um objeto, classes CSS sobre componentes já nomeados (a lógica do sucesso do Tailwind), hooks de context no componente errado (use no componente mais profundo dentro do escopo, evitando prop drilling junto com context) e camadas de tradução que só renomeiam valores - dobrando convenções de nomenclatura. Ele ressalva que abstrair segue sendo crucial para sistemas não triviais; a questão é onde e com que frequência colocar a fronteira.\n\n## Conclusão\n\nCada indireção cobra seu preço de humanos e de agentes, a cada leitura, todos os dias - e agora também na fatura. A recomendação final: pensar antes de abstrair, procurar excesso em code reviews, alertar o time e instruir os agentes; o autor publicou abertamente suas regras de "no-over-abstraction".", "hook": "Trocar a cor de um botão custou cinco vezes mais em uma base de código com 12 camadas extras de abstração - em dinheiro e tempo, com o mesmo modelo de IA. Depois de 394 execuções de agente, o autor estima que sobre-abstração encarece o desenvolvimento com agentes de IA em cerca de 30%.", "entities": ["React", "Tailwind CSS", "TypeScript", "Sonnet"], "themes": ["engenharia-com-ia", "economia-de-tokens"], "story_key": "over-abstracao-custo-agentes-ia", "reasoning": { "story_key": "Fato canônico: experimento mede que sobre-abstração encarece desenvolvimento com agentes de IA (estimativa de 30%, até 5x por tarefa).", "themes": { "engenharia-com-ia": "O assunto é o fluxo de agentes de código e como a estrutura do codebase afeta seu trabalho.", "economia-de-tokens": "Medição de custo de execuções de agente, round trips e tokens consumidos conforme o codebase." }, "entities": { "React": "Framework central dos exemplos (JSX, componentes, context) e do app de teste.", "Tailwind CSS": "Citado como exemplo de estilo colocalizado sem indireção.", "TypeScript": "Argumento central: o sistema de tipos pode guardar validade sem abstração.", "Sonnet": "Modelo usado no experimento principal (Sonnet 5), normalizado para a família." }, "excluded": { "Ondrej Velisek": "Autor da fonte, excluído por regra.", "Dan Abramov": "Inspiração/citação secundária, não sujeito do fato.", "Sandi Metz": "Citação secundária, não sujeito do fato.", "Vite": "Ferramenta do setup do experimento, menção secundária.", "Fable": "Modelo usado apenas para extrapolação, menção secundária." } } }