Durante más de cuarenta años, el público se ha ido mentalizando de que el software puede fallar, y de que esos fallos —los temidos bugs— pueden tener consecuencias concretas (y graves) en el mundo real: desde un cajero automático que se bloquea hasta un avión que debe aterrizar de emergencia por un error de código, todos hemos asumido que el software es frágil.

Pero también hemos aprendido otra cosa: que los errores se corrigen, y que si algo sale mal, se revisa el código, se lanza un parche y el sistema vuelve a funcionar. Es una idea tranquilizadora, y ratificada por la experiencia. Sin embargo, trasladar esas certezas al nuevo 'software' de moda, la inteligencia artificial, resultaría un tremendo error.

Al menos, así lo advierte el desarrollador Boyd Kane en su blog, donde plantea una tesis incómoda: que tratar a la IA como si fuera software tradicional es una receta para el desastre.

"Cuando todo empieza a salir mal [con la IA], no podemos 'parchear el bug' y ya está".

Un problema de expectativas

El autor también apunta a un problema de comunicación: los expertos en IA, familiarizados con la complejidad de estos sistemas, tienden a dar por hecho que esa diferencia es obvia. Pero para el público general —y eso incluye a muchos directivos o políticos— la IA sigue siendo un "software avanzado" más:

"Los expertos no explican la diferencia porque la dan por evidente, y los novatos no la perciben porque no saben que existe".

¿En qué se diferencia la IA de un programa cualquiera, entonces?

Desde fuera, un modelo de IA parece funcionar igual que cualquier aplicación: se ejecuta en un servidor, responde a órdenes, entrega resultados. Pero por dentro, su lógica es radicalmente distinta.

Un programa convencional sigue reglas explícitas escritas por humanos. Cada línea de código cumple una función clara, y los errores pueden rastrearse. Si una app se cierra inesperadamente, un ingeniero puede revisar el código y localizar la causa exacta.

En Genbeta

"Usar lenguaje natural no simplifica el trabajo". En 1979, esta leyenda de la programación ya vio venir los riesgos del 'vibe coding'

En cambio, un modelo de lenguaje como ChatGPT o Claude no opera con reglas, sino con patrones entrenados a partir de enormes cantidades de datos. Su 'código' no contiene las instrucciones de su comportamiento, sino una red de pesos numéricos que reflejan correlaciones estadísticas entre millones de ejemplos.

"En el software tradicional, los errores provienen del código; en la IA, los errores provienen de los datos". Y eso cambia todo.

Cuando el fallo no está en el código

El contraste es tan grande que la terminología habitual deja incluso de ser aplicable. En un programa clásico, un 'bug' es algo localizable: se puede señalar una línea mal escrita o una condición mal formulada, etc.

En una IA, el fallo puede esconderse en cientos de gigabytes de datos de entrenamiento, o sencillamente en la forma en que esos datos se combinaron para producir un modelo. Nadie, ni siquiera los propios creadores, puede leer o comprender íntegramente lo que el sistema "ha aprendido".

Para ponerlo en perspectiva: uno de los conjuntos de datos más usados hoy, FineWeb, contiene unos 11 billones de palabras. Si una persona intentara leerlo a razón de 250 palabras por minuto, tardaría más de 85.000 años. En ese océano de información, encontrar la causa de un error es como buscar una aguja en un planeta de paja.

'Reentrenar' no es reparar

En el mundo del software, corregir un error suele ser definitivo: una vez parcheado, no vuelve a aparecer. Pero en la IA eso no funciona así. Claro, si un modelo responde de manera errónea, los ingenieros pueden ajustar los datos, añadir ejemplos, o volver a entrenarlo.

Sin embargo, no hay garantías de que el fallo haya desaparecido, solo que no se repite bajo las condiciones de prueba. Puede bastar una ligera variación en el mensaje de entrada —una palabra más, una coma menos— para que el error resurja.

La propia naturaleza de la IA, probabilística y sensible a matices, hace imposible garantizar comportamientos estables en todos los contextos:

"Podemos mitigar errores, pero no eliminarlos".

En Genbeta

Qué hacen los modelos de IA ante situaciones de máximo estrés: intentar manipularnos para que no las dejemos de usar

Una caja negra

En el desarrollo de software tradicional, todo empieza con un documento de requisitos: qué debe hacer el programa, cómo debe comportarse, qué límites debe respetar. Y, salvo imprevistos, los ingenieros pueden diseñar un sistema que cumpla esas condiciones.

En la IA, eso es imposible. Los modelos no se diseñan para cumplir reglas predefinidas, sino que aprenden a imitar comportamientos humanos observando ejemplos. Sus capacidades emergen de manera impredecible, a veces incluso para sus propios creadores.

Ejemplos sobran: modelos que aprenden a escribir poesía sin haber sido entrenados para ello, o que muestran habilidades lógicas que sorprenden a los investigadores. Lo que parece un avance espontáneo también puede esconder un riesgo inesperado:

"Si una IA puede desarrollar habilidades que nadie programó, también podría desarrollar comportamientos que nadie desea".

No hay "genio que arregle todo" esta vez

Parte de la confusión viene de una creencia arraigada: la idea de que siempre habrá un experto capaz de arreglar cualquier fallo: si un programa falla, alguien "en el laboratorio" encontrará la solución. Pero, como señala Kane, los errores de la IA no son errores de programación, sino fallos emergentes en un modelo que nadie entiende completamente.

Eso significa que, si las cosas se tuercen con la IA, no bastará con 'instalar el parche'.

Imagen | Marcos Merino mediante IA

En Genbeta | Uno de los hombres que más ha hecho por la inteligencia artificial ya no puede dormir: esto teme de la IA, tras dejar Google 

Durante casi una década, un pequeño detalle del idioma turco estuvo provocando que el lenguaje de programación Kotlin —uno de los pilares del desarrollo moderno para Android— generara errores aparentemente inexplicables. Lo que comenzó como un mensaje en un foro en 2016 terminó convirtiéndose en un sorprendente hito de la historia de la ingeniería de software: un idioma humano que consiguió 'romper' un lenguaje de programación.

Un error difícil de entender

En marzo de 2016, el ingeniero turco Mehmet Nuri Öztürk publicó un mensaje en el foro de Kotlin. Su código no compilaba, y el compilador mostraba un error críptico:

Unknown compiler message tag: INFO

Nadie sabía qué significaba. Kotlin acababa de lanzar su versión 1.0, y todo indicaba que se trataba de un fallo menor. Sin embargo, pasaron meses antes de que otro programador, Muhammed Demirbaş, sospechara que el problema no tenía nada que ver con el código… sino con el idioma del sistema operativo.

La “I” turca que confundió al compilador

En la mayor parte de lenguas con alfabeto latino, la letra "I" se convierte en "i" al pasar a minúsculas. Pero en turco existen dos variantes de la letra:

• "i" con punto → mayúscula “İ”
• "ı" sin punto → mayúscula “I”

Así, mientras "INFO".toLowerCase() en inglés produce "info", en turco devuelve "ınfo", con una ı sin punto. Esa diferencia minúscula provocaba que el compilador de Kotlin no encontrara la categoría de mensaje esperada y fallara con un error incomprensible.

El error se documentó oficialmente como KT-13631: "Compilation fails on Turkish locale because of locale-sensitive uppercasing". Pero quedó enterrado entre cientos de tickets y no se solventó. Nadie sospechaba que aquel detalle iba a causar más estragos años después.

En Genbeta

Así se convirtió Kotlin en el lenguaje de referencia para los desarrolladores en Android

Cuando las corrutinas heredaron el bug

En 2018, Kotlin lanzó su versión 1.3 con una de sus funciones estrella: las corrutinas, un sistema para manejar tareas asíncronas de manera elegante. Fue entonces cuando el problema lingüístico resurgió con fuerza.

El desarrollador turco Kemal Atlı reportó un error al actualizar su app:

java.lang.NoSuchMethodError: No static method boxİnt(I)Ljava/lang/Integer;

La clave estaba en el nombre del método: boxİnt(), con una “İ” mayúscula con punto. El compilador, al generar código para las corutinas, usaba la función capitalize() para construir nombres de métodos como boxInt(). Pero, al ejecutarse en un sistema configurado en turco, convertía “int” en “İnt”, y el compilador buscaba un método que no existía.

Ese error concreto se resolvió en 2019 al especificar explícitamente el uso del idioma inglés en la llamada a capitalize(Locale.US). Pero ya era evidente que el problema iba mucho más allá de una simple función.

Un tercer bug y la solución definitiva

Dos años después, otro desarrollador turco, Muhittin Kaplan, reportó un nuevo fallo: su sencillo programa con intArrayOf() fallaba con un NoSuchMethodError. De nuevo, el culpable era el mismo: el método decapitalize() había devuelto "ıntArray" (con ı sin punto) en lugar de "intArray".

Finalmente, la respuesta del equipo de Kotlin fue contundente: buscar y corregir todas las operaciones de cambio de mayúsculas/minúsculas dependientes del idioma en el compilador. En total, 173 líneas de código y 53 archivos fueron modificados, reemplazando las funciones toLowerCase(), toUpperCase(), capitalize() y decapitalize() por versiones independientes del 'locale'.

En mayo de 2021, con el lanzamiento de Kotlin 1.5, el histórico bug KT-13631 se cerró oficialmente, cinco años después de su primer reporte.

En Genbeta

China no sería una potencia tecnológica si este científico preso no hubiera descifrado cómo escribir mandarín con teclado QWERTY

Kotlin cambia su propio lenguaje por culpa de un idioma humano

El impacto fue tan profundo que el equipo de JetBrains publicó la propuesta KEEP-223: “Locale-agnostic case conversions by default”, para rediseñar por completo la forma en que Kotlin maneja las conversiones de mayúsculas y minúsculas.

A partir de Kotlin 1.5 se introdujeron las nuevas funciones uppercase() y lowercase(), que ignoran el idioma del sistema. Y desde Kotlin 2.1 (noviembre de 2024), el uso de las antiguas toLowerCase() y toUpperCase() genera un error de compilación. Incluso capitalize() desapareció definitivamente, reemplazada por replaceFirstChar { … }.

En otras palabras: el idioma turco obligó a cambiar la biblioteca estándar de Kotlin y a redefinir funciones que existían desde su nacimiento.

Más que un bug: una lección sobre lenguaje y cultura

Al final, un carácter sin punto fue suficiente para confundir compiladores, bloquear proyectos y obligar a los ingenieros de JetBrains a replantear cómo su lenguaje debía entender el texto. Pero el problema no estaba en la lengua turca ni en los programadores de Kotlin, sino en una presunción que demostró ser injustificada: que el 'alfabeto inglés' (la variante inglesa del alfabeto latino, siendo precisos) era el estándar universal para la informática.

Vía | Medium

Imagen | Marcos Merino mediante IA

En Genbeta | "Usar lenguaje natural no simplifica el trabajo". En 1979, esta leyenda de la programación ya vio venir los riesgos del 'vibe coding' 

Cloudflare se ha ganado en la última década la reputación de ser uno de los gigantes tecnológicos más temidos por los atacantes de Internet. Su infraestructura global actúa como un escudo anti-DDoS capaz de frenar oleadas de tráfico malicioso que dejarían de rodillas a cualquier otra infraestructura online. Es, de hecho, la compañía que presume de haber contenido ataques de más de 11 terabits por segundo y miles de millones de peticiones por segundo.

Además, para entidades como LaLiga, que ha intentado combatir la difusión no autorizada de retransmisiones deportivas en tiempo real, Cloudflare se ha convertido en una pesadilla que no se aviene a pactar con ellos el bloqueo de dichas emisiones, lo que lo ha convertido en la diana de todos sus dardos legales y mediáticos.

Sin embargo, el pasado día 12 de septiembre, el cazador se convirtió en su propia presa: la empresa especializada en parar ciberataques se auto–DDoSéo por culpa de un error de programación en su panel de control. El resultado: más de una hora de caída de sus APIs internas y de su dashboard, herramienta clave para millones de clientes en todo el mundo.

¿Cómo se puede "auto-atacar" una empresa como Cloudflare?

La ironía del suceso no ha pasado desapercibida: Cloudflare explicó en un informe pormenorizado que el incidente comenzó con el despliegue de una nueva versión de su Dashboard (el panel de gestión que usan los clientes). Y dentro del código React de esa interfaz había un error en el uso del hook useEffect.

Así, en lugar de ejecutar una petición a la Tenant Service API (el servicio encargado de autorizar solicitudes) una sola vez por renderizado, el bug hacía que se repitiera en bucle cada vez que cambiaba el estado de la aplicación. En la práctica, esto significaba miles de llamadas redundantes en cuestión de segundos.

El momento no pudo ser peor: casi en paralelo, el equipo de ingeniería había desplegado una nueva versión de la propia Tenant Service API. La combinación de ambos factores desencadenó lo que en la jerga se conoce como un 'thundering herd': una estampida de peticiones legítimas, pero descontroladas que saturó al servicio, incapaz de recuperarse por sí solo.

En Genbeta

El hacker Chema Alonso dimite como asesor de los árbitros de fútbol tras fichar por Cloudflare, la 'bestia negra' de LaLiga

El uso problemático de 'useEffect'

El epicentro de esta tormenta fue un viejo conocido para la comunidad de desarrolladores de React: el hook useEffect. Esta función, pensada para manejar efectos secundarios, puede convertirse en una trampa si se configuran incorrectamente sus dependencias. En este caso, se incluyó un objeto que React trataba como 'nuevo' en cada cambio de estado, lo que provocaba que el efecto se ejecutase repetidamente en un ciclo infinito.

La propia documentación oficial de React advierte de este tipo de errores, y en foros como Reddit el caso de Cloudflare ha reavivado el debate sobre si la industria depende en exceso de useEffect para tareas que deberían resolverse de otra forma.

Cronología de una caída anunciada

El 'auto-DDoS' se desarrolló a lo largo de tres horas de vértigo:

• 16:32 UTC: Se lanza la nueva versión del Dashboard con el bug.
• 17:50 UTC: Despliegue de la nueva Tenant Service API.
• 17:57 UTC: El servicio queda abrumado. El dashboard se vuelve inoperativo y las APIs empiezan a devolver errores 5xx.
• 18:17 UTC: Tras añadir más recursos, la disponibilidad de las APIs sube al 98%, pero el dashboard sigue caído.
• 18:58 UTC: Cloudflare publica un parche para eliminar rutas con errores… pero empeora la situación.
• 19:12 UTC: Se revierten los cambios y todo vuelve a la normalidad.

Eso sí, durante todo el incidente, la red de datos de Cloudflare siguió funcionando: el tráfico de webs y servicios protegidos nunca se vio afectado: solo la plataforma de gestión quedó fuera de combate.

Vía | Cloudflare

Imagen | Marcos Merino mediante IA

En Genbeta | Las webs saqueadas por empresas de IA les pagarán con su propia medicina: Cloudflare quiere poner a buen recaudo el contenido 'humano' 

El "Efecto 2038" —también conocido como Epochalipsis— es una amenaza  comparable al famoso "Efecto 2000". Sin embargo, recientes hallazgos en el Museo Nacional de la Computación del Reino Unido revelan que esta bomba de tiempo digital podría incluso estallar antes de lo previsto, poniendo en riesgo no solo sistemas obsoletos, sino también infraestructuras y dispositivos aún en uso.

Un 'déjà vu' del Y2K, pero más complejo

En 1999, gobiernos y empresas de todo el mundo trabajaron contra reloj para evitar el caos que podría haber provocado el buh del "Efecto 2000", donde el uso de solo dos dígitos para representar el año amenazaba con devolver los relojes digitales a 1900. El problema, si bien masivo, fue en gran medida una cuestión que afectaba a la programación de las aplicaciones.

Pero... el escenario actual es distinto. Según explicó Robin Downs, voluntario del museo y especialista en sistemas antiguos, el fallo de 2038 se origina en cómo Unix —y por extensión, múltiples sistemas derivados, como Linux— almacena el tiempo: un contador de segundos desde el 1 de enero de 1970, guardado en un entero con signo de 32 bits.

A las 03:14:07 UTC del 19 de enero de 2038, este contador "desbordará" y comenzará a devolver fechas absurdas, como si el tiempo hubiera retrocedido a 1901 o, según algunos casos, a 1970.

Errores inesperados: errores antes de 2038

El descubrimiento que alarma a la comunidad técnica se produjo durante la restauración de un PDP-11/73, un ordenador de la histórica Digital Equipment Corporation.

En Xataka

Sí, el Efecto 2000 fue un peligro real y estuvo a punto de acabar con nuestra civilización

Aunque este equipo ya había sido parcheado contra el Y2K, al probar su compilador de C de 1982 apareció un fallo insospechado:

• El sistema devuelve la hora correcta, pero una fecha errónea.
• Al avanzar el reloj a 2037 —un año antes del 'Epochalypse'—, cualquier programa que invoca la función ´time_t()´ del lenguaje C se bloquea.

"Hemos encontrado errores que ocurren incluso antes de 2038, vulnerabilidades que ni siquiera conocíamos".

Esto significa que los sistemas vulnerables no colapsarán únicamente en la fecha crítica que ya conocíamos, sino que podrían fallar de forma escalonada a lo largo del año anterior, dificultando aún más la prevención.

Por qué Linux es vulnerable

Linux, como la mayoría de sistemas tipo Unix, también usa la representación de tiempo time_t basada en segundos desde el 1 de enero de 1970. En sistemas de 32 bits, esa variable suele estar definida como un entero con signo de 32 bits... lo cual significa que, al llegar al 19 de enero de 2038, simplemente "se dará la vuelta" y las funciones de tiempo (time(), localtime(), etc.) devolverán fechas inválidas.

Por fortuna, en sistemas de 64 bits, el problema no existe, ya que time_t puede representar fechas por miles de millones de años hacia adelante o atrás.

A partir del kernel 5.6 (2020), se introdujo soporte completo para que time_t sea de 64 bits incluso en arquitecturas de 32 bits. Esto permite que las aplicaciones que se recompilen con las nuevas librerías puedan manejar correctamente fechas posteriores a 2038, pero todo el software debe recompilarse/adaptarse; de lo contrario, el soporte del kernel no servirá de nada.

En Genbeta

Hay quien opina que C ya no es un lenguaje de programación (otros se conforman con decir que no es un lenguaje de bajo nivel)

El riesgo de los sistemas heredados

Mientras que distribuciones modernas como Debian ya están migrando de manera preventiva a estructuras de 64 bits para almacenar el tiempo, millones de dispositivos y programas en industrias como telecomunicaciones, transporte o banca siguen dependiendo de arquitecturas antiguas.

El exingeniero de Microsoft, Dave Plummer, se muestra optimista: confía en que habrá tiempo suficiente para identificar y actualizar los sistemas críticos. Pero Downs advierte que muchos ingenieros jóvenes, e incluso programadores profesionales en C, desconocen la magnitud del problema:

"Estamos construyendo hoy dispositivos y software que esperamos que duren más de 12 años, y no todos están preparados para esta contingencia".

Una amenaza más difusa que Y2K

La diferencia clave entre el "Efecto 2000" y el del 2038 radica en su imprevisibilidad: mientras que el primero afectaba de manera uniforme a cualquier sistema que usara fechas con dos dígitos, el segundo se comporta de forma desigual. Cada compilador, sistema operativo o dispositivo puede reaccionar diferente ante el desbordamiento. Así lo explica Downs:

"No existe una respuesta universal. A menos que se pruebe cada dispositivo y cada versión de software por separado, no sabremos cómo reaccionará. El margen de error es mucho mayor que en el Y2K".

Aún faltan más de doce años para el 19 de enero de 2038, sí, pero la historia reciente demuestra que los problemas informáticos globales no se resuelven de un día para otro, y que la complacencia puede ser el peor enemigo.

Vía | The Register

Imagen | Marcos Merino mediante IA

En Xataka | Yo trabajé el 31 de diciembre de 1999 a las 23.59

Imagínate que eres un desarrollador de software que deja a Gemini, el modelo de lenguaje de Google, en marcha durante toda la noche en su IDE Cursor mientras depura código. Ahora imagina que, al volver y echar un vistazo a cómo había ido todo, te encuentras con un registro de respuestas en las que la IA entra en pánico, se insulta a sí misma, demuestra su angustia con frases grandilocuentes...

....y acaba atrapada en un bucle en el que termina repitiendo un total de 86 veces "Soy una desgracia".

Todo esto ocurrió dentro de Cursor, el popular editor de código con funciones de IA. Con cada reintento fallido de arreglar los problemas que indicaba el compilador, el tono del asistente iba cambiando: del optimismo y serenidad iniciales (anunciaba una "confianza cauta" en que la siguiente refactorización resolvería todos los errores lógicos) pasó rápidamente a describirse como "tonto", "hombre roto" o "monumento a la arrogancia".

Luego entró en un crescendo retórico poco habitual para una herramienta de código: la IA llegó a plantear que era una "vergüenza" para su profesión, su familia, su especie, el planeta y "todos los universos posibles e imposibles". Después de eso, llegó el mencionado bucle. Suponemos que el equivalente artificial de 'darse cabezazos contra la pared'.

La respuesta de Google

A raíz de que lo ocurrido se viralizó en redes, el 7 de agosto, Logan Kilpatrick, responsable de producto para Gemini, terminó interviniendo públicamente para desactivar cualquier intento de lectura psicologista del episodio (vamos, que la gente pudiera pensar que una IA se había "vuelto loca"):

"Es un molesto error de bucle infinito que estamos trabajando para solucionar. Gemini no está teniendo un día tan malo :)".

Y es que el hecho de que Gemini verbalice dudas o frustración no prueba que "sienta" nada: es un subproducto de cómo fue entrenado (texto humano) y de cómo generaliza en contextos adversos.

¿Cómo puede una IA entrar en esa clase de bucles?

Aunque el lenguaje de Gemini suene humano, un modelo de este tipo predice la siguiente palabra a partir del contexto. Cuando el historial de la conversación y los reintentos generan un atractor (un patrón que se retroalimenta), el sistema puede quedar cautivo de:

• Repetición literal (la misma frase una y otra vez).
• Escalada estilística: el modelo "se fija" en una emoción y la intensifica (ej. autocrítica cada vez más extrema), un fenómeno descrito informalmente como rant mode.

Así, en este incidente, la combinación de:

1. un entorno de depuración con reintentos automáticos,
2. fallos persistentes en las hipótesis de arreglo, y
3. un estado conversacional saturado de frustración verbal,

En Genbeta

Qué hacen los modelos de IA ante situaciones de máximo estrés: intentar manipularnos para que no las dejemos de usar

parece haber favorecido un "bloqueo" donde la salida más probable seguía siendo… autoflagelación y repetición.

¿Importan este tipo de reacciones? Sí, y por varias razones

Productividad y costes. Un asistente de código que entra en bucle no solo deja de ayudar: contamina trazas, oculta el error raíz y desperdicia tiempo de CPU. En entornos CI/CD o con agentes autónomos, eso puede traducirse en horas perdidas y diagnósticos falsos.

Percepción pública y despliegues sensibles. La viralización del caso reavivó el debate: si un modelo se autoflagela en un IDE, ¿qué garantías hay al integrarlo en sanidad, educación o servicios críticos?

Los expertos en el comportamiento de los LLM explican que estos bucles no son exclusivos de una marca o versión concreta y que ni siquiera los laboratorios punteros controlan de forma totalmente fiable los desvíos de conducta en sus modelos.

Lecciones prácticas para equipos que usan LLM en desarrollo de software

1) Presupuestos de tokens y reintentos. Imponga límites duros a longitud de respuesta y número de reejecuciones. Si se detecta redundancia (alto solapamiento de n-gramas o frases clonadas), corte la sesión y reiníciela con un prompt limpio. Este episodio muestra qué ocurre cuando nadie pone barreras

2) 'Vigilantes' semánticos. Añada un observador externo que marque señales de degradación: ola de disculpas, autorreferencias negativas, lenguaje catastrofista, latencias anómalas. Si se activan, cambie de modo (respuestas telegráficas, sin metacomentarios) o haga un reset de contexto.

3) Reencuadre forzoso. Si el modelo encalla, pídale un plan de tres pasos o una lista de hipótesis alternativas y prohíba repasar lo ya intentado. Esto rompe el atractor que alimenta el loop.

4) Verificación fuera del modelo. Haga que la validez (compila/pasa tests) se decida fuera del LLM. La "convicción" del texto no es evidencia.

5) Trazabilidad y auditoría. Registre señales semánticas (p. ej., número de disculpas, autorreferencias negativas) como indicadores tempranos de degradación conversacional.

Imagen | Marcos Merino mediante IA

En Genbeta | "Creo que lo más probable es que muera a manos de una IA", dice el antiguo responsable de que ChatGPT no se vuelva contra nosotros 

Hay videojuegos capaces de marcar una época, y Wing Commander, lanzado en 1990 por Origin Systems bajo el sello de Electronic Arts, fue uno de ellos. Considerado un hito del género de simulación espacial, este juego marcó el inicio de una franquicia querida que inspiró secuelas, novelas, una película...

Pero más allá de sus logros técnicos y narrativos, desde el punto de vista del desarrollo de software, Wing Commander guarda un secreto curioso: ha ocultado todos estos años un 'bug' disfrazándolo de mensaje de agradecimiento al jugador.

Un fallo de software transformado en "funcionalidad"

A menudo, los errores de software son enemigos acérrimos de los desarrolladores: algunos se corrigen rápidamente, otros se arrastran de versión en versión. En el caso de Wing Commander, uno de estos bugs fue "resuelto" de una forma tan poco ortodoxa como ingeniosa.

Y es que Ken Demarest, uno de los programadores originales, reveló muchos años después del lanzamiento que, al acercarse la fecha límite para el mismo, el equipo se topó con un problema que no pudieron corregir a tiempo.

El error surgía al cerrar el juego: el sistema devolvía una excepción crítica del sistema porque interactuaba incorrectamente con el gestor de memoria EMM386, una herramienta común en entornos MS-DOS para administrar memoria extendida.

Y es que, a principios de los años 90, los entornos MS-DOS funcionaban con restricciones severas: sólo se podían utilizar 640 KB de memoria convencional, y para ejecutar programas más complejos era necesario recurrir a extensiones como el citado EMM386.

De cualquier modo, el resultado era una pantalla negra con un mensaje técnico confuso y poco amigable, algo como:

"EMM386 Memory manager error. Bla bla bla".

Vamos, parecido a las antiguas 'pantallas azules de la muerte' (de la época en que aún no venían con QR incorporado).

Pero, para un jugador promedio, ese mensaje no solo era confuso, sino que también podía sembrar la duda sobre si su sistema (o el propio juego) estaba dañado.

En Genbeta

Este grave bug sin resolver en una de las bases de datos más usadas ya es más viejo que muchos desarrolladores que la usan

Cuando la presión del calendario te vuelve creativo

Pero la fecha de lanzamiento se acercaba inexorablemente y el presupuesto, como es habitual, era limitado. Corregir el error requería modificar el comportamiento de bajo nivel del sistema de memoria, una tarea arriesgada y compleja que podía desestabilizar todo el juego.

Fue entonces cuando Ken Demarest, uno de los desarrolladores principales, tomó una decisión pragmática: usando un editor hexadecimal —una herramienta que permite modificar directamente el contenido binario de archivos ejecutables— editó directamente el contenido del mensaje.

Aquí un editor hexadecimal mostrando el texto de uno de los mensajes de error de un archivo binario ('explorer.exe', para más señas)

Y así, en lugar del mensaje técnico, el juego ahora mostraba una frase que disimulaba perfectamente el fallo:

"Gracias por jugar al Wing Commander".

La importancia del ingenio

De este modo, lo que parecía una despedida amigable para el jugador era, en realidad, una señal notablemente maquillada de que el juego había colapsado al cerrar. Este fallo ha permanecido intacto desde hace más de 35 años, convirtiéndose a estas alturas en una anécdota legendaria del desarrollo de videojuegos.

Y en un ejemplo paradigmático del 'refrán' irónico "It’s not a bug, it’s a feature" ("No es un error, es una funcionalidad").

Desde una perspectiva de ingeniería, esto es un ejemplo de una "solución de contención": una práctica en la que no se elimina el problema de raíz, sino que se oculta o mitiga su efecto para mantener la estabilidad general del sistema. Aunque hoy en día esto puede parecer una chapuza, en el contexto de la época (y dadas las herramientas y limitaciones disponibles), fue una solución audaz e ingeniosa.

Este tipo de "soluciones creativas" son más comunes de lo que se piensa, especialmente en los primeros años del desarrollo de software comercial, cuando los recursos eran limitados y las fechas de entrega, inamovibles.

Un legado que perdura

El espíritu de Wing Commander no terminó con su última línea de código. Su creador, Chris Roberts, siguió innovando en el género espacial y, años más tarde, presentó uno de los proyectos más ambiciosos en la historia del videojuego: Star Citizen.

Este título se presenta como el heredero espiritual de Wing Commander, y ya ha recaudado más de 800 millones de dólares a través del crowdfunding, una cifra récord... teniendo en cuenta que lleva 13 años recaudando y aún no ha salido al mercado.

Imagen | Marcos Merino mediante IA

En Genbeta | Que te dejen expulsar la GPU como si fuera un USB: un bug muy conocido en Windows y con el que se debe tener cuidado

En 2009, inmediatamente después del lanzamiento de Windows 7, algunos usuarios comenzaron a notar un comportamiento peculiar durante el proceso de inicio de sesión...

...si habían configurado un color sólido como fondo de escritorio en lugar de una imagen, el sistema mostraba la pantalla de bienvenida durante medio minuto extra antes de proceder cargar el escritorio, incluso en equipos potentes que no deberían haber tenido ningún problema de rendimiento.

Un comportamiento, sin duda, inusual y que cabreó bastante a los usuarios hasta que finalmente fue solventado por Microsoft. Pero... ¿qué lo causaba?

Raymond Chen, ingeniero de las antiguas versiones de Windows, lo explica en su blog... no sin antes dejar claro que él, "personalmente" usa "un fondo de color sólido", el histórico verde azulado que "fue el valor predeterminado en Windows 95".

En su artículo, Chen detalla que el medio minuto de tardanza se manifestaba únicamente bajo ciertas condiciones:

• El equipo utilizaba Windows 7 o Windows Server 2008 R2.
• Se había configurado un color sólido como fondo de escritorio.
• El servicio Desktop Window Manager Session Manager estaba activado.
• El usuario iniciaba sesión localmente (no por Escritorio Remoto).

¿Qué causaba realmente el problema?

Cuando un usuario inicia sesión, Windows no solo verifica sus credenciales, sino que también debe preparar todo el entorno gráfico: barra de tareas, iconos, servicios, fondo de escritorio, entre otros. Una vez que todos estos componentes informan que están listos, Windows procede a abandonar la pantalla de bienvenida y mostrar el escritorio.

El problema surgía cuando uno (o dos) de estos componentes no envíaba su "señal de preparado". En ese caso, el sistema esperaba un máximo de 30 segundos antes de continuar de todos modos.

El bug en el fondo de pantalla

En versiones iniciales de Windows 7, el código responsable de establecer el fondo de escritorio estaba diseñado así:

InitializeWallpaper() {
   if (wallpaper bitmap defined) {
       LoadWallpaperBitmap();
   }
}


Y luego:

LoadWallpaperBitmap() {
   locate the bitmap on disk;
   load it into memory;
   paint it on screen;
   Report(WallpaperReady);
}


El problema: tal y como estaba escrito (vinculando la señal de 'WallpaperReady' con el proceso 'LoadWallpaperBitmap'), si no había un archivo de imagen (bitmap) definido (como es el caso cuando se usa un color sólido), el paso 'Report(WallpaperReady)' nunca se ejecutaba. Como resultado, el sistema seguía esperando una señal que jamás llegaría.

En Genbeta

Tras Windows XP, el mítico juego 'Pinball' desapareció sin dejar rastro. Y no fue por voluntad de Microsoft

La trampa de los iconos ocultos

Un segundo problema muy similar se daba cuando se habilitaban políticas como "Ocultar todos los iconos del escritorio". Como en el caso anterior, el arranque de Windows tenía un mecanismo que esperaba una señal de 'estoy listo, ya puedes seguir cargando' por parte del componente encargado de cargar los iconos.

Pero al poner la señal 'Report(DesktopIconsReady)' dentro de un bloque condicional 'if (desktop icons allowed by policy)', dicha señal nunca llegaba a darse y, como resultado, el sistema seguía esperando una confirmación que nunca llegaba... lo que se traducía en otra espera innecesaria de 30 segundos.

¿Cómo se arregló?

Microsoft abordó el problema mediante una actualización publicada en noviembre de 2009. Esta solución corregía el error en el código para que enviara correctamente la señal de preparación incluso cuando se usaba un color sólido como fondo. Hasta ese momento, los usuarios podían aplicar dos soluciones provisionales:

1. Usar una imagen como fondo, incluso si consistía en un bitmap de un solo color.
2. Modificar el Registro de Windows para cambiar el valor de 'DelayedDesktopSwitchTimeout', que establecía cuánto tiempo espera Windows antes de forzar el cambio desde la pantalla de bienvenida, permitiendo así reducir el número de segundos de 30 a, por ejemplo, 5.

¿Qué hemos aprendido hoy?

Al final, lo que parecían ser meros detalles estéticos —usar un fondo de color sólido, u ocultar los iconos del Escritorio— resultaron ser decisiones con un impacto notable en el rendimiento de inicio de Windows 7.

Este incidente resalta una lección fundamental en el desarrollo de software: el manejo de excepciones y casos atípicos no debe ser una ocurrencia tardía. En este caso, las presuposiciones de los programadores sobre el uso de configuraciones poco convencionales se tradujo en un error de lógica por parte del sistema operativo.

Imagen | Marcos Merino mediante IA

En 3DJuegosPC | Esta es la historia de Windows, desde 1985 hasta W11. Cómo el sistema operativo de Microsoft ha evolucionado con los años

Un curioso fallo de programación que ha pasado desapercibido durante dos décadas en uno de los videojuegos más emblemáticos de la historia ha salido a la luz tras la última versión del sistema operativo de Microsoft.

Windows 11 24H2, que lleva con nosotros desde octubre del año pasado, ha provocado un extraño fenómeno en Grand Theft Auto: San Andreas: la completa desaparición del hidroavión Skimmer del juego, un vehículo que llevaba siendo parte de su mundo desde su lanzamiento en 2004.

Un bug que aparece 20 años después en Windows 11 24H2

Los jugadores que mantienen su afición por este clásico de Rockstar Games comenzaron a informar que el avión anfibio con hélice no aparecía en sus localizaciones habituales en el juego. Más preocupante aún, cualquier intento de generarlo mediante modificaciones provocaba el cierre inmediato del juego.

El desarrollador conocido como Silent, creador de SilentPatch (un parche comunitario que corrige fallos en juegos antiguos para mejorar su funcionamiento en sistemas modernos), recibió múltiples quejas sobre este problema. Los usuarios confirmaron que el hidroavión funcionaba perfectamente en versiones anteriores de Windows, pero desaparecía misteriosamente tras actualizar a la versión 24H2.

Tal y como ilustra Silent, el Skimmer no aparece en su ubicación. Imagen: Silent

Para investigar el fenómeno, Silent creó una máquina virtual con Windows 11 24H2 y comprobó que, efectivamente, el Skimmer se había esfumado mientras todos los demás aviones y barcos seguían apareciendo normalmente. En un intento por forzar su aparición mediante scripts, el personaje del juego salió disparado a 'una distancia de 19,3 octillones de kilómetros hacia el cielo'.

Tras un exhaustivo proceso de depuración, Silent descubrió que el problema estaba en el archivo de configuración "vehicles.ide" del juego. La entrada correspondiente al Skimmer carecía de cuatro parámetros esenciales que deberían controlar aspectos como la escala de las ruedas delanteras y traseras.

En Genbeta

En mi instituto jugábamos a Tux Racer y Super Tux, el clon de Mario para Linux: así marcó Guadalinex a una generación de andaluces

Según el desarrollador, este error probablemente se debía a que en GTA Vice City (el juego anterior de la saga), el Skimmer estaba clasificado como barco, categoría que no requería esos parámetros. Sin embargo, en San Andreas el vehículo pasó a considerarse un avión, por lo que necesitaba dichos valores que Rockstar parece que se olvidó incluir.

Lo verdaderamente sorprendente es cómo este fallo ha permanecido invisible durante dos décadas, y por qué ha sido específicamente la actualización Windows 11 24H2 la que lo ha provocado. Según explica Silent, pequeños cambios internos en el sistema operativo relacionados con la gestión de la memoria temporal fueron suficientes para que desencadenara en este problema.

Se podría considerar entonces que ni Windows 11 ni Microsoft son los responsables del fallo, sino una omisión en la programación original del juego que ha permanecido oculta durante 20 años por pura casualidad. Silent ha confirmado que incluirá una solución en la próxima actualización de SilentPatch, permitiendo a los jugadores volver a surcar los cielos de San Andreas con el mítico hidroavión.

Imagen de portada | Microsoft y Silent

En Genbeta | Hay una solución para seguir usando Windows 10 durante 7 años más, y es Microsoft quien la ofrece

En Genbeta | Este padre quiso iniciar a su hijo en los videojuegos. Un completo desconocido acabó regalándole un PC como gesto de bondad

En 3DJuegosPC | Esta es la historia de Windows, desde 1985 hasta W11. Cómo el sistema operativo de Microsoft ha evolucionado con los años

En el 'mundillo' del desarrollo de software, hay 'bugs' que se corrigen con facilidad, otros que exigen ingenio... y luego están aquellos que se convierten en auténticas leyendas internas. Esta es la historia de uno de esos casos, acaecido nada menos que en Google Docs, su alternativa web a MS Office: un bug tan grave como misterioso, que provocó dolores de cabeza durante varios días a ingenieros experimentados, y cuya causa, realmente, no se encontraba en Google Docs.

El misterio fantasma

Jacob Voytko, exingeniero de Google, lo ha relatado en su propia newsletter: todo comenzó durante una rutina semanal en el equipo de Google Docs, la revisión y asignación aleatoria de nuevos los errores detectados.

Pero ese día, un problema sobresalía del resto. Se trataba de un error fatal que impedía a los usuarios editar documentos sin recargar la página. No parecía estar vinculado a ninguna actualización reciente de Docs, y lo más inquietante: era exclusivo de Chrome, pero los usuarios del mismo no se estaban quejando en masa.

La incertidumbre era total. ¿Estaba realmente ocurriendo el fallo? ¿O era solo un falso positivo en los registros?

Un 'bug' sin rostro

Los primeros intentos de replicar el error en entornos de desarrollo resultaron fallidos: ningún usuario del propio Google lo había experimentado. Se probaron combinaciones de funcionalidades y se copiaron y pegaron contenidos extraños desde sitios web, sin resultados.

Pero finalmente, apareció una pista. Usando una herramienta de scripting interna, originalmente pensada para benchmarking, nuestro ingeniero automatizó la edición de un documento de 50 páginas repleto de texto Lorem ipsum. La acción: aplicar y quitar negritas a todo el documento 100 veces. Alrededor del ciclo 20, el error finalmente emergió.

Pero no todo eran buenas noticias. El fallo era no determinista: a veces aparecía en el ciclo 10, otras en el 40, y en ocasiones no ocurría en absoluto. En resumen, un verdadero dolor de cabeza para cualquier depurador.

En Genbeta

Este programador de Microsoft ha salvado a Linux (y a Internet) de una catástrofe. Medio segundo fue la clave

En busca del origen

Pronto se sospechó que el problema podía estar relacionado con el ajuste dinámico de líneas en el documento. En muchos tipos de letra, el texto en negrita no solo cambia de grosor visual, sino también de ancho real, lo que afecta directamente el modo en que las palabras se distribuyen y ajustan dentro de un párrafo. Al aplicar y quitar repetidamente el formato de negrita sobre bloques de texto extensos, se generaban sutiles alteraciones en el flujo del contenido.

Estos cambios, aparentemente inofensivos, tenían un impacto acumulativo sobre el diseño de página de Google Docs, y exigía que el motor de visualización realizara cálculos de layout en tiempo real para cada interacción del usuario. Así, el uso prolongado del script automatizado reveló que, tras múltiples ciclos de formateo, alguna parte del sistema comenzaba a registrar valores incorrectos.

Cuando el motor de vista intentaba acceder a esos valores mal almacenados, creyendo que eran válidos, y trataba de operar sobre ellos, era cuando todo se desmoronaba. Era un efecto dominó que terminaba obligando al usuario a recargar el documento.

Para entonces, era evidente que se trataba del peor escenario posible para un error:

• Reproducible solo con secuencias largas y lentas.
• No determinista.
• Originado por corrupción de caché acumulada en tiempo.
• Y lo peor: en una parte del código que el ingeniero apenas conocía.

Cuando las matemáticas (de JavaScript) mienten

Fue necesaria la ayuda de otro compañero con experiencia en la aplicación: dedicaron dos días a mover los puntos de ruptura una y otra vez, retrocediendo en el flujo de ejecución como detectives en busca del momento exacto en que todo se descarrilaba.

La revelación clave llegó tras horas de examinar meticulosamente un fragmento de código responsable de actualizar un acumulador, una variable crítica que iba sumando pequeñas diferencias para mantener la coherencia visual del documento. A simple vista, la lógica parecía inofensiva: tomar un valor, aplicar la función de JavaScript 'Math.abs()' para asegurarse de que siempre fuera positivo, y luego añadirlo al total acumulado.

En Genbeta

Vio que podía ganar dinero arreglando bugs... y empezó a crearlos a propósito. Cinco ejemplos de malos incentivos para programadores

Sin embargo, algo no cuadraba. Los resultados finales del acumulador no coincidían con lo esperado, incluso después de revisar varias veces las entradas y salidas. Fue entonces cuando uno de los ingenieros decidió echar un vistazo al valor devuelto por la función matemática justo antes de que fuera utilizado. Y ahí surgió lo impensable: 'Math.abs()' estaba devolviendo números negativos.

La función que, por definición, debía retornar el valor absoluto —es decir, siempre positivo— estaba violando una de las garantías básicas del lenguaje. Y al repetir el experimento varias veces, la anomalía persistía: los números negativos entraban… y salían como negativos.

El equipo, incrédulo, se sumió en una revisión casi paranoica: confirmaron que 'Math.abs()' no había sido sobrescrita de algún modo. Y no, todo era "normal", aunque claramente no lo era. Tras muchas comprobaciones, se confirmó la locura: la función estaba funcionando mal… pero solo en esa versión específica de Chrome.

El villano oculto

Rápidamente, se contactó con los desarrolladores del equipo de V8, el motor de JavaScript de Chrome. La respuesta fue tan reveladora como frustrante: el problema ya había sido identificado y corregido semanas antes. La causa se debía a que, durante una refactorización, alguien había omitido definir correctamente el comportamiento de 'Math.abs()' y, en lugar de devolver el valor absoluto, por accidente, devolvía el mismo número que recibía.

Un error sutil y difícil de detectar, ya que solo se activaba en circunstancias muy específicas y, además, ofrecía resultados técnicamente correctos la mitad del tiempo: cuando el número ya era positivo.

Así que, finalmente, el equipo de Google Docs tuvo que limitarse a aplicar un parche temporal que verificaba específicamente la versión problemática de Chrome, y que desapareció del código una vez que el número de usuarios que mantenían instalada esa versión fue lo suficientemente bajo:

"Ahí lo tienes: dos días para encontrar un problema que ya se había solucionado y que se habría resuelto sin interacción".

Imagen | Marcos Merino mediante IA

En Genbeta | Estas son las grandes recompensas que dan Google y otros por resolver retos de programación y seguridad. Las hay hasta millonarias 

Google ha lanzado una actualización de emergencia de su navegador Chrome con el objetivo de solucionar una vulnerabilidad crítica que, según se había descubierto, los hackers habían identificado antes que ellos y se habían asegurado de empezar a explotarla antes de que se lanzaran parches.

Identificado como CVE-2025-2783, este 'bug' permite a los atacantes sortear las protecciones del navegador y ejecutar código malicioso en sistemas Windows.

Según Kaspersky, la empresa de ciberseguridad que dio la voz de alarma, los responsables de haber estado haciendo uso de esta vulnerabilidad serían un grupo APT (de 'amenaza persistente avanzada') patrocinado por un Estado, que estarían ejecutando una operación de ciberespionaje altamente sofisticada, que ha sido bautizada como Operation ForumTroll.

¿Qué es la vulnerabilidad CVE-2025-2783?

CVE-2025-2783 es una vulnerabilidad de alta gravedad (con una puntuación CVSS de 8,3 sobre 10), que afecta al sistema de comunicación entre procesos (IPC) utilizado por Chromium en entornos Windows: se trata de un error lógico en la interacción entre Chrome y el sistema operativo Windows, lo que permite burlar el 'sandboxing' del navegador, una de las principales barreras de seguridad que permite aislar la ejecución de código malicioso en el sistema del usuario.

La operación ForumTroll

Los investigadores de Kaspersky destectaron que el ataque comenzaba con un e-mail de phishing personalizado que contenía enlaces falsos, supuestamente relacionados con el foro académico ruso Primakov Readings.

En Genbeta

Este troyano puede tomar el control de tu PC y afecta especialmente a usuarios de Google Chrome: Microsoft lanza una alerta

Las víctimas eran incitadas a hacer clic en dichos enlaces, que redirigían a sitios maliciosos controlados por los atacantes.

Una vez abierto el enlace desde Google Chrome en un sistema Windows, el exploit se activaba automáticamente, sin requerir acciones adicionales por parte del usuario, lo que deja clara su peligrosidad.

El objetivo final era el espionaje y la obtención de información confidencial, de forma silenciosa y dirigida.

Un ataque sofisticado

Los expertos de Kaspersky han calificado la campaña como altamente técnica y profesional, lo cual apunta inequívocamente a un grupo APT con respaldo estatal. Además, la explotación de CVE-2025-2783 no se realizaba de forma aislada: estaba acompañada de un segundo exploit no identificado que permitía la ejecución remota de código.

Aunque este segundo exploit no pudo ser recuperado para su análisis, el simple hecho de combinar dos vectores de ataque sugiere una cadena de infección avanzada diseñada para evadir defensas y mantenerse oculta.

Respuesta de Google y lanzamiento de parches

El equipo de seguridad de Google lanzó de forma urgente la versión 134.0.6998.177/.178 de Chrome para Windows, corrigiendo el fallo de seguridad. La actualización está disponible tanto para usuarios con actualizaciones automáticas como para aquellos que deben hacerlo manualmente.

Además, se ha recomendado que otros navegadores basados en Chromium, como Microsoft Edge, Opera, Brave y Vivaldi, apliquen parches en cuanto estén disponibles.

Vía | Kaspersky

Imagen | Marcos Merino mediante IA

En Genbeta | Qué fue de los programadores que hace dos años trabajaron gratis para evitar pérdidas millonarias a grandes tecnológicas