Rusia enviará este mes a la Estación Espacial Internacional a Teledroid, un robot con forma humana pensado para trabajar afuera de la estación mientras un cosmonauta lo maneja desde dentro. Según Roscosmos, el robot sube en la nave de carga Progress MS-36, prevista para noviembre; el exoesqueleto y el equipo con los que se controlará ya están a bordo desde septiembre. Es el sucesor de FEDOR, el humanoide que pasó dos semanas en la estación en 2019 y que no volvió a volar.
Teledroid lo diseñó la empresa rusa NPO Android Technics, la misma que hizo FEDOR, y el experimento lo plantea TsNIIMash, el instituto de investigación de Roscosmos. No tiene piernas: es un torso con brazos, manos y una cabeza con cámaras, hecho para aguantar el vacío, la radiación y los cambios bruscos de temperatura del exterior. La idea, según su diseñador jefe, Evgueni Dudorov, es que prepare la zona de trabajo antes de una caminata espacial y la deje limpia después, para que los cosmonautas pasen menos tiempo fuera. El jefe de Roscosmos, Dmitri Bakanov, lo resumió así: servirá para las operaciones más riesgosas, «para no arriesgar la vida de nuestros cosmonautas».
El camino ha sido largo. FEDOR, de 182 centímetros y 106 kilos, llegó en agosto de 2019 en una nave Soyuz sin tripulación, que falló su primer intento de acoplarse y lo logró tres días después. Dentro de la estación conectó cables y manejó herramientas, y el 6 de septiembre volvió a la Tierra. Cinco días más tarde, el propio Dudorov reconoció que FEDOR no podía reemplazar a los cosmonautas en una caminata, y en 2022 contó que ellos lo consideraban inútil. Teledroid es la respuesta a esa experiencia: menos humanoide de exhibición y más herramienta para el exterior.
De FEDOR a Teledroid: lo que ya pasó y lo que falta. Gráfica: decodigo.com con datos de Roscosmos, TASS, Interfax y Lenta.
Claves de Teledroid y su experimento
Dónde está hoy. La nave de carga Progress MS-35, que despegó el 16 de septiembre desde Baikonur, llevó el puesto de trabajo y el exoesqueleto con el que se manejará el robot. El robot sube en la siguiente, la Progress MS-36, que Roscosmos sitúa en noviembre. Hasta hoy, 7 de noviembre, no ha despegado ni hay una fecha oficial: el 24 de noviembre que circula sale de calendarios no oficiales.
Cómo se maneja. El cosmonauta se pone un exoesqueleto en el torso y los brazos, que copia sus movimientos, y un casco de realidad virtual que le muestra lo que ven las cámaras de la cabeza del robot. Anna Kikina, que se entrenó en la Tierra como operadora, dijo a Izvestia que el modo preferido es ese telecontrol sincronizado, aunque también se le pueden programar secuencias de acciones.
Tres formas de mandarlo. En modo copia repite al momento lo que hace el operador. En modo de supervisión recibe una tarea, también por voz gracias a un sistema de inteligencia artificial que desarrollan para él, y la cumple guiado por sus cámaras: tomar un martillo, entregar una llave, devolver una herramienta a su lugar. Y algunas tareas las puede hacer solo, según sus diseñadores.
Dentro primero, afuera después. El plan tiene dos etapas: probarlo en un módulo presurizado y luego montar su parte externa sobre el módulo ruso Nauka durante una caminata espacial de Piotr Dubrov y Anna Kikina, que están a bordo desde julio y se quedan hasta abril de 2027. Una vez afuera, se manejará desde dentro.
40 sesiones. Dudorov contó a TASS que habrá hasta 20 sesiones de práctica en un simulador virtual con el exoesqueleto y 20 con el robot, dentro y fuera: conectar un conector eléctrico, enganchar un mosquetón, poner una driza y usar distintas herramientas, con una mesa especial y una cámara externa montadas para la prueba.
¿El primero del mundo? Dudorov asegura que será el primer experimento en unir, como un solo sistema, a un cosmonauta dentro y a un robot fuera para hacer un trabajo útil. Es su afirmación: la estación ya tiene brazos robóticos que se mandan desde dentro o desde la Tierra, como se explica abajo; lo nuevo sería un robot con forma humana que copia en tiempo real los movimientos del operador en el exterior.
Cómo está planeado el control de Teledroid. Esquema simplificado: decodigo.com con datos de Roscosmos, TASS e Interfax.
Una caminata menos, si funciona
Salir de la estación es de lo más peligroso y costoso que hace una tripulación: cada caminata exige horas de preparación, dura seis o siete horas y expone a dos personas al vacío, a la radiación y a los micrometeoritos. En la estación ya trabajan robots que les ahorran parte de eso, pero ninguno con forma humana fuera. El brazo canadiense Canadarm2 y su «mano» Dextre se manejan desde dentro o desde la Tierra. El brazo europeo ERA llegó con el propio módulo Nauka en 2021, dio sus primeros pasos en abril de 2022 y movió su primera carga ese agosto. Robonaut 2, el humanoide de la NASA, trabajó dentro de la estación desde 2011 hasta que una falla lo hizo volver a la Tierra en 2018. Y el brazo de la empresa japonesa GITAI hizo tareas casi solo en 2021, dentro de una esclusa comercial.
Teledroid apuesta por otra cosa: un cuerpo parecido al de una persona para usar las mismas herramientas y agarraderas que ellas, y un operador que lo mueve como si fuera su avatar, igual que la construcción autónoma de ASTRA busca que los robots armen estructuras sin astronautas. La prueba de fuego será afuera, donde se hicieron caminatas como la de los paneles iROSA. Si el robot consigue preparar y recoger el lugar de trabajo, cada salida podría ser más corta; si repite la historia de FEDOR, será otra demostración que no pasa de la foto. Para entender qué hay dentro de un robot así, sirve la guía de los procesadores de los robots.
En octubre aparecieron en el navegador versiones jugables de Halo, GTA: Vice City, God of War o Super Mario 64, y las reunimos en una lista. La pregunta que más nos han hecho después es cómo es posible: esos juegos se escribieron para consolas con procesadores, tarjetas gráficas y controles que no tienen nada que ver con una pestaña de Chrome. La respuesta es que no hay un solo truco, sino cuatro caminos distintos, y que todos terminan en la misma pieza del navegador: WebAssembly.
Un juego de consola es un programa compilado para un procesador concreto (el MIPS de la Nintendo 64, el Emotion Engine de la PlayStation 2, el Cell de la PS3) que habla directamente con su hardware: le pide al chip gráfico que dibuje, al de sonido que suene y al puerto del control que le diga qué botón se pulsó. Para que corra en una pestaña hay que resolver cinco cosas a la vez: que su código se ejecute en un procesador distinto, que sus gráficos salgan por las funciones del navegador, que su sonido también, que el control se lea igual y que sus archivos (el disco o el cartucho) estén en algún lado. Y todo a 30 o 60 cuadros por segundo. Cada camino resuelve la primera parte de manera diferente.
Los cuatro caminos, qué necesita cada uno y ejemplos reales. Gráfica: decodigo.com.
Emular: una consola de mentira dentro de la pestaña
Un emulador es un programa que se hace pasar por la consola: lee las instrucciones del juego una por una, averigua qué significa cada una y hace lo que haría el procesador original, y además imita el chip gráfico, el de sonido y la memoria. El juego no se toca: corre tal cual, con la ROM o la imagen del disco. Para llevarlo al navegador, el emulador mismo se compila a WebAssembly. Así funcionan EmulatorJS, que se describe como «un frontend web para RetroArch» y carga sus núcleos de consolas antiguas; js-dos, que lleva DOSBox a la pestaña para los juegos de MS-DOS, y v86, que emula una PC x86 completa y va más lejos: traduce el código de máquina «a módulos de WebAssembly mientras corre» para ganar velocidad.
El problema es el costo. Un emulador trabaja varias veces por cada instrucción del juego, y eso es fácil para una NES o un Super Nintendo, razonable para una Nintendo 64 o una PlayStation, y muy difícil para una PS2, una PS3 o una Xbox 360, que ya en una PC nativa exigen procesadores potentes. Dentro de una pestaña, con la capa extra de WebAssembly, no alcanza. Por eso los juegos de esa generación de nuestra lista no son emuladores, sino de los caminos que siguen.
Portar el código, cuando existe
Si se tiene el código fuente del juego, no hace falta imitar ninguna consola: basta con compilarlo para el navegador. La herramienta casi universal es Emscripten, un compilador que toma código en C o C++ y produce WebAssembly más el JavaScript que lo conecta con la página; incluso traduce las bibliotecas que usan los juegos de PC (SDL para ventanas y controles, OpenGL para gráficos) a sus equivalentes del navegador. Lo probamos con un pequeño «bucle de juego» en C que mueve mil objetos durante 600 cuadros, compilado con Emscripten 7.0.0 en un contenedor sin red:
$ emcc -O2 hola.c -o hola.js
$ ls -l hola.js hola.wasm
7686 hola.js
9320 hola.wasm
$ node hola.js
Hola desde WebAssembly: el objeto 999 terminó en (19.20, 19.20)
$ head -c 8 hola.wasm | od -A n -t x1
00 61 73 6d 01 00 00 00
$ gcc -O2 hola.c -o hola-nativo && ./hola-nativo
Hola desde código nativo: el objeto 999 terminó en (19.20, 19.20)
El mismo archivo de C da el mismo resultado como WebAssembly y como programa nativo. Los 9 KB del .wasm empiezan con la firma 00 61 73 6d («\0asm») y la versión 1 del formato, y un navegador los ejecuta igual que Node. Así llegaron a la web los clásicos cuyo código se publicó: id Software liberó el de Doom en 1997 y el de Quake en 1999, y EA publicó en febrero de 2025, bajo licencia GPL, el de varios Command & Conquer, entre ellos Generals y Zero Hour, que hoy se juega en el navegador. Hay un detalle importante: lo que se libera es el código, no los gráficos, sonidos y mapas. EA dejó claro que esos siguen siendo suyos, y por eso el port de Generals pide los archivos de tu copia.
Descompilar o recompilar: rehacer el código que nunca se publicó
La mayoría de los juegos nunca liberó su código. La comunidad encontró dos formas de reconstruirlo a partir del programa compilado, y son las que explican casi toda la ola de octubre. Para entender qué es descompilar en general, tenemos una guía con el mismo programa descompilado en siete lenguajes.
La primera es la descompilación «coincidente»: un grupo de personas reescribe a mano, función por función, código en C que, al compilarse con el compilador original, produce exactamente los mismos bytes que el juego. El proyecto de Super Mario 64 terminó en 2019 y advierte que «no incluye todos los recursos» del juego: para compilarlo hay que poner tu propia ROM, de la que extrae los gráficos y sonidos. Con ese código ya legible se hicieron versiones para PC, como sm64coopdx, que es la base del Mario 64 multijugador de nuestra lista. Lo mismo pasó con LEGO Island: su descompilación compara cada función con el binario original, de ahí salió una versión portátil y, de esa, el port con Emscripten que se juega en isle.pizza. El Halo del navegador se apoya en otra descompilación hecha durante meses por aficionados, y Ship of Harkinian hizo lo mismo con Ocarina of Time para PC.
La segunda es la recompilación estática, que no espera a que alguien reescriba el código a mano: lo traduce una sola vez, de forma automática, a C. N64Recomp lo describe así: convierte los binarios de la Nintendo 64 «en código C que se puede compilar para cualquier plataforma», instrucción por instrucción y de forma muy literal, para evitar el trabajo que un emulador repite en cada ejecución. Con esa herramienta se hizo Majora’s Mask para PC (Zelda64Recomp, mayo de 2024), que solo pide tu copia del juego. La misma idea, aplicada a la PSP, la PS2 y la PS3, está detrás de los God of War y Gran Turismo 4 de la lista y de ps3recomp. El resultado se puede compilar como programa nativo o, otra vez con Emscripten, como WebAssembly.
Lo que hace un emulador en cada ejecución frente a lo que hace la recompilación estática una sola vez. Gráfica: decodigo.com con datos de N64Recomp.
La recompilación no es gratis: el programa necesita saber dónde empieza y termina cada función, y N64Recomp lo saca de una descompilación o un desensamble ya hecho. Tampoco sirve para todo: el código que se genera o se modifica mientras el juego corre, o los chips muy particulares de cada consola, siguen pidiendo trabajo a mano. Es, en parte, lo que la IA aceleró este año. Un caso cercano, aunque no sea en el navegador, es nxnative: como la Switch y los chips de Apple usan procesadores ARM, puede ejecutar el código original sin traducirlo y solo reemplaza lo que hacía el sistema de la consola.
Reimplementar el motor y usar los datos de siempre
El cuarto camino deja el código original de lado y escribe un motor nuevo que entiende los archivos del juego: los mapas, modelos, texturas y guiones. OpenRCT2 se presenta como una «reimplementación de código abierto de RollerCoaster Tycoon 2» y OpenMW como un motor que «permite jugar Morrowind». Ninguno trae el juego: los dos leen los datos de tu instalación. Como suelen estar en C o C++, también se pueden compilar a WebAssembly. reVC, la base del Vice City del navegador, está entre este camino y el anterior: sus autores reconstruyeron el código del juego a partir del binario, y también necesita los archivos de tu copia.
Lo que pone el navegador
Sea cual sea el camino, el juego termina hablando con las mismas piezas del navegador. WebAssembly ejecuta el código a una velocidad cercana a la nativa; WebGL (y su sucesor, WebGPU) dibuja en 3D usando la tarjeta gráfica; Web Audio mezcla el sonido; la Gamepad API lee los controles de Xbox o PlayStation conectados a la computadora, y IndexedDB o el sistema de archivos privado del origen (OPFS) guardan las partidas y los archivos que subes. Si el juego usa varios hilos, como casi todos los modernos (uno para el sonido, otro para la física), hace falta SharedArrayBuffer, y aquí aparece la trampa que más proyectos encuentran.
Las piezas del navegador que usa un juego portado. Gráfica: decodigo.com con datos de MDN, web.dev y Emscripten.
Desde las vulnerabilidades Spectre, los navegadores solo dan SharedArrayBuffer a las páginas «aisladas entre orígenes», y para eso el servidor tiene que mandar dos encabezados. La documentación de Emscripten lo advierte: el código con hilos «no funcionará» si no están bien puestos. Lo comprobamos con un programa de dos hilos compilado con -pthread, servido dos veces a Chromium:
--- sin encabezados
cross-origin-opener-policy: (no viene)
cross-origin-embedder-policy: (no viene)
crossOriginIsolated = false; typeof SharedArrayBuffer = undefined
salida del programa: (nada)
error: Failed to execute 'postMessage' on 'Worker': SharedArrayBuffer transfer requires self.crossOriginIsolated.
--- con COOP y COEP
cross-origin-opener-policy: same-origin
cross-origin-embedder-policy: require-corp
crossOriginIsolated = true; typeof SharedArrayBuffer = function
salida del programa: Dos hilos terminados: 999999 y 1500000
Sin los encabezados, el programa ni siquiera arranca; con Cross-Origin-Opener-Policy: same-origin y Cross-Origin-Embedder-Policy: require-corp, funciona. El precio es que la página ya no puede cargar imágenes, guiones ni anuncios de otros sitios que no lo autoricen, por eso estos ports suelen vivir en dominios propios, sin nada más alrededor. Si quieres jugar con estas piezas desde cero, nuestro ejemplo de canvas en JavaScript y el curso de C son un buen comienzo.
Lo legal: el código no es el juego
La línea que separa a los proyectos que siguen en línea de los que cayeron es casi siempre la misma: quién pone los datos del juego. Un emulador, una descompilación o un motor reimplementado pueden ser código propio, pero los gráficos, la música, los modelos y los mapas siguen siendo de la editora, aunque el juego ya no se venda. Por eso Halo, Vice City, God of War, Gran Turismo 4, Mario 64 o Generals piden la imagen de tu disco, tu ROM o los archivos de tu instalación, mientras que los que repartían el juego entero, como Black Ops o GTA V, fueron los primeros en desaparecer. Celeste es un ejemplo de manual: su estudio pidió el 14 de octubre retirar de GitHub una versión para el navegador que incluía sus gráficos y sonidos.
Tampoco el código está a salvo. Take-Two pidió en febrero de 2021 retirar de GitHub los proyectos re3 y reVC, y en septiembre demandó a sus desarrolladores; el caso terminó en abril de 2023 con un acuerdo cuyos términos no se publicaron. The Simpsons: Hit & Run del navegador parte de un código que se filtró en 2021, lo que lo deja en una posición todavía más frágil. Y que una empresa libere el código, como EA, no libera los datos. Para el contexto más amplio, en especial ahora que la IA abarata la ingeniería inversa, revisamos qué dice la ley.
Los cuatro caminos, comparados
Emular. Necesita: la ROM o el disco. Ventaja: sirve para cualquier juego de esa consola sin tocarlo. Costo: el más lento; en el navegador funciona bien hasta la generación de Nintendo 64 y PlayStation. Ejemplos: EmulatorJS, js-dos, v86.
Portar el código. Necesita: el código fuente. Ventaja: el juego corre como programa propio, a máxima velocidad. Costo: solo existe para juegos cuyo código se publicó (o se filtró). Ejemplos: Doom, Quake, C&C Generals.
Descompilar o recompilar. Necesita: reconstruir el código desde el binario, a mano o con una herramienta. Ventaja: velocidad nativa y la posibilidad de mejorar el juego (más resolución, más cuadros por segundo). Costo: meses de trabajo por juego, aunque la IA lo está acortando. Ejemplos: Super Mario 64, LEGO Island, Halo, God of War, ps3recomp.
Reimplementar el motor. Necesita: entender los formatos de los archivos del juego. Ventaja: libertad total para corregir y ampliar. Costo: es escribir un motor completo. Ejemplos: OpenRCT2, OpenMW y, a medio camino, reVC.
Lo que cambió en 2026 no es la técnica: los cuatro caminos existen desde hace años. Cambió la velocidad. Lo que antes era el trabajo de un equipo de aficionados durante años, hoy se acelera con agentes de IA que leen desensambles y escriben código, y por eso la lista de juegos en el navegador creció en semanas. La parte difícil sigue siendo la misma de siempre: el juego tiene que ser tuyo para que esto tenga sentido.
Cómo Craft Anything estudia un sitio, pone a un agente a construir tu versión, la compara en tres anchos y la refina. Esquema didáctico con porcentajes de ejemplo: decodigo.com.
Storytold, el equipo detrás de ArtCraft y PhotoCraft, publicó Craft Anything, una app de código abierto escrita en Rust que hace algo que hace un año sonaba a ciencia ficción: le das un sitio web, una aplicación o un juego, le dices qué quieres, y estudia el original, pone a un agente de IA a construir tu propia versión y la compara con el original hasta que se parecen. Salió el 31 de octubre, ya va en la versión 0.5.0 y suma más de 20,000 estrellas en GitHub en una semana. Sus autores la describen como alpha temprana.
El proyecto viene del mismo grupo que en octubre presentó una docena de aplicaciones creativas libres hechas con ayuda de Claude, las «Crafting Apps», y que defiende un software creativo abierto construido con IA. Esa familia sigue creciendo a toda velocidad: PhotoCraft, su imitación de Photoshop, pasó de la versión 0.9 y unas 61,000 estrellas cuando la reseñamos el 14 de octubre a la 0.21.0, publicada el 6 de noviembre, con casi 77,700. Craft Anything lleva la idea un paso más allá: en lugar de rehacer a mano una app famosa, ofrece la máquina para rehacer cualquiera.
La app trabaja en cuatro pasos y avisa en palabras simples cuando algo te toca decidir. Primero estudia el original: sus páginas en varios anchos de pantalla, sus archivos o cómo se ejecuta. Después un agente construye un proyecto nuevo en el lenguaje, framework o motor que pidas. Luego lo compara con el original, mide qué tanto se parece y enumera lo que todavía no coincide. Al final tienes algo que abrir, jugar o previsualizar, y puedes pedir cambios para que lo refine.
Del original a tu versión, en cuatro pasos y con la vuelta para refinar. Gráfica: decodigo.com con datos del README de Craft Anything.
Claves de Craft Anything
Dos modos de mirar. El modo de fábrica, Clean room, no lee nada del interior del original: trabaja con lo que ve un visitante, como capturas, texto visible, medidas, colores, fuentes y menús. El modo Deep usa todas las herramientas, lee el código y los archivos del programa o el JavaScript de un sitio, y el proyecto lo marca como «para tu uso privado».
Clean room no es una jaula. El propio README aclara que es una regla sobre lo que la app ofrece y rechaza, no un aislamiento del sistema: el agente que corre en tu computadora sigue actuando con tus permisos.
Un motor de ingeniería inversa propio. Escrito en Rust, con sus propios decodificadores, desensamblador y descompilador, y Ghidra como apoyo si está instalado. Cubre programas nativos, .NET, Java, Android, apps de Apple, Electron y JavaScript, sitios web, firmware, capturas de red, bases de datos y archivos de juegos. Hoy suma 320 herramientas; cuando se anunció eran 284.
Hecho para agentes. Cada herramienta es a la vez una orden de la terminal y una herramienta MCP, así que cualquier agente puede estudiar un objetivo o lanzar una reconstrucción completa sin abrir la app.
Claude Code primero. La app ejecuta tu propio claude, con tu sesión, y dice no tocar tu cuenta. Hay un adaptador para Codex que, según el README, todavía no se ha probado en una instalación real; GitHub Copilot y Grok Build se conectan por ACP, y de los demás agentes compatibles solo Maki se ha probado en vivo.
Qué funciona y qué no. Funcionan la app de escritorio, la línea de comandos y el servidor MCP; el ciclo completo con Claude Code; las comparaciones de sitios web en tres anchos, y las reconstrucciones de juegos en Unity, Unreal o Godot. Quedan a medias construir con otros agentes o con claves de API y las comprobaciones de comportamiento de apps y juegos.
Para casi cualquier sistema. Hay instaladores para Windows (x64, ARM y 32 bits), macOS firmado y notarizado, Linux en AppImage, Flatpak, .deb, .rpm y tarball (también RISC-V), FreeBSD y un visor web en WebAssembly. La licencia es MIT o Apache-2.0, a elegir.
Lo que mira cada modo: Clean room se queda en lo visible; Deep entra al código y los archivos. Esquema: decodigo.com.
¿Y REA? Algunos medios presentaron Craft Anything como «la versión de REA de Storytold», en referencia a REA, la herramienta de ingeniería inversa para agentes que hemos seguido aquí. Revisamos el README, los avisos de licencia, la lista de créditos, la documentación de estado y del plan, las dependencias y las incidencias del repositorio: no hay ninguna mención a REA, y el motor se presenta como propio. No pudimos confirmar que use o derive de REA; lo que sí comparten es la idea de darle a un agente herramientas de análisis por medio de MCP.
El límite entre aprender de una app y copiarla
Craft Anything pone en manos de cualquiera algo que antes pedía semanas de trabajo especializado, y por eso hereda todas las preguntas que repasamos en la ingeniería inversa barata con IA y la ley. El proyecto pide usarlo solo con software propio o que tengas permiso de examinar, asegura que no evade DRM, inicios de sesión ni sistemas anticheat, y le indica al agente no copiar logotipos, fotos ni textos sin confirmar que tienes derechos sobre ellos. Aun así, reproducir el diseño y el comportamiento de un producto ajeno puede chocar con sus términos de uso, como los que Microsoft ya actualizó contra la ingeniería inversa con IA, y el modo Deep, que lee el código, entra de lleno en terreno delicado.
También hay un riesgo más cotidiano que el README menciona con honestidad: cuando el agente instala las dependencias de un proyecto, esos paquetes pueden ejecutar código en tu computadora. La app pide permiso antes de cada tipo de orden nueva, pero elegir «permitir siempre» para npm abre la puerta a todo lo que venga después. Para quien quiera entender por dentro cómo se analiza un programa compilado, nuestras guías de descompilación y de REA explican las piezas que herramientas como esta automatizan. Craft Anything muestra hacia dónde va todo esto: estudiar, rehacer y comparar software se está volviendo una tarea de minutos, y la pregunta ya no es si se puede, sino quién puede hacerlo con qué.
La mayoría de las placas de desarrollo se diseñan pensando en quien escribe el código. ESP-Mosaico, que Espressif presentó el 20 de octubre, parte de otra idea: que el código lo escriba un agente de IA. Es una unidad compacta con el nuevo chip ESP32-S31, una pantalla táctil cuadrada y dos ranuras donde se enchufan módulos, como una cámara o un panel de sensores, que la placa identifica sola. Se programa conversando con el agente que trae dentro o con Codex o Claude Code desde la computadora, y el kit cuesta $59 USD.
Espressif es la empresa china detrás del ESP32, el microcontrolador con Wi-Fi que está en millones de enchufes inteligentes, focos y proyectos caseros, y que hace unos días protagonizó WireClaw, un proyecto que convierte una placa de $5 USD en un agente que crea sus propias automatizaciones. Con ESP-Mosaico la propia Espressif empuja esa dirección: en su comunicado lo define como «una plataforma de desarrollo modular diseñada para crear hardware con ayuda de IA». La gracia no está tanto en el chip como en que el agente pueda saber qué tiene conectado, escribir el programa, cargarlo y comprobar en la placa real si funciona.
El kit de $59 USD: la unidad central, el módulo de cámara y el de interacción, en carcasas de resina impresa en 3D. Imagen: Espressif.
Por dentro hay dos placas apiladas. La de arriba, la CoreBoard, lleva el ESP32-S31, la pantalla de 2.16 pulgadas y 480 × 480 píxeles, el audio y los sensores de movimiento. La de abajo, la BaseBoard, lleva el altavoz, una batería pequeña y las dos ranuras de expansión. Cada módulo trae una memoria diminuta con su identificación, así que la placa, y con ella el agente, sabe si lo que se enchufó es una cámara o el panel de sensores.
Cómo se reparten las piezas entre la CoreBoard, la BaseBoard y los módulos. Gráfica: decodigo.com con datos de Espressif.
Claves de ESP-Mosaico
El chip. El ESP32-S31 es RISC-V de doble núcleo a 320 MHz, con Wi-Fi 6, Bluetooth 5.4 y radio 802.15.4 para Thread y Zigbee. La placa suma 16 MB de PSRAM, 16 MB de flash y 128 MB de memoria NAND para guardar programas y datos.
Pantalla y sensores. Pantalla táctil cuadrada de 2.16 pulgadas, micrófono, altavoz con amplificador de 3 W, un sensor de movimiento de seis ejes, dos magnetómetros, motor de vibración y una batería de 65 mAh que se carga por USB-C.
Dos módulos por ahora. Una cámara, que solo cabe en la ranura izquierda, y un módulo de interacción con sensor de movimiento por infrarrojo, fotorresistor, LED infrarrojo para controlar aparatos, seis LED de color y dos teclas que también funcionan como botones táctiles. Espressif habla de más módulos para sensores, luces y motores, pero no los ha detallado.
Chat Coding. La placa trae de fábrica a ESP-Claw, un agente que corre en el propio dispositivo: le pides algo por chat o por voz, genera el código, lo ejecuta y lo vas ajustando conversando, sin instalar nada en la computadora. Incluye una cuota gratuita para preguntas y programas sencillos; para más, se configuran las credenciales de un modelo propio. Lo que funciona se guarda como skill para reusarlo.
Vibe Coding. Para proyectos más grandes, el trabajo lo hace un agente en tu computadora, como Codex, Claude Code, OpenCode o Trae: describe la tarea, la prueba en un simulador de la placa, compila, la instala por USB y la valida en el dispositivo real. Espressif lo liga a su plataforma ESP ZeroCode AI, que simula la placa y sus periféricos.
Precio. La tienda oficial lo vende en preventa en $59 USD con la cámara y el módulo de interacción. CNX Software reporta una batería opcional de $15 USD. Antes del anuncio, vendedores de AliExpress lo ofrecían en unos $117 USD, según LinuxGizmos.
El módulo de interacción, con sus piezas señaladas: teclas y zonas táctiles (Key y Touch), sensor de movimiento (PIR), fotorresistor (LDR), LED infrarrojo y LED de color. Imagen: Espressif.
Un detalle que muestra lo nuevo del producto: la documentación técnica de Espressif llama «LCD» a la pantalla, mientras que su comunicado dice que es OLED. El dato que lo resuelve está en la propia guía: el controlador de la pantalla es un CO5300, un chip de Chipone hecho para pantallas OLED de relojes inteligentes, así que lo más probable es que el comunicado tenga razón.
Los dos caminos para programarla: con el agente que trae la placa o con uno en tu computadora. Gráfica: decodigo.com con datos de Espressif.
Lo que cambia cuando el programador es un agente
Programar un microcontrolador siempre tuvo un paso que las IA no podían dar solas: conectar la placa, cargar el programa y ver qué pasa en el mundo físico. ESP-Mosaico intenta cerrar ese ciclo con tres piezas que casi ninguna placa común ofrece juntas: módulos que se identifican solos, un simulador para probar antes de cargar y herramientas para que el agente vea la pantalla y los resultados en el dispositivo. Es la misma idea que separa, en el mundo de los robots, a el procesador que piensa del que controla los motores: aquí el agente piensa y el ESP32 ejecuta.
Falta ver qué tan bien funciona fuera de la demostración. Nadie lo ha probado de forma independiente todavía, y como advierte Pause Hardware, que un agente escriba y cargue el programa no sustituye las pruebas eléctricas ni de confiabilidad que necesita un producto terminado. Para aprender, prototipar o hacer un juguete interactivo en una tarde, en cambio, un kit de $59 USD que ya trae pantalla, sensores, cámara y un agente integrado es una entrada muy barata a la electrónica sin pelearse con cables ni con el entorno de desarrollo. Si buscas una computadora completa en lugar de un microcontrolador, nuestra comparativa de Raspberry Pi y sus competidoras es mejor punto de partida.
La unidad central sola, con la tabla de pines impresa en el costado. Imagen: Espressif.
La «fábrica en abanico» del paper de DeepMind: un cálculo previo grande y, después, cada clave RSA de 1024 bits mucho más barata. Esquema simplificado: decodigo.com.
Google DeepMind anunció el 6 de noviembre que sus agentes de IA, guiados por criptógrafos, encontraron en pocas semanas dos debilidades en el RSA de 1024 bits. La primera permite falsificar firmas digitales con mucho menos cómputo cuando el atacante controla buena parte del mensaje que se firma. La segunda abarata unas 30 veces factorizar cada clave adicional cuando se atacan muchas claves del mismo tamaño. DeepMind lo dejó claro desde el principio: ninguna de las dos afecta al RSA de 2048 bits, el que protege hoy la mayor parte de la web.
RSA basa su seguridad en que factorizar un número enorme, encontrar los dos primos que lo forman, es muy caro. El RSA de 1024 bits ya se considera débil desde hace más de una década y casi todo se migró a 2048 bits o más, pero sigue vivo en equipos viejos, firmware y sistemas que nadie ha actualizado. En septiembre, un equipo de UC San Diego e Inria encabezado por Nadia Heninger y Emmanuel Thomé demostró que podía falsificar firmas RSA de 1024 bits usando un módulo de seguridad de hardware (HSM) como «oráculo» de firmas, sin sacar nunca la clave: le costó 1,380 años-núcleo de cómputo durante cinco meses. Heninger y Thomé también colaboraron con DeepMind en el trabajo nuevo, dirigido por Dj Dvijotham y Abhradeep Thakurta.
Lo nuevo es cómo se hizo. Según DeepMind, dos agentes de IA repitieron ese ataque de firmas sobre una clave de prueba ya resuelta, con unas 3.5 veces menos tiempo de CPU, en menos de cuatro días y con apenas unos 20 mensajes cortos de un investigador. En el paper sobre la factorización en lote, publicado el 5 de noviembre, los autores explican que usaron un arnés de dos agentes: un modelo escribía las demostraciones y otro las verificaba, y las identidades algebraicas quedaron comprobadas por máquina en Lean 4.
Los dos resultados, en resumen. Gráfica: decodigo.com con datos de Google DeepMind.
Claves de las dos debilidades
Firmas con relleno que ya no protege. Antes de firmar, RSA agrega un relleno (padding) al mensaje para impedir falsificaciones. DeepMind encontró que si el atacante controla aproximadamente la mitad o más del bloque que se firma, ese relleno casi no aporta protección. En el caso de una huella de 32 bytes, su algoritmo sería unas 1,600 veces mejor que el mejor ataque conocido. Es una estimación teórica, no un ataque medido.
Muchas claves, mucho más baratas. El segundo trabajo, «Fan Factories», mejora la «fábrica de factorización» de Don Coppersmith: se hace una vez un cálculo previo compartido y luego se atacan muchas claves del mismo tamaño. Con un cálculo previo equivalente a una factorización, cada clave extra de 1024 bits costaría cerca de 1/58 de una factorización normal, 30 veces menos que con el mejor método de este tipo, el MNFS, que no había mejorado desde 1993.
Solo en el papel, por ahora. El propio paper aclara que nadie ha construido una de estas fábricas y que las cifras son estimaciones a orden principal. Además, el cálculo previo exige guardar una cantidad enorme de datos, otro obstáculo práctico.
Una sola clave no se vuelve más fácil. La mejora en lote solo baja el costo de cada clave adicional. Romper una clave aislada cuesta lo mismo que antes.
RSA de 2048 bits, fuera de alcance. A ese tamaño, el cálculo previo costaría unas 2117 operaciones. «Nuestros resultados no amenazan los sistemas desplegados hoy que se basan en RSA de 2048 bits o más», escriben los autores.
Costo de cada clave extra de 1024 bits con cada método, en estimación teórica. Gráfica: decodigo.com con datos del paper «Fan Factories».
Qué cambia para quien todavía usa claves de 1024 bits
Para la mayoría de la gente, nada: navegadores, bancos y aplicaciones de mensajería usan claves de 2048 bits o criptografía de curvas elípticas. El aviso es para quien administra sistemas viejos. Si un equipo todavía firma con RSA de 1024 bits, y sobre todo si firma datos que un tercero puede elegir, como hace un HSM que atiende peticiones, hoy es más vulnerable que hace dos meses y conviene migrarlo. Y si una organización tiene muchas claves de 1024 bits del mismo tamaño, el ataque en lote las hace un blanco más atractivo en conjunto.
La otra lectura es sobre la velocidad. El exponente de la factorización en lote llevaba 33 años sin moverse, y un equipo con agentes de IA lo bajó en semanas. Es la misma tendencia que mostraron otros laboratorios este año con ataques a esquemas criptográficos de prueba: la IA ya no solo escribe código, también ayuda a encontrar grietas en las matemáticas que lo protegen. Los autores lo ven como una herramienta para medir mejor la fuerza de cada sistema y planear la migración a tiempo, en lugar de tratar la dificultad de romper una clave como un dato fijo.
Cómo ASTRA armó su tercer módulo en órbita: el robot de pórtico toma uniones y barras de los dispensadores y construye sin manos humanas. Esquema didáctico: decodigo.com.
Por primera vez, una máquina armó por su cuenta una estructura en órbita, sin astronautas. ASTRA, un robot diseñado y construido en Caltech con dinero del programa NOM4D de DARPA, tomó barras y uniones sueltas de sus dispensadores y construyó con ellas un módulo de armadura mientras daba vueltas a la Tierra. «Es la primera vez que una estructura se construye de forma autónoma en el espacio», dijo Sergio Pellegrino, profesor de ingeniería aeroespacial de Caltech y líder del proyecto. La meta era un reflector de antena de 1.4 metros con 11 módulos; el tiempo solo alcanzó para el tercero.
Todo lo grande que hoy está en órbita llegó doblado o en pedazos. Los paneles y las antenas se pliegan para caber bajo la cubierta del cohete y se despliegan arriba, como el espejo del telescopio James Webb, o se arman a mano con módulos enviados en varios lanzamientos, como la Estación Espacial Internacional. Las dos vías tienen un techo: el tamaño del cohete o el costo de muchos viajes y caminatas espaciales. DARPA lanzó NOM4D en 2022 para probar una tercera opción, mandar la materia prima y construir donde se va a usar. De los equipos del programa, solo dos llegaron a la fase de demostración en el espacio: el de Caltech y uno de la Universidad de Illinois, que más adelante probará en la Estación Espacial una forma de endurecer tubos de material compuesto.
ASTRA, siglas en inglés de «ensamble autónomo de un reflector tensado en el espacio», es una caja de aproximadamente un metro cúbico. Despegó el 30 de marzo desde la base de Vandenberg como una de las 10 cargas del vehículo Vigoride 7 de Momentus, que a su vez viajó en la misión Transporter-16 de SpaceX. Llevaba dos módulos ya armados en tierra, el robot y todas las piezas para el resto de la armadura. En órbita, el equipo liberó los seguros de lanzamiento, empujó hacia afuera los dos módulos de fábrica y ordenó armar el tercero. Lo confirmó con fotos tomadas por las 11 cámaras de la carga útil, como la de la portada.
La secuencia que ASTRA repite con cada módulo. Esquema: decodigo.com con datos de Caltech y DARPA.
Claves de la demostración de ASTRA
Un robot sencillo a propósito. DARPA lo describe como un robot de pórtico que se mueve en tres ejes rectos, no como un brazo complejo. «No hay robótica complicada ni algoritmos avanzados; es ingeniería sólida para combinar operaciones de una forma que escala», dijo Andrew Detor, director de NOM4D, que lo comparó con armar piezas de un juego de construcción tipo Tinkertoy o K’Nex.
Las piezas. Barras de fibra compuesta, uniones de aluminio y una superficie reflectora de Kapton. El reflector es una película perforada en forma de red, desarrollada con la Universidad de Pensilvania, que necesita menos tensión que la malla metálica de las antenas plegables y permite estructuras más ligeras.
Tres de once. El robot pasó unos seis meses en órbita. El equipo se topó con muchos problemas imprevistos y no alcanzó a completar los 11 módulos de la armadura ni el reflector de 1.4 metros. La misión termina en diciembre.
Un gemelo en tierra. Solo había siete u ocho ventanas al día, de unos 15 minutos cada una, para hablar con ASTRA. Cada vez que algo fallaba, el equipo reproducía el problema en una copia idéntica en el laboratorio de Pellegrino, probaba soluciones y mandaba la que funcionaba.
Hecho a toda prisa. Caltech terminó, probó y entregó la carga útil en menos de 12 meses. Según Detor, de la idea de una prueba en órbita al lanzamiento pasaron 15 meses; NOM4D ni siquiera contemplaba al principio una demostración en el espacio.
Cuánto de la armadura alcanzó a armarse y cómo se llegó ahí. Gráfica: decodigo.com con datos de Caltech y DARPA.
Por qué un módulo armado en órbita cambia el límite de tamaño
Tres módulos de una armadura de 1.4 metros no son una antena útil, y nadie lo presenta así. Lo que se probó es el método: una caja de piezas que se arma sola, módulo por módulo, y que en teoría puede seguir creciendo mientras haya material. Detor habla de estructuras de «cientos de metros o kilómetros», que hoy no se pueden hacer: espejos para telescopios mucho más grandes que el Webb, antenas de radio enormes o campos solares para llevar energía desde el espacio, un tema que Pellegrino también investiga en Caltech. Es la misma apuesta que hacen empresas como Orbital Matter, que imprime vigas en 3D en órbita: dejar de diseñar para lo que cabe en un cohete.
El balance es honesto: el robot funcionó, pero se quedó corto. El equipo de Caltech dice que aprendió lo necesario para demostrar que el método es viable y que ahora toca simplificar el diseño. Para un primer intento, armado en menos de un año y operado en ventanas de 15 minutos, haber construido algo en el espacio sin una sola mano humana ya es la noticia.
Cómo una contraseña de más de 256 bytes termina en el mismo asterisco que marca una cuenta sin contraseña, y cómo lo cierra OpenSSH 10.6p2. Esquema: decodigo.com.
Un asterisco bastó para abrir servidores. El fallo CVE-2026-123158, que su descubridor bautizó como «*sshole», permite entrar por SSH a cuentas que no tienen contraseña en Alpine Linux y otros sistemas que usan la biblioteca musl: el atacante solo tiene que mandar una contraseña de más de 256 bytes. OpenSSH lo corrigió en la versión 10.6p2 y Alpine publicó paquetes parchados el 5 de noviembre para todas sus ramas desde la 3.16.
El investigador Özgün Kültekin, de la firma Wakefield, encontró que el fallo no está en una sola pieza, sino en la suma de tres decisiones razonables tomadas por separado. En Unix, una cuenta cuyo campo de contraseña dice solo «*» es una cuenta en la que ninguna contraseña puede coincidir: así se crean los usuarios que solo entran con clave SSH, y así viene root en Alpine desde hace años. En 2012, musl decidió que su función crypt(), la que cifra contraseñas, devolviera un «*» en lugar de un error cuando algo sale mal, y le puso un límite de 256 bytes a la contraseña para evitar ataques de denegación de servicio. Y en 2016, OpenSSH empezó a cifrar las contraseñas de las cuentas sin hash con una «sal» prestada de otra cuenta, para que un atacante no pudiera adivinar por el tiempo de respuesta qué usuarios existen.
Juntas, esas tres piezas producen el fallo: el sistema guarda «*» para la cuenta, la contraseña larga hace que crypt() falle y devuelva «*», y sshd compara uno con otro, los ve iguales y deja pasar. Los equipos con glibc, la biblioteca de Debian, Ubuntu y Fedora, no tienen el problema, y tampoco los que validan contraseñas con PAM.
La cuenta sin contraseña y la contraseña demasiado larga terminan en el mismo asterisco. Gráfica: decodigo.com con datos de Alpine Linux, OpenSSH y Özgün Kültekin.
Claves de *sshole
Qué hace falta. Un Linux con musl, como Alpine, OpenWrt, Buildroot o Yocto, y muchas imágenes de Docker basadas en ellos; un sshd sin parche y sin PAM, como el paquete openssh-server de Alpine; la entrada con contraseña permitida; una cuenta con «*» que SSH acepte; y otra cuenta con contraseña real que aporte la sal.
La contraseña mágica. Cualquiera de 257 a 1024 bytes, según el aviso de Alpine. No hay que adivinar nada: basta con que sea larga.
Qué cuentas corren peligro. Los usuarios que solo entran con clave y se crearon sin contraseña, los usuarios de servicios de directorio como sssd o winbind, y el usuario alpine de las imágenes tiny-cloud de la 3.18.11 a la 3.24.3, que además puede usar doas sin contraseña. Root está protegido por la configuración de fábrica, PermitRootLogin prohibit-password, salvo que alguien la haya cambiado.
Gravedad. 8.1 sobre 10 en la escala CVSS. El número de CVE se asignó después de que Alpine y OpenSSH publicaran sus avisos, por eso esos textos no lo mencionan.
¿Ya hay ataques? Según Help Net Security, la empresa Previdian registró el primer intento a menos de nueve horas de la publicación y vio a un atacante obtener root en un equipo trampa con Alpine: ocho intentos desde una sola dirección en Japón. Otras fuentes no reportaban ataques confirmados al 6 de noviembre, pero el código de prueba ya es público.
Quién lo corrigió. Damien Miller y Darren Tucker, de OpenSSH, con el análisis de Timo Teräs. OpenSSH considera que la causa está fuera de sshd, pero que ahí se puede evitar, y por eso lo corrigió en su código.
Las condiciones que deben cumplirse a la vez y lo que no está afectado. Gráfica: decodigo.com con datos de Alpine Linux y OpenSSH.
Qué hacer si administras un Alpine
Lo primero es actualizar con apk upgrade -U -a y reiniciar sshd, porque el programa que ya está corriendo sigue siendo el viejo hasta que se reinicia. Alpine aplica la corrección sin cambiar la versión de OpenSSH en algunas ramas, así que conviene revisar el paquete con apk info -v openssh-server en lugar de fiarse de sshd -V. Si no se puede actualizar de inmediato, desactivar la entrada con contraseña (PasswordAuthentication no) cierra la puerta, siempre que antes se compruebe que el acceso con clave funciona. Y como el fallo se pudo usar sin dejar más rastro que un inicio de sesión normal, Alpine recomienda buscar líneas «Accepted password for» de cuentas que no tienen contraseña en /var/log/messages, revisar usuarios y claves nuevas, y tratar como comprometido cualquier equipo en el que no se pueda descartar un acceso.
El caso es un buen ejemplo de por qué las convenciones viejas son peligrosas. Un asterisco que desde los primeros Unix quiere decir «aquí no entra nadie» acabó significando lo mismo que un error, y ningún componente estaba mal por sí solo. Lo que falló fue el supuesto de que una función que cifra contraseñas nunca devolvería exactamente lo que el sistema guarda para decir que no hay contraseña.
Cómo Claude lee tus cuentas por medio de Plaid sin poder mover el dinero: el acceso es de solo lectura. Esquema: decodigo.com con datos de Anthropic.
Anthropic lanzó Personal Finance, una función de Claude que se conecta a tus cuentas de banco y de tarjeta para responder preguntas sobre tu dinero: a dónde se fue el sueldo del mes, si gastas más de lo que ganas o qué cargos están subiendo sin que te des cuenta. La conexión se hace por medio de Plaid y es de solo lectura: Claude puede ver saldos y movimientos, pero no puede mover, administrar ni invertir el dinero. Está en beta desde el 5 de noviembre, en los planes Pro, Max y Ultra, y por ahora solo en Estados Unidos.
La idea no es nueva. OpenAI agregó a ChatGPT herramientas parecidas, también con Plaid, en mayo de 2026, y desde septiembre se habían visto en la app de Claude para iOS pistas de una función llamada «Claude Money». Plaid es el intermediario que usan muchas apps financieras de Estados Unidos: la persona inicia sesión en su banco dentro de la ventana de Plaid, aprueba qué cuentas comparte, y la app recibe los datos sin conocer nunca la contraseña. Anthropic sigue ese mismo esquema y añade un espacio propio en la barra lateral de Claude, con tablas de gastos por categoría y preguntas sugeridas.
Tu banco, Plaid y Claude: el acceso es de solo lectura. Esquema: decodigo.com con datos de Anthropic.
Lo que hace Personal Finance
Suma y ordena tus gastos. Agrupa lo que gastaste en el mes por categorías, como renta y servicios, comida o compras, y lo compara con meses anteriores. También puede armar gráficas semanales, calendarios de pagos y paneles a la medida.
Busca lo que se escapa. Señala cargos duplicados, comisiones inesperadas y recibos que han ido subiendo, y calcula cuánto te queda antes del siguiente pago de nómina tomando en cuenta los cargos programados.
Explica términos. Por ejemplo, qué es la tasa anual de una tarjeta y cuánto pagaste de intereses en el último año.
Qué datos ve. Solo de las cuentas que elijas: el nombre del banco y de cada cuenta, el tipo de cuenta, los últimos cuatro dígitos, los saldos, los límites de crédito y hasta dos años de movimientos. El anuncio habla de cuentas de banco y de tarjeta; las notas de versión de Claude añaden préstamos e inversiones.
Qué no hace. No mueve dinero, no da asesoría de inversión, no tiene anuncios ni recomendaciones patrocinadas, y Anthropic no vende tarjetas, préstamos ni cuentas de ahorro propias.
Privacidad. Las conversaciones dentro del espacio de Personal Finance no se usan para entrenar los modelos; fuera de él aplican tus ajustes de privacidad de siempre. Una cuenta se puede desconectar en cualquier momento y, desde entonces, Claude deja de ver sus datos.
Lo que Claude ve de las cuentas conectadas y lo que no puede hacer. Esquema: decodigo.com con datos de Anthropic.
Antes de conectarle tu banco a una IA
El atractivo es evidente: una app de presupuestos tradicional te muestra gráficas, pero aquí puedes preguntar «¿me alcanza para un viaje en primavera?» y recibir una respuesta con tus propios números. El riesgo también. El propio anuncio advierte que Claude puede equivocarse y recomienda pedirle las transacciones detrás de cada cifra y confirmar con el banco cualquier dato importante. Y aunque el acceso sea de solo lectura, dos años de movimientos dicen mucho de una persona: dónde vive, qué compra, cuánto gana. Conviene conectar solo las cuentas necesarias y revisar qué pasa con esos datos al desconectarlas, algo que Anthropic remite a su centro de privacidad.
Para quienes leen desde México, la función todavía no sirve: solo funciona con bancos de Estados Unidos conectados por Plaid, y Anthropic no ha dicho cuándo llegará a otros países. Lo que sí deja ver es hacia dónde van los asistentes de IA: después del código y los documentos, las empresas quieren que sean también el lugar donde se revisa el dinero, y Anthropic ya dijo que busca trabajar con bancos, administradores de patrimonio y asesores financieros con licencia.
Cómo un pez dorado, una sesión de IA sin memoria, revisa el diseño que redactó el elefante antes de que se escriba código. Esquema: decodigo.com.
Google publicó como código abierto el Elephant-Goldfish Model (EGM), un plugin para agentes de programación con IA que los obliga a escribir y defender un documento de diseño antes de tocar el código. La idea cabe en una frase: diseña con un elefante, revisa con un pez dorado. El elefante es una sesión larga que lo recuerda todo; los peces dorados son sesiones nuevas que no recuerdan nada y solo leen el documento. Según Google, miles de sus ingenieros lo usan a diario para enviar código a producción. Funciona en Claude Code, Codex y Antigravity.
El método no nació como software. Dave Rensin, de Google, lo describió primero en un ensayo publicado en Medium, «Elephants, Goldfish and the New Golden Age of Software Engineering», que Google Research incluye en su lista de publicaciones. Su diagnóstico es conocido para cualquiera que programe con agentes: pedirle todo a la IA en un solo prompt produce código rápido, pero también más errores, más «slop» (código de relleno que nadie revisó a fondo) y conversaciones tan largas que el propio modelo pierde el hilo. El 22 de octubre, el equipo de Rensin publicó el plugin en el blog de código abierto de Google con una frase de él como lema: «el diseño es el nuevo código».
El truco está en quién revisa. Una sesión que pasó una hora discutiendo un diseño ya no puede leerlo con ojos frescos: rellena cada hueco del documento con lo que recuerda de la conversación, igual que le pasa a una persona con su propio texto. Un pez dorado no tiene esa ventaja. Si una decisión importante solo quedó en la charla y no en el documento, el pez no la encuentra, y eso es justo lo que se busca descubrir antes de programar.
Las fases del plugin, de la lluvia de ideas a la decisión humana. Gráfica: decodigo.com con datos de Google.
Claves del Elephant-Goldfish Model
Tres órdenes./egm-brainstorm abre una discusión con el elefante en la que está prohibido escribir código y deja la dirección acordada en concepts_brief.md. /egm-draft convierte eso en un documento de diseño, design_draft.md, y se detiene después de cada sección para que la corrijas. /egm-review manda el documento a los peces dorados.
Tres pruebas para el documento. Un pez debe explicar la arquitectura y la intención del diseño; si no puede, el documento es ambiguo. Varios más actúan como revisores escépticos que buscan casos límite, dependencias ocultas y huecos lógicos. Un último revisa que estén las rutas de archivos, las estructuras de datos y las firmas de las funciones, y da el veredicto: ir o no ir.
Memoria cero de verdad. Los peces son subagentes nuevos que reciben solo el documento y los archivos que cita. Si el agente donde corre el plugin no puede crear subagentes así, la revisión se detiene en lugar de simularla dentro de la misma conversación.
La última palabra es tuya. La revisión genera muchos comentarios a propósito; la persona elige cuáles atender, aprueba el diseño y solo entonces le pide al agente que programe. El README lo dice sin rodeos: una revisión no reemplaza las pruebas ni el juicio humano.
Dónde funciona. En Claude Code, Codex CLI, la app de escritorio de ChatGPT y Codex, Antigravity (el entorno de Google), Claude Cowork y ChatGPT Work. Tiene licencia Apache 2.0, aunque el repositorio aclara que no es un producto con soporte oficial de Google.
No revisa la seguridad por su cuenta. Los fallos de seguridad no están en la lista de lo que buscan los revisores, según Help Net Security. Los roles se pueden personalizar, pero una revisión de amenazas hay que configurarla aparte.
El elefante conoce toda la historia; el pez dorado solo lo que quedó por escrito. Esquema: decodigo.com.
Para probarlo en Claude Code bastan dos órdenes y abrir una sesión nueva; después, las skills aparecen con el prefijo /egm:, por ejemplo /egm:egm-brainstorm.
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm
Lo que cambia para quien programa con agentes
EGM no es un modelo nuevo ni una herramienta mágica: es un procedimiento empaquetado en skills y prompts de revisores, que se monta sobre el agente que ya usas. Su valor está en mover el esfuerzo humano de leer código a leer diseños, donde un error cuesta minutos y no días. También tiene límites que conviene tener presentes. El ciclo completo es pesado, y la propia guía del proyecto desaconseja usarlo para arreglos pequeños. La cifra de «miles de ingenieros» la da Google y nadie la ha medido por fuera, y no hay datos públicos de cuánto mejora la calidad del código. Además, si el elefante y los peces usan el mismo modelo, comparten sus sesgos: una sesión nueva olvida la conversación, no lo que el modelo aprendió.
Aun así, la idea sirve aunque nunca se instale el plugin. Cualquiera puede escribir el plan en una conversación larga, abrir otra limpia, pegarle solo el documento y pedirle que lo explique. Si la segunda IA no entiende el plan, tampoco lo hará la que escriba el código, ni la persona que lo mantenga dentro de un año.
Cómo el exploit burló el parche de junio y cómo lo detiene el Patch 3, en un esquema simplificado de la memoria del switch. Esquema: decodigo.com.
Durante semanas, los ataques a casi 1,000 switches Zyxel GS1900 se atribuyeron a un fallo que Zyxel había corregido en junio. No era así. La empresa de seguridad Binarly encontró el exploit que usaban los atacantes y descubrió que funcionaba igual en los equipos ya actualizados: aprovechaba otro fallo, desconocido hasta entonces, que ahora se registra como CVE-2026-107441. Zyxel lo corrigió con el firmware 2.90 Patch 3 y publicó su aviso el 3 de noviembre.
Los GS1900 son switches administrables pensados para oficinas y pequeñas empresas, y se configuran desde una página web que corre dentro del propio equipo. El 16 de junio, Zyxel corrigió en esa página el CVE-2026-7273, un desbordamiento de búfer que permitía ejecutar órdenes sin contraseña. A partir del 17 de agosto, la firma GreyNoise empezó a ver ataques contra estos switches: un grupo de habla china, al que llama Kapibala y vincula con la campaña Red Heron, tomó el control de 996 equipos en 48 países y, tras entrar, ejecutaba un script que copiaba su configuración, el hash de la contraseña de administrador y datos de la red. El 21 de septiembre, GreyNoise atribuyó los ataques al fallo de junio y la agencia de ciberseguridad de Estados Unidos, CISA, lo agregó a su lista de fallos explotados. Para muchos administradores, el mensaje fue claro: con el parche de junio, sus equipos estaban protegidos.
Binarly llegó por otro camino. Mientras investigaba los servidores de Red Heron, relacionados con la puerta trasera JITTERLY y el rootkit SIXZUT, encontró en uno de ellos un archivo expuesto con el exploit: un programa en Python ofuscado que primero revisaba si el switch tenía el parche de junio. Lo probó y confirmó el 28 de septiembre que funcionaba en las diez versiones de firmware ya parchadas. Avisó a Zyxel al día siguiente, Zyxel confirmó el 11 de octubre que se trataba de un fallo distinto y el 22 de octubre publicó el firmware que lo corrige. Para Binarly, «el parche de junio dio a los clientes una falsa sensación de seguridad».
Del parche de junio al firmware que sí corrige el fallo. Gráfica: decodigo.com con datos de Zyxel, Binarly, GreyNoise y CISA.
Claves del zero-day de los Zyxel GS1900
Dónde está el fallo. En dispatcher.cgi, el programa que atiende las peticiones de la página de administración. Copia cada parámetro de la petición a un búfer de memoria de tamaño fijo sin revisar cuánto mide ni cuántos son. Es una escritura fuera de límites: un dato demasiado largo sigue escribiendo más allá del espacio que le toca.
Por qué el parche de junio no sirvió. Zyxel añadió una revisión del número de parámetros, pero se hacía después de copiarlos. Un parámetro enorme se desborda y altera el contador de parámetros antes de que la revisión lo lea, así que el control ve un número falso y deja pasar la petición.
Qué gana el atacante. Con peticiones HTTP preparadas, y sin contraseña, puede ejecutar órdenes en el sistema del switch. Zyxel le da una gravedad de 8.8 sobre 10 y dice que el atacante debe estar en la red local; Binarly la califica con 9.8, dice que funciona desde cualquier red que llegue a la página del switch y que da acceso de administrador total.
Diez modelos afectados. GS1900-8, -8HP, -10HP, -16, -24, -24E, -24EP, -24HPv2, -48 y -48HPv2. Las versiones Patch 2 y anteriores siguen expuestas.
Contraseñas de fábrica. De los 996 equipos atacados, 564 conservaban las credenciales con las que salieron de fábrica, según eSecurityPlanet.
¿Un exploit hecho con IA? Binarly cree que el programa del atacante se generó con un modelo de lenguaje, y anunció que publicará una prueba de concepto reducida.
Esquema simplificado: cómo un parámetro demasiado grande pisa el contador antes de que el parche de junio lo revise. Gráfica: decodigo.com con datos de Binarly y Zyxel.
Qué deben hacer quienes administran estos switches
Lo primero es instalar el firmware 2.90 Patch 3 del modelo exacto y comprobar en cada equipo la versión que de verdad está corriendo: un inventario que solo diga «tiene el parche de junio» ya no sirve. Después, conviene que la página de administración no sea accesible desde redes en las que no se confía, cambiar las contraseñas, sobre todo si siguen siendo las de fábrica, y comparar la configuración con un respaldo conocido. Actualizar cierra la puerta, pero no echa a quien ya entró: un switch que estuvo expuesto entre agosto y octubre debe revisarse como posiblemente comprometido.
El caso deja una lección que va más allá de Zyxel. Un parche puede revisar lo correcto en el momento equivocado, y las herramientas que solo comparan números de versión dirán que un equipo está protegido cuando no lo está. Esta vez, el error se descubrió porque alguien analizó el exploit real de los atacantes, en lugar de dar por hecho cuál fallo usaban. Si se confirma que ese exploit lo escribió una IA, también será una muestra de lo rápido que se pueden encontrar las grietas de un parche apresurado.
