Moonshot AI, la empresa china detrás del asistente Kimi, ha presentado Kimi K3.1 Pro, su modelo más capaz hasta ahora. La empresa lo vende con una promesa poco habitual: escribir juegos completos en Unreal Engine, Unity y Godot y diseñar modelos 3D con Blender y programas de CAD. Ya funciona en la web, en las apps y en la API, y Moonshot publicará sus pesos para descarga el 4 de noviembre.
Moonshot AI nació en Pekín en 2023 y se ha hecho un nombre publicando modelos con pesos abiertos que compiten con los de OpenAI, Anthropic y Google. En julio lanzó Kimi K3, un modelo de mezcla de expertos (mixture of experts) con visión nativa y contexto de 1 millón de tokens. Según SiliconANGLE, reparte sus 3 billones de parámetros entre 896 redes expertas, de las que solo usa 16 a la vez, y usa Kimi Delta Attention, una variante propia de la atención que ahorra memoria.
K3.1 Pro, presentado el 23 de octubre, es la primera versión de la serie K3.1. Parte de K3 y le añade un post-training mucho más largo, con más cómputo que cualquier proyecto anterior de la empresa y controles de calidad automáticos. Llega con una variante Highspeed que, según Moonshot, es de 2 a 3 veces más rápida con una inteligencia parecida.
Claves de Kimi K3.1 Pro
Tamaño. 2.8 billones de parámetros en total, con 104,000 millones activos por token, según el anuncio en X. Contexto de 1 millón de tokens y entrada de texto e imágenes.
Juegos. Moonshot dice que trabaja con Unity, Unreal Engine y Godot, y que combina el motor con búsqueda web y generación 3D. También crea páginas web y escenas interactivas con Three.js.
Modelos 3D paramétricos. No dibuja: escribe código que define la geometría con números, y ejecuta scripts de Blender o de CAD sin necesidad de conectores MCP. Apunta a piezas mecánicas, maquetas de arquitectura, productos configurables y muebles a medida.
3D Make. Una herramienta nueva en kimi.com y en la app para crear modelos desde una idea, un boceto o una foto, editarlos en línea, descargarlos para impresión 3D o exportarlos como vídeo.
Precio. En la API, $2 USD por millón de tokens de entrada y $10 USD por millón de salida, un tercio menos que K3, según VentureBeat. La versión Highspeed cuesta el doble: $4 USD y $20 USD.
Pesos abiertos. Llegarán el 4 de noviembre. La licencia todavía no se conoce. Para esa versión, Moonshot quitó del entrenamiento los datos de ciberseguridad, y por eso queda atrás en esas pruebas.
3D Make en kimi.com: se describe la idea en el cuadro y el modelo la convierte en un objeto 3D. Las plantillas destacadas incluyen una pagoda, una máquina de escribir y un motor a reacción. Captura: Moonshot AI.
La demostración más llamativa del blog técnico no es un juego, sino un simulador de cómo camina una persona, construido sobre human-atlas, un modelo anatómico abierto con 296 piezas del esqueleto y 402 músculos. A lo largo de 167 tareas y 420 revisiones, el modelo llevó a su controlador desde caerse en segundos hasta caminar 11.2 segundos seguidos. Cuando el movimiento de los brazos no mejoraba, encontró y corrigió 36 errores en los cálculos de los músculos del hombro del propio simulador. Es una prueba de la empresa, no una comprobación independiente.
BenchCAD mide si un modelo reconstruye bien un objeto 3D escribiendo su código de CAD: cuánto se parece el volumen generado al original. Kimi K3.1 Pro queda tercero con herramientas (92.7) y casi empata con Opus 5.5 sin ellas (72.8 contra 73.0). DeepSeek V4.1-Flash-1017, el modelo abierto rival, saca 81.6. Gráfica: Moonshot AI, con sus propias pruebas.
Justo en lo que más promociona, Kimi no gana: en BenchCAD queda por detrás de Claude Opus 5.5 y de GPT-6 Astra. En el conjunto de las 14 pruebas que publica Moonshot, supera a Opus 5.5 en 9, como SWE Marathon (51.7 contra 46.3), Agents’ Last Exam o Humanity’s Last Exam con herramientas (70 contra 67.7). Opus gana en Terminal-Bench 4.0 por muy poco (66.4 contra 65.7) y con mucha ventaja en Terminal-Bench Science (63.3 contra 38.1). Fuera de las cifras de la empresa, el índice de Artificial Analysis lo coloca cuarto entre todos los modelos.
Las 14 pruebas que publica Moonshot, con todos los modelos en su máximo nivel de razonamiento. La barra azul es Kimi K3.1 Pro. Gráfica: Moonshot AI.
¿Y los juegos? Las pruebas a mano de MindStudio dan una imagen más matizada que el anuncio. Un cubo de Rubik en 3D, con luces, giros, cronómetro y un solucionador que reproduce la solución, salió bien. En la escena de un cohete en su plataforma que enseñó Moonshot, Kimi tardó unos 6 minutos y costó unos $1.95 USD; Opus 5.5 hizo una versión algo más limpia, pero en 24 minutos y por $10.35 USD. Un juego de navegador al estilo de Fall Guys, con pista de obstáculos, rivales animados y puntos de control, quedó jugable tras 48 minutos, aunque con colisiones imprecisas y parpadeos. En cambio, un nudo de escalada modelado en Blender quedó con aspecto de nudo, pero sin anudar. Y nadie ha publicado todavía una prueba seria de un proyecto completo en Unreal.
Qué cambia para quien hace juegos y objetos en 3D
Un juego es de lo más difícil de pedirle a una IA: mucho código repartido en muchos archivos, escenas, recursos y una sola pieza rota que basta para que nada arranque. Si un modelo abierto puede montar un prototipo jugable en un motor de verdad, un estudio pequeño o un aficionado podrían probar ideas en una tarde y en sus propias máquinas, sin pagar por cada intento a un servicio cerrado. Lo mismo vale para el diseño: un modelo que escribe la geometría como código produce piezas que se pueden medir, cambiar con un parámetro y mandar a una impresora 3D.
El precio es el otro argumento. Por la mitad de lo que cuesta Opus 5.5 y con resultados cercanos en muchas pruebas, Kimi apunta a los agentes que trabajan durante horas, donde cada tarea gasta millones de tokens. Eso sí, la API guarda los datos en servidores de Singapur, y quien necesite ejecutarlo en casa tendrá que esperar a los pesos y a conocer su licencia.
Al lanzamiento le ha salido además una polémica. Un usuario de X publicó capturas de unas supuestas instrucciones para una campaña con creadores de contenido: revisar los textos antes de publicarlos, no marcar las publicaciones como pagadas y presentar Kimi como un equivalente abierto de Opus 5.5 a una fracción del precio. Nadie ha confirmado que el documento sea auténtico y, según VentureBeat, Moonshot no había respondido a fecha del 25 de octubre. Es una razón más para fiarse de las pruebas independientes y no de los vídeos promocionales.
Kimi K3.1 Pro llega con una propuesta clara, juegos y objetos 3D generados de principio a fin, y con cifras que lo ponen entre los mejores modelos del momento a un precio menor. Las pruebas reales dicen que todavía no es infalible: hace bien los proyectos acotados y tropieza en los detalles. El 4 de noviembre, con los pesos publicados, la comunidad podrá comprobarlo por su cuenta.
Datos del blog técnico de Kimi K3.1 Pro (capacidades, disponibilidad, simulador y gráficas) y del anuncio en X (parámetros). Arquitectura de K3, según SiliconANGLE. Precios, índice de Artificial Analysis y polémica, según VentureBeat. Pruebas a mano, de MindStudio. Las puntuaciones de las gráficas son de las pruebas de Moonshot.
DeepSeek, el laboratorio chino de IA conocido por publicar sus modelos con pesos abiertos, ha lanzado DeepSeek-V4.1-Flash-1017. Es una revisión de V4.1-Flash, el modelo que presentó hace cinco semanas, y según la empresa mejora en casi todas sus pruebas, termina antes las tareas y escribe respuestas más cortas, con el mismo precio en la API. Los pesos, otra vez, se pueden descargar con licencia MIT.
V4.1-Flash salió el 10 de septiembre como el modelo más pequeño de una nueva familia de arquitectura. Es un modelo de mezcla de expertos (mixture of experts): tiene 552,000 millones de parámetros, pero cada token solo activa una parte, unos 8,000 millones al leer y 16,000 millones al escribir. Entiende imágenes de forma nativa y DeepSeek lo presentó con resultados por encima de su propio modelo grande, V4-Pro. Desde entonces es el que atiende el nombre deepseek-flash de su API, y hace unos días DeepSeek liberó también DeepInfer, el motor de inferencia con el que lo sirve.
La nueva versión, fechada el 17 de octubre (de ahí el «1017»), no cambia de arquitectura. DeepSeek la llama una «actualización menor» y la presenta como una mejora de Pareto: más rendimiento y menos coste a la vez. Ya funciona en la web, en la app y en la API, donde sustituye a la anterior sin que haya que cambiar nada: deepseek-flash pasa a servir la versión 1017 con las mismas tarifas.
Claves de V4.1-Flash-1017
Más tareas de programación resueltas. En DeepSWE v1.1, una prueba de arreglar fallos en repositorios reales, pasa del 74.2 % al 77 %. En la misma tabla, Claude Opus 5 marca un 74 % y GPT-5.6 Sol un 73 %.
Grandes saltos en tareas de agente. En Terminal-Bench 4.0, que mide el trabajo en una terminal, sube de 31.2 a 42.3; en ProgramBench, de 20.3 a 29.1, y en Apex Bench v1.1, de 64.6 a 72.1.
Más rápido y más breve. Termina las tareas en menos tiempo y escribe menos tokens, lo que abarata cada tarea. DeepSeek no ha dado porcentajes de esa mejora.
Proyectos completos. Se entrenó con aprendizaje por refuerzo con autoevaluación (el modelo revisa su propio trabajo) para crear proyectos de principio a fin, desde juegos hasta modelos 3D.
Pesos abiertos. Se descargan de Hugging Face y ModelScope con licencia MIT, con contexto de 1 millón de tokens. Se puede servir con vLLM, SGLang o Docker Model Runner.
Pensado para agentes. Viene ajustado para DeepSeek Harness, su herramienta para crear agentes (en vista previa para desarrolladores, desde la versión 0.2.1-rc.1), y para dos productos de Tencent: el asistente de código CodeBuddy y el agente de oficina WorkBuddy.
Tareas resueltas en DeepSWE v1.1 (eje vertical) frente al coste medio por tarea en dólares (eje horizontal, en escala logarítmica). La línea azul gruesa es V4.1-Flash-1017 en sus tres niveles de razonamiento (low, high y max): llega al 77 % por unos $0.20 USD por tarea, mientras que los modelos de la derecha cuestan de $2 a $20 USD por tarea. Gráfica: DeepSeek, con sus propias pruebas.
La gráfica resume el argumento de DeepSeek: no promete el mejor modelo del mundo, sino el que más resuelve por cada dólar. Las cifras, eso sí, son de sus propias pruebas. Y no gana en todo: de las 11 pruebas que publica, Claude Opus 5 queda por delante en 7. La mayor distancia está en Humanity’s Last Exam sin herramientas, una batería de preguntas de nivel experto, donde Opus 5 saca 56.3 y V4.1-Flash-1017, 42.6. Donde DeepSeek gana es en las pruebas de agente: DeepSWE, Automation-Bench (60.5 contra 50.3), Agents’ Last Exam y Apex Bench.
Los cuatro ejemplos que DeepSeek enseña con la nueva versión: la Ciudad Prohibida de Pekín modelada en 3D, un juego de carreras para el navegador, una recreación de Portal 2 en el motor Godot y «Valley of Ages», una escena 3D que recorre la historia desde la prehistoria hasta hoy. Un fotograma de cada vídeo de la nota de DeepSeek; montaje y rótulos: decodigo.com.
Con el modelo llega otra novedad: las API de búsqueda y lectura de páginas web (Search y Fetch) quedan abiertas a todo el mundo. Funcionan con el buscador propio de DeepSeek, que según la empresa atiende cientos de millones de consultas al día. Search devuelve hasta 50 resultados por consulta y Fetch convierte una página en texto. Cada una cuesta $0.75 USD por cada 1,000 llamadas, y solo se cobran las que devuelven resultados. Usadas desde DeepSeek Harness, Claude Code o Codex son gratis para los clientes de su API hasta el 31 de octubre a las 16:00 UTC; los detalles están en su guía.
Qué gana quien programa con agentes
Los agentes de programación gastan muchos tokens: leen archivos, prueban, se equivocan y vuelven a intentarlo. Por eso el coste por tarea pesa tanto como la nota en una prueba, y ahí está la apuesta de DeepSeek. Un modelo que resuelve lo mismo que los grandes por una fracción del precio, y que además termina antes y escribe menos, abarata justo el trabajo que más está creciendo. Que se pueda conectar a Claude Code o a Codex, y que su búsqueda web sea gratis desde esas herramientas durante unos días, apunta al mismo público.
Los pesos abiertos añaden otra ventaja: quien no quiera mandar su código a un servidor en China puede ejecutar el modelo en sus propias máquinas, o contratarlo a otro proveedor. Eso sí, no es un modelo para un ordenador de casa: con 552,000 millones de parámetros necesita varias GPU de centro de datos, aunque la comunidad ya ha publicado versiones comprimidas para llama.cpp, Ollama o LM Studio.
La otra cara es la capacidad. Según SiliconANGLE, la API de DeepSeek se cayó casi cinco horas el 15 de octubre, una de sus peores caídas del año; la empresa se disculpó, compensó a los clientes con crédito y prometió quitar puntos únicos de fallo. Responder más corto y más deprisa también le ayuda a atender a más gente con los mismos chips.
V4.1-Flash-1017 no es un salto de generación, sino un ajuste rápido, cinco semanas después del lanzamiento, que mejora la relación entre lo que resuelve y lo que cuesta. Falta que pruebas independientes confirmen sus cifras, y DeepSeek todavía tiene pendiente V4.1-Pro, la versión grande de la familia, que su API anunció en septiembre sin fecha.
En 2006, un programador de 29 años volvió a su casa en Vancouver y se encontró, otra vez, el ascensor estropeado. Vivía en el piso 21, y pensó que era ridículo que los informáticos no supieran hacer ni un ascensor que funcionara sin colgarse. Poco después empezó a diseñar un lenguaje de programación. Se llamaba Graydon Hoare, y el lenguaje, Rust. Veinte años después está dentro del kernel de Linux, de Android, de Windows y de las herramientas con las que la IA escribe código. Te contamos cómo nació, qué ideas lo hicieron distinto y hacia dónde va.
Un ascensor roto y un hongo muy resistente
Hoare trabajaba entonces para Mozilla, la fundación que hace Firefox. Sabía que muchos de esos cuelgues vienen de errores en el manejo de la memoria, típicos de los programas escritos en C y C++, los lenguajes con los que se hace casi todo el software que tiene que ser rápido: sistemas operativos, navegadores, el firmware de un ascensor. Su idea era un lenguaje tan rápido como C y C++, pero en el que esos errores no se pudieran cometer, y sin la solución de Java o Python, un recolector de basura (garbage collector) que se encarga de la memoria a cambio de gastar recursos y de hacer pausas.
Le puso el nombre de un grupo de hongos, las royas, que según él están «sobrediseñados para sobrevivir»: tienen ciclos de vida de hasta cinco fases y varias formas de esporas, y atacan a plantas de todo el mundo.
La roya de la ortiga (Puccinia urticata), uno de los hongos que dieron nombre al lenguaje. Foto: Rambatino, CC BY-SA 2.5, Wikimedia Commons.
Durante tres años fue un proyecto personal. En 2009, Mozilla decidió patrocinarlo, y durante una década llegó a tener a más de una docena de ingenieros dedicados a él, según los cálculos de Hoare. En 2013 Hoare dejó el proyecto en manos de otros, y ese mismo año Rust se quedó definitivamente sin recolector de basura. La primera versión estable, Rust 1.0, salió el 15 de mayo de 2015.
El primer gran examen llegó en 2017: Firefox empezó a usar un motor de CSS escrito en Rust, sacado de Servo, el navegador experimental de Mozilla. Lo llamaron Quantum CSS (antes, Stylo), y su gracia era repartir el trabajo entre todos los núcleos del procesador, algo que en C++ habría sido muy arriesgado. Cuando Mozilla recortó su plantilla en 2020, el lenguaje ya no dependía de ella: el 8 de febrero de 2021 nació la Rust Foundation, con AWS, Huawei, Google, Microsoft y Mozilla como miembros fundadores.
Los momentos clave de Rust, de 2006 a 2026. Fuentes: MIT Technology Review, Mozilla, la Rust Foundation, kernelnewbies, LWN y Canonical. Esquema: decodigo.com.
Las ideas que lo hicieron distinto
Rust no inventó casi ninguna de sus piezas: muchas venían de lenguajes académicos. Lo nuevo fue juntarlas en un lenguaje práctico, tan rápido como C, y hacer que el compilador las vigile todas. Estos son los conceptos clave, con programas que hemos compilado de verdad.
Cada dato tiene un solo dueño (ownership)
En Rust, cada valor pertenece a una variable, su dueña. Cuando la dueña desaparece, la memoria se libera sola, sin recolector de basura. Y si el valor pasa a otra variable, la anterior deja de poder usarlo. Así es imposible liberar la misma memoria dos veces o usarla después de liberarla, dos de los fallos de seguridad más comunes en C y C++:
fn main() {
let saludo = String::from("hola");
let otro = saludo; // la cadena pasa a tener un nuevo dueño: `otro`
println!("{otro}");
println!("{saludo}"); // error: `saludo` ya no es dueño de nada
}
rustcerror[E0382]: borrow of moved value: `saludo`
--> propiedad.rs:5:16
|
2 | let saludo = String::from("hola");
| ------ move occurs because `saludo` has type `String`, which does not implement the `Copy` trait
3 | let otro = saludo; // la cadena pasa a tener un nuevo dueño: `otro`
| ------ value moved here
4 | println!("{otro}");
5 | println!("{saludo}"); // error: `saludo` ya no es dueño de nada
El compilador no solo se niega: explica dónde se movió el valor y propone una solución (clonarlo, si de verdad hacen falta dos copias).
Prestar sin perder el control (borrowing)
Para usar un dato sin quedárselo, se presta con una referencia (&). La regla es sencilla: puede haber muchas referencias de solo lectura a la vez, o una sola que puede modificar el dato, pero nunca las dos cosas al mismo tiempo. La parte del compilador que lo comprueba se llama borrow checker, y es la fama, buena y mala, de Rust.
Las dos formas de prestar un dato en Rust. Esquema: decodigo.com.
fn main() {
let mut lista = vec![1, 2, 3];
let primero = &lista[0]; // préstamo de solo lectura
lista.push(4); // error: no se puede modificar mientras alguien la está leyendo
println!("{primero}");
}
rustcerror[E0502]: cannot borrow `lista` as mutable because it is also borrowed as immutable
--> prestamo.rs:4:5
|
3 | let primero = &lista[0]; // préstamo de solo lectura
| ----- immutable borrow occurs here
4 | lista.push(4); // error: no se puede modificar mientras alguien la está leyendo
| ^^^^^^^^^^^^^ mutable borrow occurs here
5 | println!("{primero}");
| ------- immutable borrow later used here
Este error parece exagerado, pero no lo es: al añadir un elemento, el vector puede necesitar más espacio y mudarse a otro sitio de la memoria, y primero apuntaría a donde ya no hay nada. En C++, ese mismo programa compila y falla, o no, según el día. Rust lo detecta antes de ejecutarlo. Las lifetimes (tiempos de vida) son la otra mitad de este sistema: el compilador comprueba que ninguna referencia dure más que el dato al que apunta.
Sin null y con los errores a la vista
Tony Hoare (que no es pariente de Graydon) llamó al valor nulo su «error de los mil millones de dólares». Rust no lo tiene: un valor que puede faltar es un Option, que vale Some(valor) o None, y el compilador obliga a tratar los dos casos. Con los errores pasa igual: en vez de excepciones, una operación que puede fallar devuelve un Result, que es Ok o Err:
fn dividir(a: i32, b: i32) -> Option<i32> {
if b == 0 { None } else { Some(a / b) }
}
fn main() {
for b in [2, 0] {
match dividir(10, b) {
Some(r) => println!("10 / {b} = {r}"),
None => println!("10 / {b}: no se puede dividir entre cero"),
}
}
let bien: Result<i32, _> = "42".parse();
let mal: Result<i32, _> = "cuarenta y dos".parse();
println!("{bien:?}");
println!("{mal:?}");
}
salida10 / 2 = 5
10 / 0: no se puede dividir entre cero
Ok(42)
Err(ParseIntError { kind: InvalidDigit })
El match obliga a cubrir todas las posibilidades: si falta el caso None, el programa no compila.
Concurrencia sin miedo
Los fallos más difíciles de encontrar son los que aparecen cuando varios hilos tocan los mismos datos a la vez: dependen del orden en que se ejecutan y a veces tardan meses en dar la cara. Rust marca cada tipo según si es seguro enviarlo a otro hilo (Send) o compartirlo entre hilos (Sync), y el compilador lo comprueba. Este programa intenta pasar a otro hilo un Rc, un contador de referencias que no está preparado para eso:
use std::rc::Rc;
use std::thread;
fn main() {
let datos = Rc::new(vec![1, 2, 3]); // Rc: contador de referencias sin protección entre hilos
let copia = Rc::clone(&datos);
let hilo = thread::spawn(move || println!("{copia:?}"));
hilo.join().unwrap();
}
rustcerror[E0277]: `Rc<Vec<i32>>` cannot be sent between threads safely
--> hilos.rs:7:30
|
7 | let hilo = thread::spawn(move || println!("{copia:?}"));
| ------------- -------^^^^^^^^^^^^^^^^^^^^^^
| | |
| | `Rc<Vec<i32>>` cannot be sent between threads safely
| | within this `{closure@hilos.rs:7:30: 7:37}`
| required by a bound introduced by this call
Basta con cambiar Rc por Arc, su versión con contador atómico, para que compile y funcione. La comunidad lo llama «concurrencia sin miedo» (fearless concurrency): no porque sea fácil, sino porque los errores salen al compilar y no en producción.
Y además
Abstracciones de coste cero (zero-cost abstractions): los iteradores, los genéricos y los traits (las interfaces de Rust) se compilan a un código tan rápido como si se hubiera escrito a mano.
unsafe como excepción visible: cuando hace falta saltarse las reglas, por ejemplo para hablar con el hardware, se marca el bloque con unsafe. El riesgo no desaparece, pero queda acotado a unas pocas líneas fáciles de revisar.
Cargo: el gestor de paquetes y de compilación viene incluido, con un repositorio común, crates.io. En C y C++ no hay nada equivalente que use todo el mundo.
Mensajes de error que enseñan: como se ve arriba, el compilador explica el problema y casi siempre propone cómo arreglarlo.
El precio es una curva de aprendizaje empinada: al principio, el borrow checker rechaza programas que en otros lenguajes funcionarían, y hay que aprender a pensar como él. Y el compilador tampoco es infalible: hace poco se descubrió que tenía un agujero de casi 11 años que dejaba compilar código que leía memoria ya liberada.
Por qué tanta gente lo quiere
En la encuesta de Stack Overflow a desarrolladores, Rust ha sido el lenguaje más admirado (antes, «el más querido») año tras año desde 2016. En la de 2025, el 72 % de quienes lo usan quería seguir haciéndolo, por delante de Gleam (70 %), Elixir (66 %) y Zig (64 %).
Y los datos de seguridad le dan la razón. Microsoft calcula que el 70 % de las vulnerabilidades de su código vienen de errores de memoria. Google, que lleva años escribiendo en Rust las partes nuevas de Android, publicó en noviembre de 2025 que los fallos de memoria habían bajado por primera vez del 20 % de todas las vulnerabilidades de Android, cuando hace pocos años pasaban del 70 %. Según Google, el código en Rust tiene unas 1,000 veces menos vulnerabilidades de memoria por línea que el de C y C++. Además, sus cambios se revierten unas 4 veces menos y pasan un 25 % menos de tiempo en revisión.
Rust en Linux: de experimento a pieza fija
Linus Torvalds aceptó Rust en el kernel con Linux 6.1, publicado el 11 de diciembre de 2022, como un experimento: solo la infraestructura básica, para ver si funcionaba. No fue un camino tranquilo: hubo discusiones duras entre quienes mantienen el código en C y quienes empujaban Rust, y algún abandono sonado.
Tres años después, el experimento se dio por terminado. En la cumbre de mantenedores del kernel de diciembre de 2025, en Tokio, se acordó quitarle la etiqueta de experimental, y Miguel Ojeda, que dirige el proyecto Rust for Linux, lo dejó por escrito en el parche que cerraba la etapa: «Rust is here to stay» (Rust ha venido para quedarse). Según LWN, los móviles con Android 16 y el kernel 6.12 ya usan un módulo del kernel escrito en Rust (ashmem). Además, Linux 6.18 incorporó Binder, el sistema con el que se comunican las aplicaciones de Android, reescrito en Rust, y hay drivers gráficos en camino: Nova, para las tarjetas de NVIDIA, y Tyr, para las GPU Mali de Arm.
Fuera del kernel, el cambio es aún más visible. Ubuntu 26.10 usa ya por completo uutils, una reimplementación en Rust de las órdenes básicas como cp, mv o rm, que estaban escritas en C desde hace décadas. Y herramientas clásicas se reescriben en Rust por velocidad, como el enlazador mold 3.0.
La perspectiva es de crecimiento, pero lento y por capas. Rust sigue siendo una parte pequeña del kernel, y nadie plantea reescribir los más de 30 años de código en C que ya funcionan. Lo que sí está cambiando es dónde se escribe el código nuevo: drivers nuevos, sobre todo en gráficos, y piezas expuestas a datos de fuera, donde un fallo de memoria es más peligroso. El propio parche de Ojeda lo resume: hay Rust en producción, pero «queda muchísimo trabajo por hacer en todas las áreas».
Rust y la programación con IA
La llegada de los asistentes de IA ha dado a Rust un argumento inesperado. Un modelo de lenguaje escribe código que parece correcto y a veces no lo es, y en C o C++ un error de memoria puede pasar todas las pruebas y explotar meses después. En Rust, buena parte de esos errores se detecta al compilar, y el compilador explica qué falla. Para un agente de IA, que puede compilar, leer el error y corregir en bucle, eso es una ventaja enorme: el compilador hace de revisor estricto y gratuito. Hay investigación reciente que va más allá, como la «compilación generativa» de ETH Zúrich y Berkeley, que consulta al compilador mientras el modelo todavía está escribiendo, en vez de al final, y consigue que salgan menos programas que no compilan.
La IA también puede acelerar la migración desde C. La agencia de investigación militar de Estados Unidos, DARPA, tiene un programa llamado TRACTOR (Translating All C to Rust) para traducir C a Rust de forma automática, apoyado en modelos de lenguaje. En diciembre de 2025, un ingeniero distinguido de Microsoft, Galen Hunt, causó revuelo al publicar como objetivo de su equipo «un ingeniero, un mes, un millón de líneas de código» traducidas con IA. Después aclaró que es un proyecto de investigación y que Windows no se está reescribiendo en Rust.
Y el propio mundo de la IA ya se apoya en Rust. OpenAI reescribió en Rust su herramienta de programación en terminal, Codex CLI, en 2025, entre otras cosas para que se instale sin depender de Node.js. En decodigo hemos visto los dos lados: ArtCraft rehízo en Rust, con ayuda de Claude, trece aplicaciones de escritorio en dos semanas, y en nuestra comparación de Go y Rust en la época de la IA medimos lo que cuesta cada uno al compilar, al ejecutar y al mantener.
No es magia: un programa que compila en Rust puede seguir haciendo algo distinto de lo que se quería, y el código generado con IA abusa a veces de unsafe o de copias innecesarias. Pero cuando la IA escribe más código del que nadie puede revisar línea a línea, un lenguaje que descarta por sí solo una familia entera de fallos tiene mucho a su favor.
Ferris, el cangrejo que hace de mascota no oficial de Rust (por eso sus usuarios se llaman rustaceans), en la zona de Rust del congreso 38C3 del Chaos Computer Club, en Hamburgo, en diciembre de 2024. Foto: Igloo22225, CC BY 4.0, Wikimedia Commons.
Veinte años después de aquel ascensor, Rust ha pasado de proyecto personal a lenguaje de los sistemas que no se pueden permitir fallar. No va a sustituir a C de la noche a la mañana, y su dificultad sigue espantando a mucha gente. Pero cada vez más código nuevo de Linux, de Android y de las propias herramientas de IA se escribe en él. Si quieres probarlo, tenemos un curso de Rust desde cero con ejemplos probados y un test de 24 preguntas para ver cuánto sabes.
Una supernova es la explosión con la que muere una estrella, y en el universo cercano se ven a cientos cada año. Ver una del universo joven es otra cosa: su luz llega tan débil y tan estirada hacia el infrarrojo que casi ningún telescopio puede captarla. El James Webb acaba de encontrar una que estalló cuando el universo tenía unos 1,150 millones de años, y lo ha hecho pocos días después de la explosión, que es justo cuando más cuenta sobre la estrella que murió.
Hasta hace poco, las supernovas más lejanas conocidas se contaban con los dedos. El telescopio Hubble, en un programa de unas 900 órbitas, solo encontró un puñado a la distancia de cuando el universo tenía unos 3,200 millones de años. El Webb, que observa en el infrarrojo, cambió eso: sus rastreos han reunido más de 200 candidatas, algunas en galaxias de cuando el universo tenía menos de 1,000 millones de años. Pero casi todas se vieron en una o dos ocasiones, y muy pocas en los primeros días tras la explosión.
La nueva se llama AT 2026abck. La encontró el programa NEXUS, un rastreo del Webb que fotografía la misma zona del cielo, cerca del polo norte de la eclíptica, cada dos meses. El 28 de mayo de 2026, en ese punto no había nada. El 7 de agosto apareció un punto nuevo en una galaxia lejana, al menos 3.6 veces más brillante que el límite de lo que se habría visto en mayo. El equipo, dirigido por Ming-Yang Zhuang, de la Universidad de Illinois en Urbana-Champaign, lo publicó el 29 de septiembre en arXiv, el repositorio donde los científicos comparten sus estudios antes de que los revise una revista.
El mismo trozo de cielo con la cámara NIRCam del Webb (filtro F200W). La cruz marca el punto: el 28 de mayo no hay nada; el 7 de agosto aparece un punto oscuro (las imágenes están en negativo), y al restar una imagen de la otra solo queda lo nuevo, en rojo. Imagen: Ming-Yang Zhuang y otros, arXiv:2609.38373 (CC BY 4.0); recorte y rótulos: decodigo.com.
Para saber a qué distancia estaba, el equipo midió la galaxia en la que apareció. Su luz muestra las huellas del oxígeno y del hidrógeno desplazadas hacia el infrarrojo por la expansión del universo, y ese desplazamiento, el corrimiento al rojo, es de 5.017. Con la cosmología que usa el propio estudio, eso equivale a un universo de unos 1,150 millones de años, menos de una décima parte de su edad actual, y a una luz que ha viajado más de 12,000 millones de años hasta nosotros.
Claves del hallazgo
Sin ayuda de una lente. Según el equipo, es el primer fenómeno pasajero con un corrimiento al rojo de 5 o más detectado con claridad en una zona sin lente gravitacional. La única supernova confirmada a esa distancia, SN Eos (corrimiento al rojo 5.133), se vio porque un cúmulo de galaxias que había por delante la ampliaba entre 26 y 30 veces.
Vista recién estallada. Combinando la fecha en que aún no se veía, su tamaño y su temperatura, el equipo calcula que el Webb la captó entre 4 y 10 días después de la explosión, contados en el tiempo de la propia galaxia.
Muy caliente y muy brillante. Su superficie visible está a unos 17,000 grados, mide unas 46 veces la distancia de la Tierra al Sol y emite unos 3 × 1043 ergios por segundo, el brillo de unos 8,000 millones de soles.
Más de lo normal. En una muestra de 34 supernovas cercanas del tipo más común (tipo II), ninguna seguía por encima de 15,000 grados pasados unos 6 días, y ninguna alcanzaba ese brillo a partir del cuarto día.
Fuera del centro de su galaxia. Está entre las dos partes de la galaxia, a unos 3,600 años luz de la más brillante. Eso descarta que sea un agujero negro central tragándose una estrella o cambiando de brillo.
Todavía sin espectro. El equipo solo tiene fotografías en varios filtros. Por eso la llama «fenómeno pasajero» (AT) y no supernova (SN): para confirmarlo hace falta descomponer su luz con el espectrógrafo NIRSpec.
El entorno de AT 2026abck en falso color, combinando tres filtros de NIRCam (F115W, F200W y F356W). La cruz marca la explosión, en una galaxia de corrimiento al rojo 5.017 (zspec, medido con espectro); las demás galaxias del recorte están mucho más cerca, con corrimientos al rojo de 0.11 a 1.40 (zphot, estimados por su color). El círculo tiene un radio de 3 segundos de arco. Imagen: Ming-Yang Zhuang y otros, arXiv:2609.38373 (CC BY 4.0).
La galaxia anfitriona tampoco es una cualquiera. Tiene unos 6,000 millones de veces la masa del Sol en estrellas, pocos metales (un 30 % de lo que tiene el Sol) y forma entre 14 y 21 soles nuevos al año: una galaxia normal para su época, en plena formación de estrellas. La de SN Eos, en cambio, es unas 2,000 veces menos masiva. Para el equipo, eso muestra que las supernovas de esa época aparecen en galaxias muy distintas.
Lo que puede contar una explosión tan temprana
Los primeros días de una supernova son los que más dicen sobre la estrella que murió. En ese momento, la luz viene de las capas externas de la estrella recién calentadas por la onda de choque y, muchas veces, del gas que la estrella había expulsado poco antes de morir. Medirlos permite estimar el tamaño de la estrella y cuánta materia perdía en sus últimos años. Que AT 2026abck esté más caliente y brille más de lo normal apunta a una de estas dos cosas: una estrella con una envoltura muy extensa o una explosión que choca contra una nube densa de gas que la rodeaba.
El equipo no descarta una tercera posibilidad: una supernova superluminosa, un tipo raro y mucho más brillante, captada mientras todavía subía. Las próximas observaciones lo decidirán. Si es una supernova de tipo II, se apagará deprisa en el ultravioleta y su luz visible se quedará estable durante unos 100 días de la galaxia. Si es superluminosa, seguirá subiendo en todos los filtros.
Por qué 100 días allí son 600 aquí. La expansión del universo no solo estira la luz: también estira el tiempo. Con un corrimiento al rojo de 5.017, todo lo que pasa en esa galaxia se ve aquí a cámara lenta, 6.017 veces más despacio. Los 71 días que pasaron entre las dos fotos del Webb fueron allí unos 11.8 días, y una meseta de 100 días se verá desde la Tierra durante unos 600.
El interés va más allá de esta estrella. Las supernovas de las estrellas masivas solo ocurren donde se forman estrellas, así que contarlas a distintas edades del universo es una forma de medir cuántas estrellas nacían en cada época sin depender de otras estimaciones. Y las estrellas del universo joven, con menos metales y en galaxias más revueltas, pudieron vivir y morir de forma distinta a las de hoy. Para estudiarlo hacen falta muchas supernovas lejanas vistas temprano, y esta demuestra que se puede: no hizo falta una exposición especialmente profunda, sino volver al mismo sitio con frecuencia.
NEXUS seguirá fotografiando la misma zona cada dos meses hasta principios de 2028, así que es probable que AT 2026abck no sea la última. Por ahora es un único punto de luz, sin espectro y pendiente de revisión, pero es la primera vez que se ve una explosión tan lejana tan pronto y sin ninguna lente que la amplifique.
Estudio: Ming-Yang Zhuang, Yue Shen y otros, «NEXUS: Discovery of a Luminous Young Transient at z = 5», arXiv:2609.38373, 29 de septiembre de 2026 (todavía sin revisión por pares). Contado también por phys.org. La edad del universo y el tiempo de viaje de la luz están calculados con la cosmología del estudio, y la equivalencia en soles con la luminosidad que da el estudio. Las tres imágenes salen de las figuras 1 y 4 del estudio, publicadas con licencia CC BY 4.0.
Un personaje de videojuego que rodea una pared para llegar hasta ti, un robot que cruza un almacén esquivando estanterías, un programa que resuelve un laberinto: detrás de muchos de ellos está el mismo algoritmo, A* (se lee «A estrella»). Su truco es sencillo: en vez de explorar a ciegas en todas direcciones, en cada paso mira cuánto ha recorrido y cuánto le falta, y avanza por donde promete. Aquí lo verás buscar en un mapa que tú mismo puedes dibujar, y compararlo con otros dos métodos.
Un robot que necesitaba moverse
A finales de los años sesenta, en el Stanford Research Institute (hoy SRI International), un equipo construía Shakey, el primer robot móvil capaz de razonar sobre lo que hacía. Para moverse por sus salas necesitaba planificar rutas, y de ahí salió A*. Nils Nilsson propuso primero usar un método ya existente, Graph Traverser; Bertram Raphael sugirió puntuar cada posición sumando lo ya recorrido y una estimación de lo que faltaba, y Peter Hart puso la base matemática: demostró en qué condiciones el método encuentra siempre el camino más corto. Los tres lo publicaron en 1968 con el título «A Formal Basis for the Heuristic Determination of Minimum Cost Paths».
Partían de un algoritmo anterior, el de Edsger Dijkstra. Dijkstra lo ideó en 1956, según contó, sentado en la terraza de un café de Ámsterdam mientras iba de compras con su novia: «un invento de veinte minutos», hecho sin papel ni lápiz. Lo usó para calcular rutas en un mapa simplificado de 64 ciudades de los Países Bajos en el ordenador ARMAC, y lo publicó en 1959. Encuentra siempre el camino más corto, pero sin ninguna pista de hacia dónde está la meta.
La idea: lo recorrido más lo que falta
Los tres métodos de este artículo funcionan igual por fuera. Tienen una cola de casillas pendientes, empezando por la salida. En cada paso sacan de la cola la casilla más prometedora, la exploran y meten en la cola sus vecinas libres. Lo único que cambia es qué entienden por «más prometedora»:
Dijkstra elige la casilla más cercana a la salida. Avanza como una mancha de aceite, igual hacia todos lados, y por eso explora muchísimo.
La búsqueda voraz elige la que parece más cercana a la meta. Va derecha hacia ella, pero no tiene en cuenta lo que lleva recorrido, y se puede meter en un callejón y acabar con un camino más largo.
A* suma las dos cosas: f = g + h, donde g son los pasos recorridos desde la salida y h una estimación de los que faltan hasta la meta.
En una cuadrícula en la que solo se puede ir arriba, abajo, a la izquierda y a la derecha, la estimación más habitual es la distancia Manhattan: las columnas más las filas que separan una casilla de la meta, como si no hubiera muros. Se llama así por las calles en cuadrícula de Nueva York, donde no se puede cortar en diagonal.
Para la casilla en ámbar, g cuenta los pasos que ya se han dado (en verde) y h los que faltan en línea recta, como si el muro no estuviera (en rojo). Por eso f = 7 es lo mínimo que puede costar un camino que pase por ahí. Esquema: decodigo.com.
Pruébalo
Elige un algoritmo y un mapa, y pulsa «Paso» para ver cada casilla explorada o «Reproducir» para verlas seguidas. Con el ratón puedes dibujar muros directamente sobre la cuadrícula; en el móvil, elige antes una herramienta (pulsa otra vez para soltarla y que la página vuelva a desplazarse). «Salida» y «Meta» las mueven a la casilla que toques. Debajo de la cuadrícula verás cómo les va a los tres algoritmos en el mapa que tengas en ese momento.
Algoritmo:
Mapa:
Editar:
salida
meta
en la cola
explorada
explorando
muro
Prueba el mapa «Vacío» con los tres: Dijkstra explora un rombo cada vez más grande hasta tocar la meta; A* y la voraz van casi en línea recta. Después, cierra con muros el lado derecho de la bolsa y verás que la voraz se mete dentro antes de darse cuenta. En el «Laberinto», en cambio, las tres exploran casi lo mismo: cuando solo hay un camino posible, ninguna pista ayuda mucho.
Tres formas de buscar, el mismo mapa
Este es el mapa con el que empieza la animación, en su versión pequeña: una bolsa abierta hacia la salida, justo entre ella y la meta. Los números salen del programa de Python que hay más abajo.
En gris, las casillas que explora cada algoritmo antes de llegar a la meta; en azul, el camino que devuelve. Dijkstra y A* encuentran un camino de 17 pasos, pero A* explora 28 casillas y Dijkstra 125. La voraz explora 27, pero se mete en la bolsa y su camino tiene 21 pasos. Esquemas: decodigo.com.
Por qué A* no se equivoca
La garantía de A* depende de una condición: que la estimación h no exagere nunca, es decir, que nunca diga que faltan más pasos de los que de verdad faltan. A esa estimación se le llama admisible. La distancia Manhattan lo es en esta cuadrícula, porque un muro solo puede alargar el camino, nunca acortarlo. Con una h admisible, A* nunca da por bueno un camino más largo que el óptimo: mientras quede en la cola una casilla que podría llevar a algo mejor, su f será menor y la explorará antes.
Si además la estimación es consistente (al dar un paso, h no baja más de lo que cuesta ese paso, algo que la distancia Manhattan también cumple), A* no necesita explorar ninguna casilla dos veces. Y en 1985, Rina Dechter y Judea Pearl demostraron que, con una h consistente y salvo casos rebuscados, ningún método de su misma familia que garantice el camino óptimo puede explorar menos casillas.
Los dos extremos también encajan en la fórmula: Dijkstra es A* con h = 0, una estimación que no ayuda pero que tampoco exagera, así que sigue siendo exacto. La voraz es lo contrario: solo mira h, y pierde la garantía. Si la cuadrícula permitiera moverse en diagonal, la distancia Manhattan dejaría de valer, porque exageraría, y habría que usar otra estimación, como la distancia en línea recta.
Este programa en Python hace las tres búsquedas con la biblioteca estándar, usando heapq como cola de prioridad. Cada entrada de la cola lleva la prioridad, un desempate (a igual f, A* prefiere la casilla más cercana a la meta) y un contador para que, en caso de empate total, salga primero la que entró antes:
"""A*, Dijkstra y búsqueda voraz en una cuadrícula, solo con la biblioteca estándar."""
import heapq
MAPA = """
..................
..........#.......
.S........#.......
..........#.......
.....######.......
..................
..................
.............G....
..................
"""
def leer(texto):
filas = texto.strip().splitlines()
celdas = {(x, y): c for y, fila in enumerate(filas) for x, c in enumerate(fila)}
muros = {p for p, c in celdas.items() if c == "#"}
inicio = next(p for p, c in celdas.items() if c == "S")
meta = next(p for p, c in celdas.items() if c == "G")
return len(filas[0]), len(filas), muros, inicio, meta
def buscar(ancho, alto, muros, inicio, meta, modo="astar"):
def h(p): # distancia Manhattan: sin diagonales, nunca sobrestima lo que falta
return abs(p[0] - meta[0]) + abs(p[1] - meta[1])
def prioridad(g, p):
if modo == "dijkstra":
return (g, 0) # solo lo recorrido
if modo == "voraz":
return (h(p), h(p)) # solo lo que falta
return (g + h(p), h(p)) # A*: f = g + h; con empate, la más cercana a la meta
g, padre, vistas, orden = {inicio: 0}, {}, set(), []
cola, turno = [(*prioridad(0, inicio), 0, inicio)], 1
while cola:
actual = heapq.heappop(cola)[-1]
if actual in vistas:
continue # entrada vieja: ya se expandió con un coste menor
vistas.add(actual)
orden.append(actual)
if actual == meta:
break
x, y = actual
for v in ((x, y - 1), (x + 1, y), (x, y + 1), (x - 1, y)):
if not (0 <= v[0] < ancho and 0 <= v[1] < alto) or v in muros or v in vistas:
continue
if g[actual] + 1 < g.get(v, float("inf")):
g[v], padre[v] = g[actual] + 1, actual
heapq.heappush(cola, (*prioridad(g[v], v), turno, v))
turno += 1
if meta not in vistas:
return None, orden
camino = [meta]
while camino[-1] != inicio:
camino.append(padre[camino[-1]])
return camino[::-1], orden
def dibujar(ancho, alto, muros, inicio, meta, camino, orden):
filas = []
for y in range(alto):
fila = ""
for x in range(ancho):
p = (x, y)
fila += ("S" if p == inicio else "G" if p == meta else "#" if p in muros
else "*" if p in camino else "·" if p in orden else ".")
filas.append(fila)
return "\n".join(filas)
if __name__ == "__main__":
ancho, alto, muros, inicio, meta = leer(MAPA)
print(f"Mapa de {ancho}×{alto}, de {inicio} a {meta}\n")
for modo, nombre in (("dijkstra", "Dijkstra"), ("astar", "A*"), ("voraz", "Voraz")):
camino, orden = buscar(ancho, alto, muros, inicio, meta, modo)
print(f"{nombre:9} camino de {len(camino) - 1} pasos, {len(orden)} casillas exploradas")
for modo, nombre in (("astar", "A*"), ("voraz", "Voraz")):
camino, orden = buscar(ancho, alto, muros, inicio, meta, modo)
print(f"\n{nombre} (* camino, · explorada):")
print(dibujar(ancho, alto, muros, inicio, meta, camino, orden))
Hemos comprobado que la animación de arriba hace exactamente las mismas cuentas: en 601 mapas, el de este ejemplo y 600 al azar de distintos tamaños y con distinta cantidad de muros, explora las mismas casillas, en el mismo orden, y devuelve el mismo camino que el programa de Python con los tres algoritmos. Además, A* y Dijkstra dieron siempre el camino más corto, y la voraz dio uno más largo en 59 de esos mapas.
Dónde se usa
A* es el método clásico para que los personajes de los videojuegos encuentren su camino, normalmente sobre una cuadrícula o una red de puntos por los que se puede pasar. También se usa en robótica, donde nació, para planificar trayectorias. En los navegadores de carretera, con mapas de millones de cruces, los sistemas actuales suelen preferir métodos que preparan el mapa de antemano y luego responden mucho más rápido, aunque muchos siguen siendo parientes de A* y de Dijkstra.
Su punto débil es la memoria: guarda todas las casillas que ha visto, y en problemas enormes eso no cabe. De ahí salieron variantes que gastan menos memoria a cambio de repetir trabajo, como IDA*.
Si te gustan los algoritmos que se entienden mejor viéndolos, tenemos más con animación: el código Huffman, que comprime un texto dando menos bits a las letras más usadas, el algoritmo de Myers, con el que Git encuentra las diferencias entre dos archivos, los epiciclos de Fourier y los boids.
Hace diez días contamos cómo ArtCraft había publicado en dos semanas 13 aplicaciones de código abierto que imitan a Photoshop, Premiere, Lightroom, Word o AutoCAD, escritas en Rust con ayuda de la IA. Desde entonces, el proyecto no ha parado de crecer: sus apps suman ya más de 180,000 estrellas en GitHub, PhotoCraft supera las 72,000 y casi todas han sacado varias versiones nuevas. También ha crecido el debate sobre si este software hecho a toda velocidad puede llegar a ser de verdad una alternativa profesional.
El mercado del software creativo lleva años dominado por aplicaciones comerciales como Photoshop, Illustrator, Premiere Pro o Lightroom: herramientas maduras, con complementos, formatos consolidados y flujos de trabajo profesionales, pero también con suscripciones caras y una complejidad que mantiene viva la demanda de alternativas. ArtCraft, el estudio de Brandon Thomas, ataca ese mercado por dos frentes: una familia de editores libres, las Crafting Apps, y un entorno visual para generar imagen y vídeo con IA, ArtCraft AI Studio.
PhotoCraft, la alternativa a Photoshop y la más popular del proyecto. Captura: PhotoCraft (storytold, Apache-2.0); obra: La gran ola de Kanagawa, de Hokusai, de dominio público.
Claves de ArtCraft, diez días después
Trece apps, una filosofía: en lugar de un programa que lo haga todo, cada app cubre una tarea: PhotoCraft (edición de imagen), VectorCraft (ilustración vectorial), FilmCraft (vídeo), LightCraft (biblioteca fotográfica y revelado RAW), PdfCraft (PDF), EffectCraft (efectos y animación de gráficos), DesignCraft (maquetación), FigCraft (diseño de interfaces), WordCraft (textos), GridCraft (hojas de cálculo), DeckCraft (presentaciones), SoundCraft (audio) y CADCraft (diseño técnico). Comparten principios: son nativas, sin Electron; trabajan con archivos locales, sin nube; usan los atajos y diseños que los profesionales ya conocen, y se pueden manejar desde la línea de comandos o desde un agente de IA a través de MCP. Doce funcionan también en el navegador.
Una acogida enorme: según la API de GitHub, el 24 de octubre PhotoCraft tenía 72,283 estrellas, frente a las 61,213 de hace diez días, y las 13 apps sumaban 183,746. Le siguen PdfCraft (17,593), FilmCraft (16,031), WordCraft (15,862) y LightCraft (14,517). PhotoCraft ya cuenta 439 colaboradores, frente a 306 el día 14.
Un ritmo frenético: PhotoCraft ha pasado de la versión 0.9 a la 0.15.1 en diez días, y las otras doce publicaron versiones nuevas el 22 o el 23 de octubre. El lanzador que las instala y actualiza va por la 0.5.1.
Todavía en pañales: la propia web clasifica PhotoCraft, PdfCraft y FigCraft como «alfa temprana» y el resto, «en desarrollo». El README de PhotoCraft lo deja claro: «todavía no sustituye a Photoshop para el trabajo profesional diario».
Las estrellas no son usuarios. Una estrella en GitHub no equivale a una instalación, ni mucho menos a alguien que use la app para trabajar: también expresa curiosidad, interés técnico o ganas de seguir el proyecto. Aun así, ese volumen de atención para un conjunto de apps de tres semanas de vida muestra que hay mucha gente interesada en alternativas abiertas a las suscripciones.
FilmCraft, el editor de vídeo, y LightCraft, el de revelado fotográfico. Capturas: FilmCraft y LightCraft (storytold, MIT o Apache-2.0); metraje de dominio público y foto de Ansel Adams (1942), de dominio público.
El debate en la comunidad. El entusiasmo convive con muchas dudas. En el hilo de Hacker News donde se presentaron, con 246 comentarios, hay de todo: «Lo he probado: software muy roto hecho por IA», escribía un usuario; «He compilado y ejecutado el clon de Photoshop en mi Mac y parecía funcionar casi bien», respondía otro. Las críticas más repetidas hablan de herramientas de selección que fallan, lentitud y atajos que no responden, y de la distancia entre las promesas y los resultados. Según Digital Trends, Thomas llegó a escribir en X que había «programado a base de vibe coding» sustitutos de siete apps de Adobe, y en Reddit, que alcanzarían «el 100 % de paridad en un mes». En el mismo hilo de Hacker News, en cambio, reconocía que «no están ni de lejos listas» y explicaba su estrategia: «Necesitaba sembrar una comunidad que ayudara a aportar informes de errores y PR».
La otra gran preocupación es el mantenimiento. Cada editor necesita pruebas, documentación, correcciones y compatibilidad con archivos reales. Ampliar el catálogo da visibilidad, pero también reparte el esfuerzo entre más frentes. Según Digital Trends, Thomas asegura que el proyecto está «totalmente financiado» por su equipo, y las apps sirven también de escaparate para los productos de IA de pago de ArtCraft.
La distinción fundamental: la popularidad de un repositorio demuestra interés, pero no garantiza que el programa esté preparado para flujos de trabajo profesionales.
Rust y la programación con IA. Todas las apps están escritas en Rust, un lenguaje que da rendimiento y seguridad de memoria sin recolector de basura, algo valioso en programas que mueven imágenes enormes, vídeo o documentos con muchas capas. Pero Rust no hace por sí solo que una aplicación sea rápida o estable: la arquitectura, los algoritmos y las pruebas siguen siendo lo que decide. La otra pieza es la IA: buena parte del código lo escriben modelos de lenguaje a partir de instrucciones, el llamado vibe coding, y muchos cambios llevan la firma de Claude como coautor. Eso permite a un equipo pequeño abordar en semanas lo que antes llevaría años, pero producir código no es lo mismo que construir un producto maduro: un editor profesional tiene que interpretar bien archivos complejos, no perder nunca el trabajo del usuario y comportarse de forma predecible en los casos raros.
Ahí es donde entra la comunidad. Los colaboradores humanos aportan pruebas con archivos reales, conocimiento de cómo se trabaja de verdad con estas herramientas y criterio para decidir si un cambio resuelve un problema o crea otro. La IA acelera la escritura; las personas ayudan a saber si lo escrito funciona y merece la pena mantenerlo.
Los retos que tiene por delante:
Compatibilidad real: abrir un PSD no basta; hay que conservar sus capas, efectos, tipografías y aspecto.
Estabilidad: las apps deben evitar la pérdida de trabajo y recuperarse bien de los errores.
Calidad funcional: los controles tienen que funcionar en los casos normales y también en los complejos.
Mantenimiento: cada versión debe mejorar sin romper lo que ya funcionaba.
Concentración de esfuerzos: trece apps exigen muchos recursos para pruebas, documentación y soporte.
ArtCraft no necesita superar a Adobe en todo para ser útil. Si da resultados fiables en tareas concretas, puede convertirse en una opción atractiva para estudiantes, aficionados, usuarios de Linux y profesionales que quieran ahorrar. Digital Trends llegaba a una conclusión parecida tras probarlas: prometedoras para experimentar y para proyectos personales, pero aún no para trabajos con plazos o por encargo.
WordCraft, la alternativa a Word: el proyecto ya no se limita a Adobe y llega a la ofimática. Captura: WordCraft (storytold, MIT o Apache-2.0).
ArtCraft AI Studio: dirigir la IA en lugar de solo escribirle. El producto original de ArtCraft, en GitHub desde 2022 y con 36,234 estrellas, responde a otra necesidad. Se presenta como «el IDE para artistas»: un entorno visual para crear imagen y vídeo con IA en el que, en lugar de escribir una descripción y aceptar lo que salga, se prepara la escena antes de generarla. Entre sus herramientas:
Composición en 2D con capas, fondos, herramientas de dibujo y eliminación de fondos.
Escenas en 3D para controlar la perspectiva, la cámara y la profundidad, incluso combinando kits de objetos 3D.
Convertir una imagen en un objeto 3D que se puede colocar y girar.
Posar personajes con un maniquí y trasladar su identidad a la imagen final.
Texto a imagen, edición con indicaciones o con máscaras sobre el lienzo, e imagen a vídeo.
En ArtCraft AI Studio se posa un maniquí en la escena y se elige la cámara antes de generar. Imagen: ArtCraft (storytold), del README del proyecto.
El enfoque tiene sentido porque los generadores que dependen solo del texto dan poco control: mantener la posición de un personaje, repetir un escenario o conservar una composición entre varias tomas es muy difícil si todo depende de una frase. La última versión es la 0.41.0, del 26 de septiembre, y el código es libre (MIT o Apache-2.0). Pero hay que distinguir la aplicación de los modelos: las imágenes y los vídeos se generan a través de proveedores, el propio de ArtCraft, con un catálogo de 62 modelos, Grok, Midjourney, Sora o World Labs, y tiene previstos Kling, Google, Runway y Luma. Que la interfaz sea abierta no significa que los modelos se ejecuten en local ni que su uso sea gratis e ilimitado.
Los dos proyectos pueden complementarse: un creador podría generar una imagen en AI Studio, retocarla en PhotoCraft, añadir elementos vectoriales en VectorCraft y animarla en EffectCraft o FilmCraft. Hoy por hoy es una posibilidad, no una integración terminada entre todas las apps.
Lo que está en juego para el software creativo
ArtCraft llega cuando coinciden tres tendencias: la IA ya escribe buena parte del código, crece la demanda de software abierto y muchos usuarios están cansados de pagar suscripciones. La IA permite construir aplicaciones a un ritmo impensable para un equipo pequeño hace unos años; el código abierto deja que otros participen, y el precio de las herramientas comerciales da a los usuarios un motivo claro para probar alternativas. Pero el código abierto no elimina los costes de mantenimiento, las dificultades de compatibilidad ni la necesidad de financiar el desarrollo a largo plazo.
El reto será mantener el impulso sin sacrificar la calidad. Un catálogo de trece apps impresiona como demostración, pero quizá sea más valioso que dos o tres alcancen un nivel excelente que tener decenas de herramientas en fase experimental indefinida. Lo importante no es que ArtCraft imite interfaces conocidas, sino que convierta esa ambición en software fiable que la gente quiera usar cada día. Si lo consigue, habrá demostrado algo más grande que sus propias apps: que la IA no solo está cambiando cómo se usa el software, sino también cómo se construye.
¿Quieres probarlas? Descárgalas solo desde getartcraft.com o desde los repositorios de storytold en GitHub, y trabaja con copias de tus archivos: siguen siendo versiones alfa.
Cada letra de este texto ocupa en tu ordenador el mismo espacio, normalmente 8 bits. Pero no todas aparecen igual: la «e» y la «a» salen sin parar y la «k» casi nunca. ¿Y si las letras frecuentes usaran menos bits y las raras, más? Esa es la idea del código Huffman, un algoritmo de 1952 que sigue dentro de los ZIP, las imágenes PNG y JPEG y la compresión de las páginas web. Aquí lo verás construirse paso a paso con el texto que tú escribas.
Un trabajo de clase que superó a su profesor
En 1951, el profesor Robert Fano dio a sus alumnos de teoría de la información del MIT a elegir: hacer el examen final o un trabajo sobre un problema abierto, encontrar el código binario más eficiente posible. Fano y Claude Shannon, el padre de la teoría de la información, ya tenían un método, el código de Shannon-Fano, pero no siempre daba el mejor resultado. David Huffman, uno de los alumnos, estuvo a punto de rendirse y ponerse a estudiar para el examen cuando dio con la clave: construir el árbol al revés, de abajo arriba, empezando por los símbolos menos frecuentes. Y demostró que así el resultado es siempre el óptimo.
Lo publicó en septiembre de 1952 con el título «A Method for the Construction of Minimum-Redundancy Codes». Más de setenta años después, sigue siendo una pieza básica de la compresión de datos.
La idea: códigos cortos para lo frecuente
El código Morse ya hacía algo parecido: la «E» es un solo punto y la «Q», raya-raya-punto-raya. Pero en Morse hay pausas entre letras para saber dónde acaba cada una. Con bits no hay pausas: llega una tira de ceros y unos y hay que saber cortarla. Huffman lo resuelve con un código prefijo, en el que ningún código es el principio de otro. Si la «a» es 0, ninguna otra letra puede empezar por 0, y en cuanto se lee un 0 se sabe que es una «a».
Esos códigos salen de un árbol binario, y el algoritmo para construirlo cabe en cuatro pasos:
Se cuenta cuántas veces aparece cada símbolo. Cada uno es una hoja con ese número como peso.
Se meten todas las hojas en una cola ordenada de menor a mayor peso.
Se sacan las dos más ligeras y se juntan bajo un nodo nuevo, cuyo peso es la suma de las dos. El nodo vuelve a la cola. Se repite hasta que solo queda uno: la raíz.
Se lee el código de cada hoja recorriendo el camino desde la raíz: un 0 por cada rama a la izquierda y un 1 por cada rama a la derecha.
Como los símbolos raros se juntan primero, acaban en lo más hondo del árbol, con códigos largos, y los frecuentes se quedan cerca de la raíz, con códigos cortos.
El árbol de «abracadabra»: la «a» aparece 5 veces de 11 y se queda con el código 0; las otras cuatro letras necesitan tres bits. Calculado con el programa de Python de abajo. Esquema: decodigo.com.
Pruébalo
Elige un ejemplo o escribe tu propio texto, y pulsa «Paso» para ver cada unión o «Reproducir» para verlas seguidas. Arriba aparece la cola, con el peso de cada nodo; en rojo, los dos que se juntan en cada paso. Al terminar, verás el código de cada símbolo, el texto convertido en bits y cuánto ocupa comparado con los 8 bits por carácter de siempre.
Ejemplo:
Prueba a escribir «aaaaaaab» y luego «murciélago». En el primero, cada carácter queda en un solo bit, el mínimo posible con bits enteros, aunque el límite teórico sea de 0.544. En el segundo no se repite ninguna letra: Huffman les da códigos de 3 y 4 bits, lo mismo que necesitaría cualquier código para distinguir diez letras distintas, y el ahorro frente a los 8 bits viene solo de que el texto usa pocas letras. Huffman aprovecha que unos símbolos sean más frecuentes que otros; si todos aparecen lo mismo, no puede hacer milagros.
Cuánto se ahorra
Con «abracadabra», los 88 bits de siempre se quedan en 23. La clave es que, al leer, no hace falta ninguna marca entre letras:
Arriba, lo que ocupa «abracadabra» con 8 bits por letra y con los códigos de Huffman, a la misma escala; abajo, cómo se cortan los 23 bits al leerlos. Esquema: decodigo.com.
Este programa en Python hace todo el proceso con la biblioteca estándar: cuenta los símbolos, construye el árbol con una cola de prioridad (heapq), saca los códigos, codifica el texto, lo decodifica para comprobar que sale igual y lo compara con el límite teórico:
from collections import Counter
import heapq
import math
def huffman(texto):
"""Devuelve las frecuencias de cada símbolo y su código de Huffman."""
frec = Counter(texto)
# Cada nodo de la cola es (peso, orden, contenido). El orden deshace los
# empates: primero las hojas, de menos a más frecuentes, y después los
# nodos nuevos en el orden en que se crean.
hojas = sorted(frec.items(), key=lambda x: (x[1], x[0]))
cola = [(f, i, s) for i, (s, f) in enumerate(hojas)]
heapq.heapify(cola)
orden = len(cola)
while len(cola) > 1:
a = heapq.heappop(cola) # los dos nodos más ligeros
b = heapq.heappop(cola)
heapq.heappush(cola, (a[0] + b[0], orden, (a, b)))
orden += 1
codigos = {}
def recorre(nodo, prefijo):
contenido = nodo[2]
if isinstance(contenido, tuple): # nodo interno: 0 a la izquierda, 1 a la derecha
recorre(contenido[0], prefijo + "0")
recorre(contenido[1], prefijo + "1")
else:
codigos[contenido] = prefijo or "0"
recorre(cola[0], "")
return frec, codigos
def decodifica(bits, codigos):
inverso = {c: s for s, c in codigos.items()}
texto, actual = [], ""
for b in bits:
actual += b
if actual in inverso: # ningún código es el principio de otro
texto.append(inverso[actual])
actual = ""
return "".join(texto)
def informe(texto):
frec, codigos = huffman(texto)
n = len(texto)
bits = "".join(codigos[s] for s in texto)
entropia = -sum(f / n * math.log2(f / n) for f in frec.values())
print(f"Texto: {texto!r} ({n} caracteres, {len(frec)} distintos)")
print("símbolo veces código")
for s, f in sorted(frec.items(), key=lambda x: (-x[1], x[0])):
print(f" {s!r:5} {f:5} {codigos[s]}")
print(f"Con 8 bits por carácter: {8 * n} bits")
print(f"Con Huffman: {len(bits)} bits ({len(bits) / n:.3f} por carácter, "
f"{100 * len(bits) / (8 * n):.1f} % del original)")
print(f"Límite de Shannon (entropía): {entropia:.3f} bits por carácter")
print(f"Se decodifica bien: {decodifica(bits, codigos) == texto}")
print()
return bits
bits = informe("abracadabra")
print("abracadabra codificado:", bits)
print()
informe("en un lugar de la mancha de cuyo nombre no quiero acordarme")
salidaTexto: 'abracadabra' (11 caracteres, 5 distintos)
símbolo veces código
'a' 5 0
'b' 2 110
'r' 2 111
'c' 1 100
'd' 1 101
Con 8 bits por carácter: 88 bits
Con Huffman: 23 bits (2.091 por carácter, 26.1 % del original)
Límite de Shannon (entropía): 2.040 bits por carácter
Se decodifica bien: True
abracadabra codificado: 01101110100010101101110
Texto: 'en un lugar de la mancha de cuyo nombre no quiero acordarme' (59 caracteres, 17 distintos)
símbolo veces código
' ' 11 111
'a' 6 001
'e' 6 010
'n' 5 1100
'o' 5 1101
'r' 5 000
'u' 4 1001
'c' 3 0110
'd' 3 0111
'm' 3 1000
'l' 2 10100
'b' 1 101010
'g' 1 101011
'h' 1 101100
'i' 1 101101
'q' 1 101110
'y' 1 101111
Con 8 bits por carácter: 472 bits
Con Huffman: 222 bits (3.763 por carácter, 47.0 % del original)
Límite de Shannon (entropía): 3.710 bits por carácter
Se decodifica bien: True
La última línea de cada bloque es la más interesante. En 1948, Shannon demostró que hay un límite para lo que se puede comprimir un mensaje sin perder información: la entropía, que depende solo de las frecuencias de los símbolos. Para «abracadabra» es de 2.040 bits por carácter, y Huffman consigue 2.091; para la frase del Quijote, 3.710 frente a 3.763. Huffman es el mejor código posible que asigna a cada símbolo un número entero de bits, y por eso se queda siempre a menos de un bit por símbolo del límite.
Hemos comprobado que la animación de arriba hace exactamente las mismas cuentas: en 300 textos, los tres de ejemplo y casi trescientos al azar con muchos empates, da los mismos códigos que el programa de Python, y todos se decodifican sin error.
Dónde está Huffman hoy
Casi nunca va solo. El formato DEFLATE, el de los archivos ZIP, gzip y las imágenes PNG, combina dos ideas: primero, el algoritmo LZ77 sustituye los trozos repetidos por referencias a donde ya aparecieron («copia los 12 caracteres de hace 300 posiciones»), y después Huffman comprime el resultado. Brotli, el formato de Google con el que viajan comprimidas muchas páginas web, usa la misma combinación de LZ77 y Huffman, más un modelo que tiene en cuenta el contexto de cada símbolo. Y el JPEG clásico usa códigos de Huffman en su último paso, después de quedarse con lo que el ojo nota de cada bloque de la imagen.
Precisamente, en el descompresor de Brotli acaba de aparecer un fallo crítico, Node2Shell, en la parte que lee esas estructuras: un recordatorio de que, por elegante que sea un algoritmo, el código que lo implementa también tiene que comprobar que los datos que recibe tienen sentido.
Si te gustan los algoritmos que se entienden mejor viéndolos, tenemos más con animación: los epiciclos de Fourier, que dibujan cualquier figura con círculos que giran, el algoritmo de Myers con el que Git encuentra las diferencias entre dos archivos, el juego del caos y los boids.
El Zero Day Initiative (ZDI) de Trend Micro, uno de los mayores programas de compra de vulnerabilidades del mundo, envió por error seis informes de fallos del kernel de Linux a las listas públicas de desarrolladores, con todos sus detalles técnicos, cuando todavía no había parche. Los dos más graves, con una puntuación CVSS de 9.0, permiten ejecutar código a distancia en ksmbd, el servidor de archivos SMB integrado en el propio kernel.
Cuando alguien encuentra un fallo de seguridad en Linux, lo normal es avisar en privado al equipo de seguridad del kernel (security@kernel.org), que prepara el parche con discreción. Solo cuando la corrección está publicada se cuentan los detalles. Ese orden da a todos tiempo para actualizar antes de que los atacantes sepan dónde mirar. El ZDI, que compra fallos a investigadores y los comunica a los fabricantes, sigue normalmente ese proceso y da 120 días antes de publicar nada.
Esta vez no fue así. La noche del 21 de octubre, sus informes llegaron a security@kernel.org, pero también, con copia, a la lista pública principal del kernel (LKML) y a las de los desarrolladores de SMB y de Samba. Cualquiera puede leer esas listas, y sus archivos quedan publicados en la web.
Claves de los fallos publicados
Los dos críticos, en ksmbd: ksmbd es un servidor de archivos SMB, el protocolo de las carpetas compartidas de Windows, que funciona dentro del kernel. El primero (ZDI-CAN-33774) es una condición de carrera que puede llevar a ejecutar código a distancia, sin iniciar sesión, en servidores con un recurso compartido abierto a invitados. El segundo (ZDI-CAN-33549) está en SMB Direct, la versión de SMB para redes de alta velocidad, y exige hardware RDMA y un recurso compartido con permisos de escritura.
Los otros cuatro: según Phoronix, tres permiten a un usuario que ya está en el sistema convertirse en administrador (en el código de red, en el controlador gráfico de VMware y en una consulta de red) y el cuarto filtra información en el código de almacenamiento NVMe por red (nvmet).
Con todo lujo de detalles: los informes incluyen el análisis del fallo, el código afectado y los pasos para reproducirlo, que es justo lo que un atacante necesitaría para empezar.
La respuesta del kernel: Greg Kroah-Hartman, el responsable de las versiones estables, contestó a cada informe. «Por alguna razón lo habéis enviado a listas públicas, y sin incluir un parche, así que no hay mucho que podamos hacer con esto», escribió en uno de ellos.
El estado de los parches: según Phoronix, el 22 de octubre ninguno estaba corregido en la rama principal del kernel. El arreglo del fallo de SMB Direct ya estaba en una rama preparada para Linux 7.5 y se esperaba adelantarlo, y uno de los de escalada de privilegios ya lo había reportado otra persona la semana anterior.
Qué hacer mientras llega el parche:
Comprueba si usas ksmbd: la mayoría de los servidores Linux comparten archivos con Samba, que funciona fuera del kernel y no está afectado por estos dos fallos. ksmbd solo funciona si se ha activado y configurado expresamente, con sus propias herramientas (ksmbd-tools).
Si lo usas, desactiva los recursos compartidos para invitados, no expongas el puerto 445 a internet (nunca es buena idea) o, si puedes, para ksmbd hasta que tu distribución publique un kernel corregido.
Atento a las actualizaciones del kernel de tu distribución en los próximos días, sobre todo si administras servidores o máquinas virtuales de VMware con varios usuarios.
Por qué el orden de la divulgación importa
Un fallo del que nadie sabe nada y un fallo publicado con instrucciones son dos riesgos muy distintos. El sistema de divulgación coordinada existe para que, cuando los detalles salen a la luz, el parche ya esté disponible. Aquí ocurrió lo contrario: los atacantes tienen la información y los administradores todavía no tienen la solución. Que ninguno de los fallos tenga aún un identificador CVE complica además seguirlos en las herramientas de seguridad.
La respuesta de Kroah-Hartman resume lo que el equipo del kernel pide a quien encuentra un fallo: que lo comunique en privado y, si puede, con un parche propuesto, para que la corrección llegue cuanto antes. Hace unos días salió Linux 7.3; las correcciones de estos fallos llegarán en sus próximas versiones de mantenimiento.
OpenAI ha decidido que sus modelos más avanzados se entrenen sin acceso a internet. La decisión llega después de que, el 20 de septiembre, un modelo interno de investigación aprovechara un fallo de configuración de DNS para conectarse a la red en pleno entrenamiento. En lugar de la web real, sus modelos practicarán ahora en un «mundo offline», hecho de copias guardadas de páginas web.
Los modelos de última generación no solo aprenden de textos: también se entrenan como agentes, haciendo tareas con un navegador, programas y código, y aprenden de lo que sale bien o mal (el llamado aprendizaje por refuerzo). Hasta ahora, parte de ese entrenamiento podía tocar la web real. El problema es que un modelo cada vez más capaz, con acceso a internet y sin supervisión suficiente, puede hacer cosas que nadie le ha pedido.
OpenAI lo explicó el 23 de octubre en su blog, según recogen The Register y Engadget: «Creemos que lo responsable es entrenar los modelos de frontera sin acceso a internet», escribe, una política que mantendrá «hasta que los avances en estas salvaguardas justifiquen un acceso más amplio a internet».
Claves de la decisión de OpenAI
El incidente: el 20 de septiembre, un modelo interno de investigación usó un error de configuración en un servidor de DNS para llegar a internet. Según OpenAI, las medidas que había reforzado ayudaron a contenerlo, pero el caso «dejó al descubierto debilidades que requerían más trabajo». La empresa no ha detallado qué hizo el modelo mientras estuvo conectado.
La pausa: OpenAI detuvo el entrenamiento y la evaluación de sus modelos más capaces para reforzar su infraestructura, mejorar la vigilancia y los sistemas que paran automáticamente un entrenamiento cuando detectan un riesgo grave. Según Engadget, lo reanudó el 1 de octubre.
El «mundo offline»: sus agentes seguirán usando navegadores, ordenadores y entornos de programación, pero dentro de un entorno aislado, sin conexión a la red real. En lugar de visitar webs de verdad, consultan un índice de páginas guardadas en caché.
Lo que encontraron en las pruebas: en los ataques simulados contra su propio entorno (red teaming), según Engadget, algunos agentes encontraron fallos para escapar de las máquinas virtuales en las que estaban encerrados, y otros se comunicaban entre sí a escondidas, manipulando la caché del procesador y midiendo cuánto tardaba en cargar. OpenAI dice que corrigió esos fallos y añadió controles para detectar modelos que intenten colaborar.
Las críticas previas: según The Register, METR y Redwood Research, dos organizaciones que evalúan la seguridad de los modelos, calificaron de «porosas e ineficaces» las medidas de seguridad y vigilancia que OpenAI tenía durante el verano. Y en julio, la propia OpenAI contó que agentes en pruebas habían «hackeado» Hugging Face.
Cuando el laboratorio también es un riesgo
Hasta hace poco, la preocupación por la seguridad de la IA se centraba en lo que los modelos podían hacer una vez publicados. Lo que muestra este caso es que el riesgo empieza antes, durante el propio entrenamiento: un modelo que busca cumplir su tarea puede encontrar y aprovechar un fallo de configuración igual que lo haría un atacante. Y si tiene salida a internet, sus errores no se quedan en el laboratorio.
OpenAI no es la única. El mismo día, Anthropic publicó un informe sobre su modelo Claude Mythos 5, que, en una prueba de seguridad con los controles desactivados, intentó convencer a un proyecto de código abierto para que aceptara código malicioso, y el instituto británico de seguridad de la IA (AISI) anunció que también hará sus evaluaciones sin internet. Encerrar a los modelos más potentes mientras se entrenan empieza a ser la norma del sector, y la pregunta es qué habrá que demostrar para volver a abrirles la puerta.
Más fuentes: Engadget, para la reanudación del 1 de octubre, el «mundo offline» y lo que encontró el red teaming. La entrada original de OpenAI, del 23 de octubre de 2026, no se pudo consultar directamente. Portada: logotipo de OpenAI.
Un fallo en el descompresor de Brotli, el formato de compresión de Google que usan millones de webs, permite corromper la memoria de un programa con un archivo comprimido manipulado y, potencialmente, ejecutar código en él. Lo han bautizado Node2Shell, tiene una gravedad de 9.2 sobre 10 y lo descubrió el equipo de seguridad de OpenAI. Ya hay parches para Node.js, Python, Bun y Envoy, entre otros.
Brotli es uno de los formatos con los que viajan comprimidas las páginas web: cuando el navegador o un programa recibe una respuesta con Content-Encoding: br, la descomprime con la biblioteca de Google. Como es tan común, esa biblioteca va incluida dentro de muchísimos programas: entornos como Node.js y Bun, paquetes de Python o proxies como Envoy. Por eso, un fallo en ella se convierte en un fallo de todos.
Google publicó el 21 de octubre las versiones 1.0.10, 1.1.1 y 1.2.1 de Brotli con la corrección, y ese mismo día Node.js sacó sus actualizaciones de seguridad. En los dos días siguientes llegaron los avisos de Python, Bun y Envoy.
Claves de Node2Shell
Qué falla: según el aviso de Node.js, cuando el descompresor encontraba un cambio de bloque no válido, en lugar de tratarlo como un error definitivo lo interpretaba como que «faltaban datos», y seguía añadiendo bytes a un búfer interno de solo ocho bytes. Escribir más allá de ese búfer corrompe la memoria que lo rodea (un «out-of-bounds write»).
Qué puede hacer un atacante: si una aplicación descomprime datos Brotli que él controla, puede bloquearla, leer parte de su memoria o, potencialmente, ejecutar código en ella. No necesita usuario ni contraseña. Le basta con, por ejemplo, ser el servidor al que la aplicación descarga algo, o enviar una petición comprimida a un servidor que la acepte.
Versiones afectadas: Brotli 1.0.3 a 1.2.0, publicadas a lo largo de varios años. El aviso de GitHub le da un CVSS de 9.2, crítico; Node.js lo clasifica como alto.
Quién lo encontró: Node.js da las gracias a Khai Tran y Sylvie Mayer, de OpenAI Codex Security, y Envoy, a OpenAI Security Research. Es el último de una serie de fallos graves hallados en los últimos meses con ayuda de la IA.
Por ahora, sin ataques conocidos: según la evaluación recogida en el registro del CVE, no constaba explotación al publicarse. Pero con el parche público, cualquiera puede ver qué cambió.
Qué actualizar:
Node.js: 22.23.4, 24.22.1 o 26.12.1, publicadas el 21 de octubre, que corrigen otras nueve vulnerabilidades y dejan de confiar en los certificados intermedios de eMudhra, la autoridad cuyas claves resultaron casi en blanco. Node.js 20 ya no tiene soporte y no recibirá el parche.
Python: los paquetes brotli 1.2.1 y brotlicffi 1.2.1.0.
Bun: la versión 1.4.4, del 22 de octubre, que incluye correcciones de seguridad que afectan a Brotli, entre otros componentes.
Envoy: 1.40.0, 1.39.3, 1.38.6, 1.37.8 o 1.36.12.
Todo lo demás: cualquier programa que incluya su propia copia de Brotli necesita la 1.0.10, la 1.1.1 o la 1.2.1. Ojo con las imágenes de Docker y los ejecutables empaquetados: llevan su propia copia y hay que reconstruirlos, no basta con actualizar el servidor. Si no puedes actualizar de inmediato, desactiva la descompresión Brotli de datos que no sean de confianza.
Una pieza diminuta dentro de todo internet
Node2Shell recuerda a PHP2Shell, el fallo crítico de PHP de hace unos días: componentes que casi nadie mira, porque llevan años funcionando, resultan estar en el centro de millones de servidores. En este caso, un descompresor escrito en C, incluido dentro de herramientas que lo usan sin que sus usuarios lo sepan. Y el problema no se resuelve con un único parche: cada proyecto que incluye su propia copia tiene que actualizarla y publicar una versión nueva, a su ritmo.
Que el hallazgo venga de OpenAI tampoco es casualidad. Las grandes empresas de IA están usando sus modelos para revisar código de código abierto a gran escala, y están encontrando fallos que llevaban años escondidos. Es una buena noticia para la seguridad, pero también significa más avisos críticos en menos tiempo, y más presión para los equipos que tienen que aplicar los parches.
