Ya no hay razón para que el software sea lento
Las afirmaciones de que los agentes de IA ya pueden optimizar el software tan bien que “ya no hay razón para que sea lento” provocan una fuerte reacción. Los comentaristas sostienen que el rendimiento en el mundo real depende menos de la posibilidad técnica que de los incentivos: las empresas priorizan funciones, velocidad de entrega, bloqueo en la nube/SaaS y atractivo visual por encima de la eficiencia, mientras que los LLM a menudo amplifican la mala arquitectura existente en lugar de arreglarla. Algunos comparten éxitos usando IA para optimizaciones concretas y ven potencial en flujos de trabajo agentic, pero la mayoría espera que el software cotidiano siga sintiéndose más lento y pesado salvo que cambien las prioridades económicas y de producto.
Incentivos económicos y “enshittification”
- Muchos sostienen que el software es lento principalmente porque los incentivos favorecen las funciones, el bloqueo del proveedor y la monetización por encima del rendimiento o la artesanía.
- Dinámicas de venture/PE: construye algo bueno, luego sube los precios y recorta la calidad; la IA hace más barato sacar productos “al 80%” a gran escala.
- Incluso con IA, las organizaciones seguirán priorizando funciones visibles sobre velocidad invisible, salvo que el rendimiento afecte claramente a los ingresos o a la rotación de usuarios.
IA/LLMs como herramientas de rendimiento
- Varios comentaristas informan de mejoras reales: aceleraciones de uno o varios órdenes de magnitud en rutas críticas, motores de regex, búsqueda/indexación, código de hidrología y frontends web, combinando perfilado, benchmarks y reescrituras iterativas con IA.
- Los bucles agentic de “autoresearch” junto con buenas suites de pruebas/benchmarks se consideran una gran combinación para la microoptimización y los kernels intensivos en SIMD/GPU.
- La IA puede aprender rápidamente profiladores y herramientas del ecosistema (JMH, async-profiler, etc.) y probar muchas variantes que los humanos no tendrían tiempo de explorar.
Límites, riesgos y tradeoffs
- Otros encuentran que los LLM producen por defecto código lento, inseguro y ciego a la arquitectura; los intentos de optimización a menudo fallan o se ajustan en exceso a los benchmarks.
- Problemas difíciles: disposición de memoria, uso de caché, diseño orientado a datos/hardware, arquitectura distribuida y bases de código complejas y de larga vida.
- Preocupa que el código de IA altamente optimizado se vuelva demasiado ingenioso para mantener, y que los juniors con IA se conviertan en “multiplicadores peligrosos” de malos diseños.
- Varios señalan que el rendimiento es solo un eje entre corrección, seguridad, estabilidad, simplicidad y mantenibilidad; “optimizar solo para velocidad” es arriesgado.
Arquitectura, redes y fuentes reales de lentitud
- Muchos dicen que el principal cuello de botella es la arquitectura, no el código bruto: microservicios muy charlatanes, ORM, viajes de ida y vuelta innecesarios por la red y diseños solo en la nube.
- La latencia de red, especialmente para usuarios fuera de EE. UU., y los backends lentos dominan la lentitud percibida; los spinners y las animaciones a menudo solo la tapan.
- Se proponen enfoques local-first / offline-first, CRDTs y una colocación cuidadosa de los datos como mejores soluciones que los parches de UI.
Lenguajes, frameworks y bloat
- Fuerte crítica a Electron, a los frameworks pesados de JS y a los stacks SPA para aplicaciones básicas; se pide usar Rust/Go/C++/C o “JavaScript puro”/bibliotecas mínimas.
- Contrapunto: los frameworks y Electron aportan velocidad multiplataforma; la IA quizá acabe abaratando las implementaciones nativas por plataforma.
- Algunos esperan que la escasez de RAM derivada de la presión del hardware para IA obligue a mejorar la eficiencia; otros son pesimistas por los perversos incentivos de siempre.
UX, percepción y presentación del artículo
- Varios señalan que “lo suficientemente rápido para el usuario medio” impulsa la mayoría de las decisiones; los usuarios avanzados son mucho más sensibles a los retrasos y a las animaciones “falsas”.
- Hilo aparte sobre el propio sitio del artículo: algunos se quejan de las fuentes pequeñas y del texto a ancho completo; otros aprecian el estilo austero, sin adornos, y usan el modo lector o CSS personalizado.