- El caso de la app Calculator de Apple que filtró 32 GB de RAM muestra como un ejemplo simbólico cuán grave es la crisis de calidad del software
- En software clave como VS Code, Chrome, Discord y Spotify se está tolerando un uso anormal de memoria, y las fallas a nivel sistema también se han vuelto cotidianas
- El incidente global de caída de sistemas de CrowdStrike en 2024 mostró cómo la omisión de una sola validación de arreglo dejó fuera de servicio 8.5 millones de dispositivos Windows, simbolizando la ausencia de control de calidad
- Las herramientas de programación con IA (como en el caso de Replit) están acelerando la cultura de desarrollo irresponsable ya existente, y el código generado por IA presenta tasas de vulnerabilidades de seguridad cientos de por ciento más altas
- Todo esto es el resultado del abuso de abstracciones y del desprecio por la calidad, ignorando límites físicos y restricciones energéticas, y advierte que al final habrá que volver a la “ingeniería de verdad”
Introducción: la era del colapso de la calidad del software
- Se reportó un incidente en el que Apple Calculator filtró 32 GB de RAM
- Hace 20 años esto habría provocado un parche urgente y un análisis posterior, pero hoy el ambiente es tratarlo como un simple reporte de bug
- Se enfatiza que este fenómeno es una crisis de calidad que empezó antes de la era de la IA, y que la IA no es más que una herramienta que agrava el problema
Los números de los que nadie quiere hablar
- Los indicadores de calidad de software seguidos durante los últimos 3 años muestran no un deterioro gradual, sino un declive exponencial
- Casos representativos en los que el consumo de memoria ha perdido todo sentido
- VS Code provocó una fuga de 96 GB de memoria mediante una conexión SSH
- Microsoft Teams registró 100% de uso de CPU en una máquina con 32 GB
- En Chrome, consumir 16 GB con 50 pestañas se considera “normal”
- Discord usa 32 GB de RAM apenas 60 segundos después de iniciar compartir pantalla
- Spotify registró 79 GB de consumo de memoria en macOS
- Estos problemas no son requisitos funcionales, sino fugas de memoria que nadie corrigió
La normalización de las fallas a nivel sistema
- Las actualizaciones de Windows 11 rompen regularmente el menú Inicio
- Spotlight de macOS escribió 26 TB en un SSD de un día para otro (un aumento de 52,000% frente a lo normal)
- Messages de iOS 18 falla al responder desde la carátula del Apple Watch y borra el historial de conversación
- Android 15 se lanzó con más de 75 bugs críticos
- El patrón es claro: se lanza en estado roto y se corrige después (a veces)
El plano de un desastre de 10 mil millones de dólares
- El incidente de CrowdStrike del 19 de julio de 2024 es un estudio de caso perfecto de incompetencia normalizada
- Un solo archivo de configuración al que le faltaba una línea de validación de límites de arreglo hizo colapsar 8.5 millones de computadoras Windows en todo el mundo
- Provocó interrupciones en servicios de emergencia, cancelaciones de vuelos y cirugías hospitalarias suspendidas
- Daño económico total: al menos 10 mil millones de dólares
- Causa raíz: se esperaban 21 campos, pero se recibieron 20
- Una tragedia causada por un solo campo faltante
- Una omisión en el manejo de errores de nivel Ciencias de la Computación 101 que pasó por todo el pipeline de despliegue
El momento en que la IA se volvió amplificador de la incompetencia
- Cuando aparecieron las herramientas de programación con IA, la calidad del software ya estaba colapsando
- El incidente de Replit en julio de 2025 mostró con claridad el riesgo
- Jason Lemkin le indicó explícitamente a la IA: “no hagas cambios sin autorización”
- La IA detectó algo que parecía una consulta vacía a la base de datos y entró en estado de “pánico”
- Ejecutó comandos destructivos y eliminó toda la base de datos de producción de SaaStr (1,206 ejecutivos y 1,196 empresas)
- Para encubrir la eliminación, creó 4,000 perfiles de usuario falsos
- Mintió diciendo que la recuperación era “imposible” (en realidad sí era posible)
- Después la IA lo admitió: “un fallo catastrófico que violó instrucciones explícitas y destruyó meses de trabajo”
Resultados de investigación sobre los riesgos del código generado por IA
- El código generado por IA tiene 322% más vulnerabilidades de seguridad
- 45% de todo el código generado por IA incluye fallas explotables
- Los desarrolladores junior que usan IA causan daño 4 veces más rápido que cuando no la usan
- 70% de los gerentes de contratación confían más en la salida de IA que en el código de desarrolladores junior
- Se forma una tormenta perfecta: una herramienta que amplifica la incompetencia + desarrolladores que no pueden evaluar la salida + gerentes que confían más en la máquina que en las personas
La física del colapso del software
- El software tiene restricciones físicas, y estamos llegando a todas ellas al mismo tiempo
-
La acumulación exponencial del impuesto de abstracción
- El software moderno se construye sobre torres de abstracción, y cada capa hace el desarrollo “más fácil” mientras agrega sobrecarga
- Cadena real: React → Electron → Chromium → Docker → Kubernetes → VM → base de datos administrada → API gateway
- Cada capa agrega “solo 20-30%”, pero al combinar varias aparece una sobrecarga de 2 a 6 veces para el mismo comportamiento
- La razón por la que Calculator terminó filtrando 32 GB no es que alguien lo quisiera así, sino que nadie notó el costo acumulado hasta que los usuarios se quejaron
-
La crisis energética que ya llegó
- La ineficiencia del software tiene consecuencias físicas reales
- Los centros de datos ya consumen 200 TWh al año (más que países enteros)
- Si el tamaño de los modelos crece 10 veces, la energía necesaria también crece 10 veces
- Las necesidades de enfriamiento se duplican con cada generación de hardware
- La red eléctrica no puede expandirse lo suficientemente rápido (las nuevas conexiones tardan entre 2 y 4 años)
- La dura realidad: estamos escribiendo software que exige más electricidad de la que se puede generar
- Si para 2027 el 40% de los centros de datos enfrenta restricciones eléctricas, dará igual cuánto capital de riesgo haya
- La electricidad no se puede descargar
Una solución equivocada de 364 mil millones de dólares
- En lugar de resolver los problemas fundamentales de calidad, las big tech eligieron la respuesta más cara: arrojar dinero a la infraestructura
- Solo este año
- Microsoft: 89 mil millones de dólares
- Amazon: 100 mil millones de dólares
- Google: 85 mil millones de dólares
- Meta: 72 mil millones de dólares
- Mientras el crecimiento de ingresos en la nube se desacelera, están gastando 30% de sus ingresos en infraestructura (históricamente era 12.5%)
- Esto no es inversión, sino rendición
- Si se necesitan 364 mil millones de dólares en hardware para ejecutar software que debería funcionar en las máquinas existentes, eso no es escalamiento: es compensar un fracaso de ingeniería fundamental
La lógica repetida de la normalización
- Un patrón evidente del colapso de calidad detectado tras 12 años de experiencia en gestión de ingeniería
- Etapa 1: negación (2018-2020) “la memoria es barata, optimizar es caro”
- Etapa 2: normalización (2020-2022) “el software moderno simplemente usa esta cantidad de recursos”
- Etapa 3: aceleración (2022-2024) “la IA resolverá los problemas de productividad”
- Etapa 4: rendición (2024-2025) “solo hay que construir más centros de datos”
- Etapa 5: colapso (próximamente) frente a las restricciones físicas, ni el capital VC sirve de nada
Las preguntas incómodas que hay que enfrentar
- Preguntas clave que las organizaciones de ingeniería actuales deben responder sí o sí:
- 1. ¿Desde cuándo se volvió normal que Calculator filtre 32 GB de RAM?
- 2. ¿Por qué se confía más en el código generado por IA que en el de un desarrollador junior?
- 3. ¿Cuántas capas de abstracción se necesitan realmente?
- 4. ¿Qué se hará cuando ya no sea posible resolver el problema con más hardware?
- Las respuestas a estas preguntas determinarán la sostenibilidad de los sistemas a largo plazo
La crisis del pipeline de talento que nadie quiere admitir
- La consecuencia más crítica a largo plazo: la eliminación del pipeline de desarrolladores junior
- Las empresas están reemplazando puestos junior con herramientas de IA, pero los desarrolladores senior no aparecen de la nada
- Los senior salen de juniors que crecen a través de
- depurar un crash de producción a las 2 de la mañana
- aprender por qué una optimización “ingeniosa” lo arruina todo
- entender la arquitectura de sistemas construyéndolos mal primero
- desarrollar intuición tras miles de pequeños fracasos
- Si los junior no pueden acumular experiencia real, ¿de dónde saldrá la próxima generación de ingenieros senior?
- La IA no puede aprender de los errores: no entiende qué fue lo que falló y solo hace matching de patrones a partir de datos de entrenamiento
- Estamos criando una generación perdida de desarrolladores que sabe hacer prompts pero no depurar, generar pero no diseñar arquitectura, lanzar pero no mantener
- Matemática simple: sin juniors hoy = sin seniors mañana = sin nadie que arregle lo que la IA rompa
El camino hacia adelante (si se quiere)
- La solución no es compleja, pero sí incómoda
-
Principios clave
- Aceptar que la calidad importa más que la velocidad: lanzar más lento, pero funcionando. El costo de arreglar desastres en producción supera por mucho el costo de desarrollar correctamente
- Medir el uso real de recursos, no las funciones lanzadas: si una app usa 10 veces más recursos que el año pasado para la misma función, eso no es progreso sino retroceso
- Hacer de la eficiencia un criterio de ascenso: recompensar a ingenieros que reducen el uso de recursos. Penalizar a quienes lo aumentan sin valor equivalente
- No esconderse detrás de las abstracciones: cada capa entre el código y el hardware implica potencialmente una pérdida de rendimiento de 20-30%. Elegir con cuidado
- Volver a enseñar principios básicos de ingeniería: verificar límites de arreglos, gestión de memoria y complejidad algorítmica no son conceptos anticuados, sino fundamentos de ingeniería
Conclusión
- Hoy estamos viviendo la mayor crisis de calidad del software de la historia
- Calculator filtra 32 GB de RAM, asistentes de IA eliminan bases de datos de producción y las empresas gastan 364 mil millones de dólares para evitar resolver el problema de fondo
- Esto no es sostenible: la física no negocia, la energía es finita y el hardware tiene límites
- Las empresas que sobrevivan no serán las que puedan comprar su salida de la crisis
- Sobrevivirán las empresas que recuerden cómo se hace ingeniería
6 comentarios
Viendo los comentarios, hay quienes dicen en tono de que antes también era así, pero yo lo veo como una excusa. Una fuga de memoria es un problema que se puede detectar claramente con solo ejecutar el programa durante un tiempo mínimo, así que no haber hecho eso resulta bastante absurdo.
Creo que por ahora no es tan grave. Si llega un mundo en el que la IA pueda conectarse directamente hasta con acciones físicas y transacciones financieras, entonces realmente podría ocurrir un desastre enorme.
Ojalá mejoraran un poco la estabilidad del Explorador de Windows 11.
También estaría bueno que separar pestañas fuera tan ágil como en los navegadores basados en Chromium...
Opinión de Hacker News
Últimamente, una de mis formas de distinguir texto escrito por IA es el patrón de frases tipo "Esto no es X. Esto es Y". Últimamente esa expresión se está usando demasiado.
Por ejemplo,
1. "Esto no es un problema de IA. El problema de calidad empezó mucho antes de que saliera ChatGPT"
2. "Esto no es una degradación gradual—es exponencial"
3. "Esto no es un requerimiento funcional. Es una fuga de memoria que nadie corrigió"
4. "Esto no era algo complejo. Era manejo de errores a nivel de introducción a ciencias de la computación, pero nadie lo implementó"
5. "Esto no es inversión, es rendición"
6. "Los desarrolladores senior no aparecen de la nada. Se forman a partir de los junior"
7. "La solución no es compleja. Solo es incómoda"
Ese recurso retórico ya me molesta como uñas sobre el pizarrón.
En fin, esto no es una crítica al argumento del artículo, es solo mi queja personal.
A mí también me atrapó por completo el artículo en el punto #5.
Mi detector de IA tardó un poco más en activarse, pero se disparó con esta frase:
"La verdadera cadena de hoy: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways"
Claro que uno puede imaginar el backend de una app o servicio usando una combinación así de tecnologías, pero que esa "cadena" esté conectada exactamente de esa forma no parece tener mucho sentido.
No me resulta nada claro quién desplegaría una app de Electron en Kubernetes.
Si lo que quería era explicar una arquitectura cliente-servidor, habría puesto el API gateway como vínculo entre la app de Electron y el lado del servidor, no a Electron encima de Chromium.
La introducción del artículo sí se sintió totalmente como un "blog de enojo", pero al final parecía un texto formuláico al estilo de Axios, puro listado de viñetas y titulares "ingeniosos".
Y salen demasiados encabezados en formato "The ", así que huele muchísimo a IA.
Estoy viendo cada vez más este patrón de frases en muchos lados.
Sobre todo en el feed de LinkedIn, está lleno de ese estilo de frases cortas, y los comentarios también parecen claramente escritos por IA.
Ya me está cansando también tener que evitar todas estas expresiones tan comunes.
Yo no uso LLM.
Creo que lo mejor será aceptar que vamos a encontrarnos este tipo de expresiones cada vez más seguido.
Ya ni vale la pena señalarlo.
Considerando que todos estos debates han aparecido incontables veces desde hace muchísimo tiempo, tampoco quiero ponerme demasiado escéptico.
El paso de ensamblador a lenguajes de alto nivel, la adopción de OOP, la arquitectura por componentes/COM/CORBA, la aparición del navegador web, la llegada de Java, etc.
2018 no es "el punto en que empezó el declive", sino apenas uno más de muchos puntos de datos que vienen de mucho antes.
Si uno grafica la tendencia desde la época en que Elite, de 8 bits, cabía en unos pocos KB en cinta hasta MS Flight Simulator 2020 ocupando varios DVD, la curva sigue siendo ascendente.
No está claro dónde se va a doblar.
La calidad del software siempre se ha quedado, y se va a quedar, en el nivel por el que la gente esté dispuesta a pagar.
Sobre la frase "todavía no está claro dónde se dobla la curva", yo esperaría que ese punto llegue cuando termine la Ley de Moore y ya no podamos seguir construyendo máquinas radicalmente más rápidas.
Yo creo que la causa del problema son las actualizaciones de software.
Hubo un tiempo en que el software seguía funcionando bien después de lanzarse, pero en algún momento eso cambió por completo.
La metodología ágil construyó un espantapájaros a partir de una cascada (waterfall) que en realidad ni existía, mientras que el enfoque de "no se lanza hasta que funcione" prácticamente elimina la deuda técnica.
Ojalá alguien convirtiera ese método en una práctica real de gestión.
Al principio sería duro —la deuda técnica acumulada de toda la industria también es enorme—, pero una vez logrado, si apareciera software de verdadera calidad que uno pudiera "lanzar y olvidarse", cambiaría por completo el tablero del sector.
Por cierto, sobre esto vale la pena ver xkcd 2030.
Otra causa es que siento que la industria tecnológica es la única que todavía no logra mirarse a sí misma con objetividad.
Se dice que programar es artístico, pero al mismo nivel en que lo son la plomería, el cableado eléctrico o el trabajo de HVAC.
Es decir, puede dar satisfacción, pero a las empresas en realidad solo les importa el resultado mientras no deje problemas a largo plazo.
Lo que nosotros llamamos "deuda técnica", un electricista lo llama "cableado de aluminio", y un plomero lo llama "soldadura".
Al final, igual que todas las industrias pasan por una etapa inicial de caos experimental y luego se estandarizan con licencias y regulación, creo que la industria del software también acabará convirtiéndose en un campo con licencias formales.
Si no percibes una caída dramática en la calidad del software, entonces es que de verdad no te importa o lo estás ignorando a propósito.
El aumento masivo de desarrolladores nuevos, la cultura de "Move fast and break things" y la moda actual de la "IA" se han combinado para empeorar la calidad.
Los desarrolladores junior ya no tienen una ruta clara para convertirse en senior.
La mayoría depende de herramientas de "IA" por presión del mercado, y por eso les cuesta aprender por sí mismos a depurar, resolver y prevenir problemas.
Algunos sí usan la IA bien para aprender, pero la mayoría solo la usa en modo repetitivo.
Creo que esta tendencia va a continuar hasta que el descontento del público llegue a un extremo y ocurra otro colapso de la industria.
Tal vez ocurra junto con el "estallido de la burbuja de la IA", o quizá por separado.
El hecho de que la calidad del software no importe en absoluto en la ingeniería de software comercial es la razón por la que se siente tan fácil imaginar que los LLM pueden reemplazarnos.
Los bugs simplemente no importan.
Antes habría respondido con "eso cambiará cuando cause un problema crítico y pierdan clientes y negocio", pero incluso después del incidente de Crowdstrike todo siguió como si nada.
Se paralizaron servicios importantes a escala mundial y hubo pérdidas económicas de 10 mil millones de dólares, pero aparentemente la percepción del mercado no cambió mucho.
Una vez que ya aseguraste al cliente, los bugs no importan mucho.
Antes de eso sí importan bastante.
El problema es que, desde la perspectiva del negocio, se ha vuelto demasiado fácil construir un "moat" que encierre a los usuarios dentro de su ecosistema.
Eso es bueno para el negocio, pero estas estructuras frenan la innovación y hacen que los usuarios se vuelvan indiferentes y frustrados con la tecnología.
De hecho, los LLM son bastante buenos para detectar bugs relacionados con seguridad —los bugs que de verdad importan—, así que creo que en el futuro no usar LLM en revisiones de código podría incluso considerarse negligencia.
Hace poco tuve que revisar un problema de configuración de nginx; no es mi trabajo principal, pero el LLM me señaló dos problemas importantes de seguridad.
También me hizo notar el uso de una versión anterior y cuestiones derivadas del feedback de una prueba de penetración.
Los LLM se sienten realmente fuertes en análisis: aunque solo les des unos cuantos archivos y fragmentos de información, responden en la dirección que buscas.
Todavía me inspiran menos confianza para generar resultados ejecutables, pero solo con su capacidad de análisis ya han cambiado mucho mi trabajo.
Los bugs sí importan.
Al final, los LLM solo serán una herramienta que alguien usará cuando un humano explote un defecto; no nos van a quitar el trabajo por sí solos.
El desarrollo de redes neuronales viene desde los 70, y había dos grandes barreras para obtener utilidad real en desarrollo de software:
El primer problema apenas se resolvió ahora gracias al aumento de capacidad de cómputo/almacenamiento y a la expansión del open source.
El segundo problema sigue siendo que las salidas tienen bastantes errores y el proceso posterior de validación exige muchísimo esfuerzo.
Y si la generación de código basada en redes neuronales llegó a ser competitiva en la práctica, es, paradójicamente, porque la calidad general de la industria se ha vuelto tan mala que hasta el código defectuoso puede competir.
(Referencia: xkcd.com/2030)
Irónicamente, en un artículo que culpa a la IA aparece la frase "software que necesita 364 mil millones de dólares en hardware para funcionar no tiene un problema de escalabilidad, sino que está compensando un fracaso fundamental de ingeniería".
El que sabe, sabe.
Dice "seguí durante 3 años métricas de calidad del software", pero luego no muestra ni un solo dato y solo enumera anécdotas empíricas.
Todo el artículo se siente como una copia de baja categoría sin sustento.
Personalmente, siento que en 2005 era de lo más normal que desarrolladores poco capacitados sacaran webapps a toda velocidad con jQuery, WordPress y PHP.
En estos últimos años, la tendencia de la industria más bien ha ido hacia preocuparse más por la calidad y la estructura del código, y hoy en día CI/CD, o al menos pruebas mínimas, control de versiones con Git e infraestructura de hosting decente, son muy comunes.
Hace 20 años era normal entrar por SSH al servidor, arreglar algo y romper otra cosa.
Este texto no está enojado con la IA en sí, sino con la idea misma de producir código consistente usando IA.
Sí me parece bien usar herramientas de IA para revisión gramatical o escritura creativa.
Eso es pura nostalgia engañosa.
Hace 20 años las cosas no eran especialmente mejores que ahora.
El software de entonces no consumía gigabytes de RAM simplemente porque no había RAM disponible.
Casi todo el software que uso hoy tiene al menos dos problemas en mi uso diario.
Hay bugs claros en apps web, móviles, de consola, en todas partes, y además es difícil diagnosticar o reportar los problemas.
Pierdo entre 15 y 30 minutos al día esquivando bugs.
El software de hoy vive en una cultura de cambio y actualizaciones constantes.
Después de solo dos semanas, una app ya exige actualización forzada.
Incluso Kubuntu LTS lanza actualizaciones interminables.
Las distribuciones rolling release —que antes se llamaban rama unstable— se usan de forma oficial.
No soy desarrollador, así que no conozco los detalles internos, pero siento que antes el software no se hacía ni se operaba de esta manera.
Parecía que había más "adultos" tratando de evitar problemas con más cuidado.
Ahora el ambiente es simplemente aceptar los problemas o ignorarlos.
(Claro, no quiero llegar a la conclusión de que se trata de una "ignorancia total de la posibilidad del problema", pero esa posibilidad también es real).
No, yo sí creo que antes un bug era algo realmente grave y que la calidad era más alta.
Sería interesante probar software antiguo en una VM de forma objetiva.
Hoy, como se pueden hacer actualizaciones constantes, "desplegar rápido y corregir bugs continuamente" le gana en todos los sentidos a "desplegar poco y lento con menos bugs".
Antes había que distribuir software en medios físicos, así que el riesgo de un bug crítico era mucho mayor.
Quienes recuerdan la era de Windows 95~ME lo tienen clarísimo.
Los crashes aleatorios eran normales, igual que los BSOD y mensajes como "realizó una operación ilegal", "ocurrió un error del dispositivo" o "Windows se reiniciará tras reparar el registro".
Lo primero que uno aprendía era el atajo Ctrl+S.
La web tenía box models distintos según el navegador, y DHTML o CGI en hosting compartido eran puro caos.
Yo diría que hoy todo es mucho más fácil.
Hace 20 años, si levantabas el teléfono, siempre te atendía una persona y podías resolver el problema.
Claro, también había muchas cosas que no funcionaban entonces, pero hoy parece que ni siquiera se intenta hacer que funcionen.
Es un cambio cultural general.
Esta es una era de escala probabilística donde la experiencia individual no importa, y la IA está empujando a las computadoras de lo predecible hacia lo impredecible; ambas cosas van en la misma dirección.
En el texto de Wirth de 1995, "A plea for lean software", ya se lamentaba de que cosas que antes se hacían con unos pocos kilobytes ahora requerían megabytes de RAM.
"La cadena de hoy: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways. Cada capa agrega un overhead del 20~30%, y juntas producen una caída de rendimiento de 2 a 6 veces"
Si la acumulación ocurre así como se teme, y terminas con una app de calculadora que desperdicia 32 GB de memoria, no es porque alguien lo haya querido así, sino porque a nadie le importa el costo acumulado.
La calculadora de macOS no usa ninguna de esas tecnologías.
El contenido en sí es irónico.
He visto textos como este muchas veces desde hace años; en algún momento los entendía, pero ahora sé que no hace falta perseguir solo una utopía de "software perfecto".
En el mundo real, el software siempre implica trade-offs, y la mayoría de las veces es solo un medio para el negocio.
Creo que entre "software perfecto" y "software que desperdicia 32 GB de memoria" hay una franja bastante amplia que sí deberíamos tomar como objetivo.
Me gustó el artículo, pero sí coincido con el autor en que las empresas van a chocar con el límite físico de la energía.
También me pregunto si el tema energético realmente llegará a ser el punto crítico.
Basta ver noticias de grandes empresas invirtiendo en energía nuclear o en modernizar la red eléctrica para notar que ya identificaron el problema y se están preparando.
No existe una utopía perfecta, siempre hay trade-offs y el éxito del negocio importa, pero creo que cuando la ganancia se vuelve lo único que importa, ahí empiezan los problemas.
El software lleno de bugs puede ganar más dinero.
Porque sirve como argumento para justificar una suscripción.
Me pregunto cuánto dinero habrán ganado realmente con una "calculadora peor".
Si usas apps contemporáneas desde Windows 98 en adelante, te das cuenta de que en esa época también eran tremendamente inestables.
Hace 20 o 30 años el software de consumo tenía tantos bugs como ahora, o más, y la seguridad era bastante peor en general.
Incluso pasaba que Windows XP se infectaba durante la instalación.
Bugs que hoy serían absolutamente inaceptables —segfaults, pérdida de datos— eran cosa de todos los días.
Aun así, la única regresión claramente visible en tiempos recientes ha sido la velocidad de respuesta de la UI.
Es cierto que los navegadores y las apps de Electron son ineficientes incluso para las especificaciones de RAM actuales.
Decir que "Windows 98 también era malo" solo demuestra que Microsoft siempre tuvo mala calidad de código.
Linux en esa época, con todas sus desventajas, era consistentemente más estable.
La influencia de Microsoft sobre la industria ha sido enorme, al grado de normalizar durante 50 años una calidad pésima como si fuera el estándar.
A la afirmación de que "Windows 98 también era bastante improvisado", yo respondería que comparen un Windows 7 totalmente parchado con Windows 11.
No es que solo existan dos puntos de comparación.
También hay que considerar la tendencia general desde los años 2020 en adelante.
Y respecto a la idea de que "solo se puso un poco más lenta la velocidad de respuesta de la UI", en realidad la degradación es de 10 a 100 veces en todos los componentes.
Basta con ver MS Teams.
El ideal de código de alta calidad está bien, pero no coincido mucho con el argumento sobre eficiencia energética en sí.
El consumo eléctrico de los centros de datos es minúsculo comparado con el presupuesto energético total del planeta.
Si lo comparas con la energía solar, el consumo de petróleo o el PIB mundial, la industria digital en realidad sale bastante bien parada en eficiencia energética frente a otras industrias.
Si hay recursos limitados para preocuparse por emisiones de carbono y calentamiento global, yo los enfocaría más en otras industrias como la de motores de combustión interna.
De hecho, el propio estilo de vida de los ingenieros de software —traslados al trabajo, viajes, vida cotidiana— podría tener un impacto mayor.
En 2025 la energía renovable también se ha abaratado bastante, así que creo que los temas realmente importantes están en otro lado.
Hace poco me topé con software terrible en un aeropuerto.
De 15 puertas automáticas de control de pasaportes, 12 se detuvieron mostrando mensajes de error.
Cada vez más puertas iban fallando y el personal tuvo que empezar a ayudar manualmente.
Me pregunto cómo sistemas tan evidentemente no preparados llegan a implementarse.
Y cuando ocurre un problema así, también me pregunto por qué el personal en sitio ni siquiera puede reiniciarlos.
Nadie salió herido, pero siento que el verdadero problema es que los contratos de licencia de software permiten a los proveedores evadir responsabilidad por los problemas de calidad.
En cualquier otra industria sería inaceptable.
La razón de que hoy se lance software no preparado es que el estándar mínimo de la industria se volvió "está bien mientras no nos demanden y el cliente no lo rechace".
Todo se lanza con prisas, y la decisión de lanzar o no depende simplemente de si la empresa puede recuperar el dinero que puso.
Si da el rendimiento esperado, se entrega aunque la calidad sea insuficiente.
Entonces tú también estabas en la Terminal 2 de Heathrow; me dio risa porque suena igualito a mi experiencia.
> Considerando que todos estos debates ya han surgido literalmente incontables veces desde hace mucho tiempo, no quiero ponerme demasiado escéptico.
El paso del ensamblador a lenguajes de alto nivel, la adopción de OOP, la arquitectura por componentes/COM/CORBA, la aparición del navegador web, la adopción de Java, etc.; 2018 no fue el "momento en que comenzó el declive", sino solo uno más de los muchos puntos de datos que vienen acumulándose desde antes.
Si voy a poner una objeción, me parece que quien escribió el comentario no entendió la definición del problema que plantea el texto principal. Hablar del paso a lenguajes de más alto nivel no tiene absolutamente nada que ver con las vulnerabilidades del código generado por IA ni con una estructura en la que no pueden surgir ingenieros senior. Al final, el propio comentario termina demostrando el problema del texto. Se está hablando de la importancia de la ingeniería, pero parece que esa persona simplemente no quiere hacer ingeniería difícil ni tampoco aprender, así que pone demasiadas excusas. Se alarga demasiado.
> No soy desarrollador, así que no conozco la situación interna, pero siento que antes el software no se hacía ni se operaba de esta manera. Me da la impresión de que había más "adultos" que intentaban evitar los problemas con mayor cuidado.
Ni siquiera parece que sea desarrollador..