Não há razão para o software ser lento hoje em dia
Afirmações de que agentes de IA agora podem otimizar software de forma tão eficaz que “não há razão para ele ser lento” provocam forte reação contrária. Os comentaristas argumentam que o desempenho no mundo real é governado menos pela possibilidade técnica e mais pelos incentivos: empresas priorizam funcionalidades, velocidade de entrega, lock-in de cloud/SaaS e apelo visual em vez de eficiência, enquanto LLMs muitas vezes amplificam arquiteturas ruins existentes em vez de corrigi-las. Alguns relatam sucessos usando IA para otimização direcionada e veem potencial em fluxos agentic, mas a maioria espera que o software do dia a dia continue parecendo mais lento e pesado, a menos que prioridades econômicas e de produto mudem.
Incentivos econômicos e “enshittification”
- Muitos argumentam que o software é lento principalmente porque os incentivos favorecem funcionalidades, lock-in e monetização em vez de desempenho ou artesanato.
- Dinâmica de venture/PE: construir algo bom, depois aumentar preços e reduzir a qualidade; a IA torna mais barato produzir produtos “80% prontos” em escala.
- Mesmo com IA, as organizações ainda priorizarão funcionalidades visíveis em vez de velocidade invisível, a menos que o desempenho impacte claramente a receita ou a rotatividade de usuários.
IA/LLMs como ferramentas de desempenho
- Vários comentaristas relatam ganhos reais: acelerações de ordem de grandeza em caminhos críticos, motores de regex, busca/indexação, código de hidrologia e frontends web ao combinar profiling, benchmarks e reescritas iterativas com IA.
- Loops agentic de “autoresearch” mais bons conjuntos de testes/benchmarks são vistos como uma forte combinação para micro-otimização e kernels pesados em SIMD/GPU.
- A IA pode aprender rapidamente profilers e ferramentas do ecossistema (JMH, async-profiler, etc.) e tentar muitas variantes que humanos não teriam tempo de explorar.
Limites, riscos e trade-offs
- Outros acham que os LLMs produzem código lento, inseguro e cego à arquitetura por padrão; tentativas de otimização muitas vezes travam ou se ajustam demais aos benchmarks.
- Problemas difíceis: layout de memória, uso de cache, design orientado a dados e hardware, arquitetura distribuída e codebases complexas de longa duração.
- Há preocupação de que código de IA agressivamente otimizado fique inteligente demais para manter e que juniores com IA se tornem “multiplicadores perigosos” de maus designs.
- Vários observam que desempenho é apenas um eixo entre correção, segurança, estabilidade, simplicidade e manutenibilidade; “otimizar só para velocidade” é arriscado.
Arquitetura, redes e fontes reais de lentidão
- Muitos dizem que o principal gargalo é a arquitetura, não o código bruto: microservices que trocam mensagens demais, ORMs, round-trips de rede desnecessários e designs apenas na nuvem.
- Latência de rede, especialmente para usuários fora dos EUA, e backends lentos dominam a percepção de lentidão; spinners e animações muitas vezes apenas mascaram isso.
- Abordagens local-first / offline-first, CRDTs e posicionamento cuidadoso de dados são propostas como soluções melhores do que remendos de UI.
Linguagens, frameworks e bloat
- Críticas fortes ao Electron, a frameworks JS pesados e a stacks SPA para apps básicos; apelos para usar Rust/Go/C++/C ou “JS puro”/bibliotecas minimalistas.
- Contraponto: frameworks e Electron oferecem velocidade de desenvolvimento multiplataforma; a IA talvez no futuro reduza o custo de implementações nativas por plataforma.
- Alguns esperam que a escassez de RAM causada pela pressão do hardware de IA force eficiência; outros são pessimistas diante de incentivos perversos de longa data.
UX, percepção e apresentação do artigo
- Vários observam que “rápido o suficiente para o usuário médio” conduz a maioria das decisões; usuários avançados são muito mais sensíveis a atrasos e animações “falsas”.
- Tópico separado sobre o próprio site do artigo: alguns reclamam de fontes minúsculas e texto em largura total; outros gostam do estilo enxuto, sem firulas, e recorrem ao modo de leitura ou CSS personalizado.