Comparto su diagnóstico al 200%, aunque no su conclusión. Aquí es donde difieren nuestras perspectivas.

Llevo casi tres décadas construyendo infraestructura de internet en España. Desde los tiempos de Fidonet y las BBS, varios proveedores de hosting a mis espaldas, hasta cofundar Stackscale, donde operamos infraestructura cloud privada con centros de datos en Madrid y Ámsterdam bajo jurisdicción europea. He visto nacer este sector, he visto cómo Europa perdía posiciones año tras año, y he visto cómo cada intento de reacción se quedaba en papel mojado. Pero también sé, porque lo vivo cada día, que la tecnología y el talento europeo existen. Lo que falta es otra cosa.

Los números que nadie quiere mirar a la cara

AWS, Azure y Google controlan más del 70% del mercado europeo de cloud. Los proveedores europeos hemos pasado del 27% de cuota en 2017 a un 15% que se ha estabilizado — si es que a eso se le puede llamar estabilización y no simplemente tocar fondo. OVHcloud, el mayor proveedor europeo, factura menos de 1.000 millones de euros al año. AWS facturó 107.600 millones de dólares en 2024. Más de cien veces más.

Y aquí viene lo que más duele: los hyperscalers estadounidenses invierten más de 10.000 millones de euros cada trimestre solo en infraestructura europea. Cada trimestre. Más de lo que todos los proveedores europeos juntos invertimos en un año entero. Microsoft invierte 3.200 millones en centros de datos en Alemania, mientras que toda la industria cloud alemana invierte unos 2.000 millones anuales.

El 92% de los datos europeos se almacena en servidores gestionados por empresas estadounidenses. Y no es solo una cuestión de dónde están los servidores: el 85-90% de la tecnología que hay en cualquier centro de datos europeo — incluidos los nuestros en Stackscale — es americana. Intel y AMD controlan entre el 95 y el 100% de los procesadores de servidor. NVIDIA tiene el monopolio absoluto en GPUs para IA. Cisco domina el networking con casi el 77% del mercado global.

Esto implica algo incómodo que hay que decir en voz alta: incluso cuando una empresa elige un proveedor europeo como Stackscale, la cadena de suministro de hardware sigue siendo fundamentalmente estadounidense. Es una dependencia de doble capa que nadie parece querer abordar de verdad.

El director legal de Microsoft Francia lo dijo bajo juramento

En noviembre de 2025 ocurrió algo que debería haber sido un terremoto, pero apenas generó ruido: el director legal de Microsoft Francia, Anton Carniax, reconoció bajo juramento que la compañía no puede garantizar que los datos de ciudadanos franceses no sean transferidos a las autoridades estadounidenses sin autorización explícita de Francia.

Bajo juramento. No puede garantizarlo.

Y no es que Microsoft sea especialmente mala en esto. Es que la US CLOUD Act obliga a cualquier empresa estadounidense a entregar datos almacenados en sus servidores cuando el gobierno de EE.UU. los solicite, da igual en qué país estén físicamente esos datos. Esto convierte en papel mojado cualquier promesa de «sovereign cloud» que provenga de un hyperscaler americano. Son soluciones de marketing, no de soberanía real.

En Stackscale operamos como empresa europea, bajo jurisdicción europea, con datos que nunca salen del territorio europeo. Cuando digo soberanía, no es un claim de marketing: es una realidad jurídica. Y eso es exactamente lo que ningún hyperscaler americano puede ofrecer, por muchos centros de datos que abran en Frankfurt o en Madrid.

Lo que nos enseña Stackscale sobre lo que Europa sí puede hacer

Desde Stackscale, como parte de Grupo Aire, llevamos años demostrando algo que el discurso derrotista ignora sistemáticamente: que se puede hacer cloud europeo competitivo, fiable y de primer nivel. Nuestros clientes — desde startups hasta grandes cuentas que necesitan cumplimiento normativo estricto — nos eligen no por patriotismo, sino porque la propuesta de valor funciona: proximidad, control real sobre los datos, jurisdicción europea, soporte humano directo y un rendimiento que no tiene nada que envidiar a los grandes.

¿Tenemos la escala de AWS? Obviamente no. Pero la pregunta correcta no es si un solo proveedor europeo puede igualar a AWS. La pregunta es si Europa, de verdad, puede construir un ecosistema que cubra las necesidades del mercado europeo. Y la respuesta es sí: sí se hace con la misma lógica que se usó para crear Airbus.

Lo que veo en el día a día es que cada vez más empresas españolas y europeas se plantean repatriar cargas de trabajo críticas a proveedores europeos. No por moda ni por regulación, sino porque la geopolítica les ha enseñado que tener todos los huevos en la cesta de un proveedor sujeto al derecho estadounidense es un riesgo real para el negocio.

Gaia-X, CADA, EuroStack: ¿esta vez va en serio?

La historia reciente de Europa en esto es un catálogo de buenas intenciones mal ejecutadas. Gaia-X nació con la ambición de ser la respuesta europea y acabó con AWS, Azure y Google como miembros del consorcio. Los críticos la llamaron «alianza de perdedores» desde el principio, y aunque incluir a los hyperscalers tenía cierta lógica pragmática, el resultado ha sido que la iniciativa se ha diluido hasta la irrelevancia práctica.

Pero algo ha cambiado en los últimos meses y merece atención. En noviembre de 2025, Francia y Alemania convocaron una Cumbre de Soberanía Digital Europea con compromisos concretos y un grupo de trabajo conjunto. La iniciativa EuroStack, nacida en el Parlamento Europeo en septiembre de 2024 e impulsada por voces como Cristina Caffarra, Francesca Bria y CEOs de empresas europeas como Nextcloud, Proton y Ecosia, ha ganado tracción política real: figura en el programa de coalición del gobierno alemán y ha sido reconocida oficialmente en múltiples foros institucionales. Su estimación: se necesitan unos 300.000 millones de euros en una década. Suena a mucho, pero Europa gasta 264.000 millones al año en proveedores tecnológicos extranjeros. Con lo que gastamos en poco más de un año, financiaríamos una década entera de soberanía digital.

Y luego está el Cloud and AI Development Act (CADA), previsto para 2026. A diferencia de todo lo anterior, CADA es una legislación vinculante basada en el artículo 114 del TFUE. No un framework voluntario, no unas directrices, no otro Gaia-X. Sus objetivos: triplicar la capacidad de los centros de datos de la UE en 5-7 años, simplificar los permisos, establecer requisitos de soberanía para la contratación pública y crear un esquema de certificación cloud europeo.

Como dice Christoph Strnadl, CTO de Gaia-X: ninguna empresa estadounidense puede garantizar que el gobierno de EE.UU. no acceda a tus datos. Para datos críticos, jamás deberías usar una empresa estadounidense. Soberanía significa tener opciones estratégicas, no hacerlo todo tú mismo.

España tiene un papel clave que jugar

Y aquí es donde quiero poner el foco: se habla mucho de Francia y Alemania, pero España tiene cartas muy potentes en esta partida.

Nuestro mercado cloud crece a un 21,6% anual, el más rápido de Europa según las proyecciones. España está emergiendo como uno de los destinos más atractivos para centros de datos hiperescala en Europa, con un crecimiento proyectado del 12,5% anual hasta 2031. Tenemos ventajas competitivas reales: energía renovable abundante, clima favorable para la eficiencia energética, conectividad con Latinoamérica y el norte de África, talento técnico a costes competitivos y ubicación geográfica estratégica.

AWS ya anunció una inversión de 7.800 millones de euros en una región de Brandeburgo, pero España está en la lista de todos los hyperscalers su expansión. La pregunta es: ¿vamos a ser solo receptores pasivos de centros de datos americanos o vamos a usar este momento para construir capacidad propia?

Desde Stackscale llevamos años operando infraestructura cloud en Madrid con tecnología Proxmox, demostrando que no hace falta VMware (ahora Broadcom) ni depender de licencias estadounidenses para ofrecer virtualización de primer nivel. Es un ejemplo pequeño pero significativo: cuando Europa tiene alternativas open source competitivas, debería usarlas.

España, además, tiene el ecosistema. Empresas como Stackscale, Tenocrática, Comvive, Arsys, Gigas, Acens, Dinahosting, Telefónica Tech y otras tantas que cuenta con capacidad técnica real. Lo que no tenemos es un marco de coordinación que nos permita operar como un ecosistema integrado en lugar de como competidores fragmentados peleándonos por las migajas que dejan los grandes.

Lo que realmente necesitamos: pensar como Airbus, no como 27 aerolíneas de bandera

Hermann lo dice en su artículo y yo llevo años diciéndolo: la fragmentación es nuestro mayor enemigo. Europa no tiene un problema de talento, ni de dinero, ni siquiera de tecnología — tiene un problema de escala provocado por la insistencia en tener campeones nacionales en lugar de construir un campeón europeo.

Cuando se quiso competir con Boeing, no se crearon 27 fabricantes nacionales de aviones. Se creó Airbus. Cuando se quiso hacer física de partículas de primer nivel, no se construyeron 27 aceleradores nacionales. Se creó el CERN. Esos proyectos funcionaron porque se entendió que ciertas cosas solo pueden hacerse a escala continental, con inversión coordinada y visión a largo plazo.

El cloud y la infraestructura digital son exactamente ese tipo de proyecto. Y el timing es ahora. La IA generativa está acelerando todo: representa el 50% del crecimiento del mercado de cloud desde 2022. AWS planea invertir entre 100.000 y 105.000 millones de dólares solo en 2025 — más que el valor de mercado del cloud europeo completo. Cada trimestre que pasa sin un movimiento europeo real, la brecha se profundiza.

El contexto geopolítico ha cambiado radicalmente. La administración Trump ha demostrado que EE.UU. está dispuesto a instrumentalizar las dependencias tecnológicas como palanca política. Esto ya no es un debate académico sobre soberanía: es una vulnerabilidad estratégica real que, por fin, los gobiernos europeos empiezan a tomarse en serio.

Qué hay que hacer, sin paños calientes

Lo que necesitamos no es otro framework, ni otra cumbre, ni otro consorcio con 200 miembros donde las decisiones se diluyen por consenso:

Escala real, no fragmentación disfrazada de diversidad. Consolidar esfuerzos, crear consorcios europeos de infraestructura cloud que operen como una sola entidad a escala continental. Proveedores como Stackscale, OVHcloud, Telefónica, Hetzner, Scaleway, IONOS y otros tenemos que encontrar la forma de interoperar y presentar una oferta conjunta creíble frente a los hyperscalers.

Compra pública europea decidida. Si los gobiernos europeos no usan infraestructura europea para sus servicios críticos, ¿por qué debería hacerlo nadie? La contratación pública es la palanca más potente que tenemos y la estamos desperdiciando.

Inversión industrial con lógica Airbus. Europa necesita fondos de inversión en infraestructura digital coordinados a nivel continental, no programas de ayudas fragmentados entre 27 estados que nadie coordina.

Honestidad sobre las dependencias. Sí, nuestros servidores cuentan con procesadores Intel y AMD. Sí, nuestras GPUs son NVIDIA. No podemos cambiar eso mañana. Pero podemos construir la capa de servicios y operaciones bajo jurisdicción europea e invertir en alternativas a medio plazo: RISC-V, los procesadores de SiPearl, el EU Chips Act.

Tratarlo como lo que es: infraestructura crítica. Igual que nadie discute que Europa necesita defensa propia, infraestructura energética propia y un sistema financiero propio, necesitamos aceptar que la infraestructura digital tiene el mismo nivel estratégico.

La pregunta no es si Europa puede. Es si Europa quiere.

Quiero ser claro: esto no va de odiar a los americanos ni de cerrar fronteras digitales. Va de que Europa tenga alternativas reales y competitivas. Va de que, cuando el director legal de Microsoft admite bajo juramento que no puede garantizar la privacidad de tus datos ante al gobierno de EE.UU., tienes otro sitio donde ir.

Los hyperscalers americanos son buenos. Son muy buenos. Tienen escala, tecnología y décadas de ventaja. Pero la idea de que no se puede competir con ellos es un derrotismo autocomplaciente.

Hace un año Hermann decía que si alguien te ofrece una alternativa europea creíble a los hyperscalers, te levantes y salgas de la sala. Yo digo algo diferente: si alguien te dice que Europa no puede construir esa alternativa, sal tú de la sala. Porque esa persona no ha entendido que no se trata de capacidad, sino de voluntad y coordinación.

Desde Stackscale, desde España, desde el ecosistema europeo de infraestructura que conozco por dentro, lo tengo claro: la tecnología está, el talento está, el mercado está. Lo que ha faltado siempre es la voluntad política de hacer las cosas a la escala en que se necesitan.

Cada trimestre que pasa sin un movimiento europeo real, coordinado y a escala continental, la dependencia se vuelve más profunda, más estructural y más difícil de revertir. O construimos nuestro propio ecosistema ahora o seremos eternamente dependientes de decisiones tomadas fuera de nuestras fronteras.

La elección es nuestra. Pero el tiempo se agota.

La entrada La soberanía digital europea es un espejismo mientras sigamos fragmentados aparece primero en Carrero.

Justin Poehnelt lo explica muy bien en su artículo “You Need to Rewrite Your CLI for AI Agents”, publicado el 4 de marzo de 2026. Su tesis es muy directa: la experiencia de desarrollador pensada para humanos y la pensada para agentes no son lo mismo. La primera prioriza el descubrimiento, la flexibilidad y el perdón ante los errores. La segunda necesita predictibilidad, estructuras claras y defensa en profundidad. Justin no lo plantea como teoría abstracta, sino desde la experiencia de haber construido una CLI para Google Workspace pensada para agentes desde el primer día. Además, acompaña esa idea con una skill pública instalable con este comando: npx skills install jpoehnelt/skills/agent-dx-cli-scale.

Lo interesante es que esta reflexión no se limita a “hagamos que la IA ejecute comandos”. Va mucho más allá. Lo que plantea es que muchas CLI tradicionales están diseñadas para un uso humano que no encaja bien con los modelos de lenguaje. Un humano puede leer una tabla bonita, navegar por documentación externa, tolerar cierta ambigüedad o improvisar cuando algo falla. Un agente no funciona así. Un agente necesita salidas estructuradas, introspección en tiempo real, validación agresiva de las entradas y barreras de seguridad frente a sus propias alucinaciones. Y, cuanto más lo pienso, más sentido me tiene.

También me parece especialmente valioso que Justin no se quede en la superficie y publique después un segundo texto, “The MCP Abstraction Tax”, en el que añade un matiz muy relevante: cada capa que ponemos entre la intención del agente y el dato real introduce un coste de abstracción. En su esquema, el dato está en el fondo, encima está la API, y encima puede llegar MCP. Cada capa aporta cosas útiles —descubrimiento, seguridad, estandarización—, pero también pierde fidelidad. Y cuando trabajas con APIs complejas, ese coste acumulado puede importar mucho más de lo que parece.

Aquí es donde, personalmente, creo que se abre un debate muy interesante.

Porque durante mucho tiempo hemos asumido que una buena API era suficiente, y que una CLI era, básicamente, una capa de comodidad para personas. Pero si aceptamos que cada vez más tareas pasarán por agentes, entonces una CLI deja de ser solo una herramienta de productividad humana y se convierte en una especie de interfaz operativa entre la IA y el sistema real. En ese contexto, ya no importa solo que el comando sea bonito o fácil de recordar. Importa que sea robusto ante entradas erróneas, que pueda devolver JSON limpio, que permita pedir solo los campos necesarios, que tenga dry-run, que exponga esquemas en tiempo de ejecución y que no obligue al agente a tragarse medio manual antes de empezar a trabajar.

Lo que más me ha hecho pensar de su planteamiento

Hay tres ideas del enfoque de Justin que me parecen especialmente acertadas.

La primera es dar prioridad a las cargas útiles completas en JSON frente a una maraña de flags pensados para humanos. Puede sonar incómodo para una persona, pero para un LLM tiene mucho sentido: reduce las traducciones intermedias y permite expresar estructuras anidadas sin inventar convenciones adicionales.

La segunda es convertir la propia CLI en una fuente de documentación viva e introspectable. En vez de obligar al agente a cargar documentación estática en el prompt, la idea es que pueda consultar esquemas, parámetros y tipos sobre la marcha. Esto no solo ahorra contexto, sino que también reduce el riesgo de trabajar con documentación desactualizada.

La tercera, y quizá la más infravalorada, es la de no confiar en la entrada del agente. Justin lo dice con mucha claridad: los humanos cometen errores; los agentes alucinan. No es el mismo problema. Por eso propone endurecer la validación: rechazar caracteres de control, impedir rutas sospechosas, evitar parámetros incrustados en los IDs, controlar la codificación y asumir siempre que la entrada puede ser adversaria, aunque no haya mala intención. Me parece una idea fundamental. En el fondo, se parece mucho a cómo deberíamos diseñar cualquier frontera seria entre el software y el mundo real.

El punto donde CLI y MCP no compiten, sino que se complementan

Otra parte que me parece muy útil del debate es que Justin no cae en el simplismo de presentar CLI vs MCP como si hubiera que elegir un ganador. En su artículo sobre el “abstraction tax”, lo que plantea es más interesante: cada enfoque optimiza aspectos distintos. MCP favorece descubribilidad y estandarización. Una CLI bien diseñada para agentes puede preservar mejor la fidelidad y ofrecer más flexibilidad, sobre todo si se apoya en skills y en la carga de contexto bajo demanda. El problema real no es cuál “gana”, sino dónde pagas el peaje de la abstracción y si ese peaje te compensa.

Y esto me parece especialmente relevante ahora que tantas empresas están corriendo a “poner un MCP” sobre cualquier cosa, a veces sin revisar si la API subyacente ya era complicada, hostil o excesivamente abstracta. Si la base es mala, la capa superior no hace milagros. A veces ordena. A veces ayuda. Pero también puede ocultar problemas que luego reaparecen en producción de formas más difíciles de depurar. Esa es una conversación que, en mi opinión, todavía estamos empezando a tener.

Mi impresión personal

Mi sensación es que Justin está señalando algo muy importante: la Agent DX se va a convertir en una disciplina real. Igual que durante años hemos hablado de UX, DX, DevOps o platform engineering, vamos a empezar a hablar de herramientas, patrones y guardarraíles diseñados específicamente para agentes.

No creo que eso signifique reescribir de cero todas las CLI del mundo mañana. Tampoco creo que la respuesta sea abandonar las APIs limpias ni la buena documentación. Pero sí creo que obliga a repensar las prioridades. Añadir --output json, endurecer entradas, exponer esquemas, soportar dry-run, reducir salidas innecesarias, incorporar skills o contexto operativo específico… todo eso deja de ser “nice to have” y empieza a parecerme parte del diseño serio de cualquier herramienta que quiera convivir con agentes de IA de verdad.

Y aquí es donde me gustaría abrir el debate.

Porque no tengo claro que el futuro pase por una única respuesta. Habrá casos en los que una CLI agent-first tenga todo el sentido. Habrá otros donde una API directa más una buena librería sean mejores. Y habrá escenarios en los que MCP aporte una capa útil de estandarización. Lo que sí me parece evidente es que seguir pensando únicamente en interfaces para humanos empieza a quedarse corto.

Preguntas frecuentes

¿Qué propone exactamente Justin Poehnelt?
Propone que muchas CLI dejen de diseñarse solo para humanos y adopten patrones pensados para agentes de IA: JSON como entrada de primera clase, introspección de esquemas, validación dura de entradas, salida estructurada, dry-run y skills para aportar contexto operativo.

¿Qué es npx skills install jpoehnelt/skills/agent-dx-cli-scale?
Es el comando de instalación de una skill pública del repositorio personal de Justin Poehnelt, descrita como una escala para evaluar hasta qué punto una CLI está bien diseñada para agentes de IA.

¿Qué aporta su artículo sobre MCP?
En “The MCP Abstraction Tax”, Justin sostiene que cada capa entre la intención del agente y los datos reales —por ejemplo, las APIs y las MCP— introduce un coste de abstracción y una pérdida de fidelidad, algo especialmente importante en las APIs empresariales complejas.

¿La CLI y la MCP compiten entre sí?
Según el planteamiento de Justin, no necesariamente. MCP y CLI optimizan cosas distintas: descubrimiento y estandarización en un caso, fidelidad y flexibilidad en el otro. La cuestión clave es entender los costes y beneficios de cada capa.

Más referencias: Noticias.AI

La entrada ¿Hay que rediseñar las CLI para agentes de IA? Una reflexión a partir de Justin Poehnelt aparece primero en Carrero.

Durante años, en el mundo de la empresa y del software se ha repetido una idea casi como un dogma: no intentes hacerlo todo, no abarques demasiado, no te disperses. Era un buen consejo en un contexto normal. Servía para mantener el foco, para evitar proyectos imposibles y para no perder meses en ambiciones mal definidas. Garry Tan parte precisamente de ahí, pero sostiene que ese consejo empieza a quedar obsoleto en una etapa marcada por agentes de IA cada vez más capaces y por una automatización del trabajo intelectual que está cambiando la escala de lo posible.

Y creo que ese es el punto realmente interesante.

Una parte importante del debate actual sobre inteligencia artificial se ha quedado atrapada entre dos extremos. Por un lado, el miedo: la idea de que la IA llega para sustituir, abaratar y recortar. Por otro lado, la exageración vacía: promesas casi místicas sobre un futuro perfecto. Entre esas dos posiciones hay una tercera, mucho más útil, que es la que me interesa: la IA como multiplicador de capacidad para quien quiera construir de verdad.

Garry lo plantea con bastante claridad. Su argumento de fondo es que el miedo al futuro crece cuando nuestras aspiraciones son demasiado pequeñas. Si una persona o una empresa solo piensa en seguir haciendo exactamente lo mismo que hace hoy, pero de forma un poco más eficiente, entonces una máquina que lo haga más rápido y más barato da miedo. Pero si la ambición cambia y lo que se busca es construir algo mucho más grande, mucho mejor o mucho más útil, entonces la máquina deja de ser una amenaza y pasa a ser una herramienta extraordinaria.

Esa idea me parece especialmente valiosa porque obliga a revisar el tipo de preguntas que nos hacemos. Muchas empresas siguen atrapadas en una mentalidad de optimización mínima: cómo reducir un 5 % de costes, cómo ganar un poco más de margen, cómo hacer el mismo proceso con menos personas. Garry critica precisamente esa lógica y propone otra muy distinta: en lugar de usar la IA para arañar mejoras pequeñas, usarla para atacar objetivos que antes parecían excesivos o directamente imposibles. En su artículo pone ejemplos muy concretos: por qué conformarse con mejoras marginales si se puede aspirar a productos o servicios que multipliquen de verdad el valor entregado.

A mí me parece que ahí está el auténtico cambio de época.

La IA no obliga solo a aprender nuevas herramientas. Obliga, sobre todo, a elevar el tamaño de nuestras ambiciones. Porque si la capacidad de ejecutar software, analizar información, diseñar procesos o construir servicios se multiplica, seguir pensando con el marco mental de hace cinco años puede convertirse en un lastre. No basta con correr más. Hay que decidir hacia dónde merece la pena correr.

Esto tiene implicaciones muy profundas para fundadores, directivos, inversores y también para quienes trabajan por cuenta ajena. Garry llega a decir que, para quien vive de intercambiar trabajo por salario, este puede ser el momento de convertirse en constructor, de iniciar proyectos propios y de usar estas herramientas para ampliar radicalmente su capacidad. Y para quienes ya tienen responsabilidad de gestión o acceso a capital, su planteamiento es todavía más contundente: no usar la IA solo para recortar, sino para ampliar de forma mucho más agresiva el nivel de aspiración.

Comparto bastante esa mirada. No porque piense que todo vaya a ser fácil ni porque la transición no vaya a traer tensión, sino porque reducir la IA a una herramienta para sustituir tareas me parece una forma muy pobre de entender lo que está ocurriendo. La pregunta relevante no es únicamente qué trabajo se automatiza. La pregunta de verdad es qué tipo de empresa, de producto, de servicio o de infraestructura se vuelve viable ahora.

Ese cambio de enfoque también ayuda a entender por qué la obsesión por la “eficiencia” puede quedarse corta. La historia de la tecnología demuestra que cuando algo se vuelve mucho más eficiente, no siempre se consume menos; muchas veces ocurre lo contrario. Garry enlaza esa idea con el concepto de Buckminster Fuller de hacer cada vez más con cada vez menos, y también con la lógica de la paradoja de Jevons: cuando un recurso se abarata y se vuelve más útil, su uso puede dispararse en lugar de reducirse. En su texto aplica esa lógica a la inteligencia, al trabajo y a la creación de productos y servicios.

Y aquí creo que merece la pena detenerse un momento. Porque esa expansión no sucede por sí sola. No basta con que exista una tecnología poderosa. Hace falta también dirección, valentía, capital y, sobre todo, una voluntad real de pensar a otra escala. Si la IA se usa solo para exprimir un poco más el modelo anterior, el resultado será decepcionante. Si se usa para abrir mercados, lanzar productos radicalmente mejores, automatizar lo tedioso y liberar tiempo para crear valor nuevo, entonces sí puede cambiar muchas cosas.

Por eso, más que “hervir el océano”, yo diría que ha llegado el momento de atreverse con lo que antes parecía inabarcable. Esa sería, al menos para mí, la mejor forma de decirlo en castellano. No se trata de hacer locuras ni de perder el foco. Se trata de aceptar que el foco de ayer quizá ya no sea suficiente para el mundo que viene.

Las startups siempre han tenido ventaja cuando el terreno cambia deprisa, porque pueden moverse sin tanto peso, sin tanta burocracia y sin tanta necesidad de justificar cada paso con un Excel. Garry recuerda, precisamente, que las startups son especialmente buenas para construir para un futuro 10x, mientras que otros siguen optimizando el presente a un 1,05x. Y quizá esa sea la gran lección de esta etapa: la IA va a premiar menos a quien defiende lo de siempre y más a quien tenga el coraje de replantear la escala de lo que quiere construir.

Yo me quedo con esa idea. No como consigna grandilocuente, sino como disciplina mental. En una etapa como esta, el mayor riesgo no es solo quedarse atrás en términos tecnológicos. El mayor riesgo es quedarse atrás en la ambición.

Inspirado en “Boil the Ocean”, de Garry Tan, publicado en Garry’s List el 7 de febrero de 2026.

La entrada Ha llegado la hora de pensar a lo grande con la Inteligencia Artificial aparece primero en Carrero.

Por eso me resulta tan llamativo lo que está ocurriendo ahora. La inteligencia artificial no solo está acelerando tareas: en mi caso, me ha devuelto algo que daba por perdido: el disfrute de crear software. Y no hablo de “ver cómo un modelo genera un snippet bonito”, sino de levantar aplicaciones completas, probar ideas, iterar y, sobre todo, sentir que la fricción ha bajado lo suficiente como para que vuelva a merecer la pena ponerse a construir por puro placer.

La sorpresa no es el código: es el método

En estos últimos experimentos, me he encontrado con una sensación que hacía años que no sentía: la consistencia. Con Claude Code, al menos en mi experiencia reciente, la tasa de éxito ha sido del 100 %: toda aplicación que he pedido ha funcionado a la primera. Suena exagerado, y lo sé, porque la programación nunca es perfecta. Pero lo que me tiene pensando no es el número en sí, sino el porqué.

La clave no es que el modelo “sea un genio”, sino el enfoque de trabajo. Claude Code no se limita a contestar en una ventana de chat: se apoya en un flujo en el que el proyecto tiene memoria, reglas, convenciones y objetivos que se vuelven persistentes. Y ahí entra una pieza que, aunque parezca menor, es el corazón de todo: el archivo CLAUDE.md.

CLAUDE.md: un contrato para que el agente no improvise

Claude Code permite dos tipos de memoria: una “auto memory”, donde el sistema guarda contexto útil (patrones del proyecto, comandos clave, preferencias), y otra basada en archivos CLAUDE.md, que el usuario escribe y mantiene como un conjunto de instrucciones y reglas. Dicho sin vueltas: es un documento que le dice al agente “así se trabaja aquí”. Y eso, para alguien que lleva años gestionando sistemas y proyectos, es casi una obviedad: si el marco es claro, el resultado suele ser mejor.

Lo que cambia con estos agentes es que ese marco ya no es solo documentación para humanos: también es la guía operativa de la inteligencia artificial. Si el archivo define cómo se estructura el repositorio, qué comandos se usan para test, cómo se valida una entrega, qué estilo se sigue y qué decisiones no se tocan, el asistente deja de improvisar y empieza a ejecutar con mayor fiabilidad.

Mi experimento: “refinar el guion” antes de tocar el repositorio

La rutina que me ha funcionado (y que me ha hecho replantearme el flujo entero) ha sido esta:

1. Pedir a Claude (en la web) que genere un CLAUDE.md con unos objetivos concretos.
2. Pedirle a Gemini que mejore ese Markdown.
3. Pedirle a GPT que lo mejore de nuevo.
4. Pasar el resultado final a Claude Code en la terminal.

Lo interesante es que no estoy usando varios modelos para “escribir el código”, sino para mejorar el documento de instrucciones. Es decir: estoy invirtiendo el esfuerzo en el guion, no en la escena. Y ahí aparece una verdad incómoda para cualquiera que haya trabajado con equipos técnicos: cuando lo que se pide está bien definido, lo normal es que se ejecute mejor. Solo que ahora ese “equipo” incluye un agente que edita archivos, ejecuta comandos y trabaja con el repositorio como si fuera un desarrollador más.

En mi caso, al refinar el CLAUDE.md con varios modelos, el documento termina siendo más nítido: menos ambigüedad, más criterios verificables, mejor orden y —muy importante— menos contradicciones internas. El resultado se nota después: Claude Code entra en el repositorio con un mapa más claro y toma decisiones más alineadas con lo que realmente quiero.

Por qué esto encaja con mi forma de trabajar (aunque haya pasado tanto tiempo)

Si dejé de programar en 1998, no fue por falta de interés, sino por el contexto. La realidad es que el mundo cambió y mis prioridades también. Pero hay algo que no ha cambiado: mi obsesión por los sistemas que funcionan, por los procesos repetibles y por reducir el caos operativo.

Claude Code, en cierto modo, se siente como llevar esa mentalidad al desarrollo: reglas claras, memoria persistente y una herramienta que puede operar mediante archivos y comandos. La documentación lo presenta como un asistente de programación que entiende el código base y puede trabajar en múltiples archivos y herramientas; además, existe en varias “superficies” (terminal, IDEs, escritorio y web) que comparten el mismo motor para reutilizar la configuración y la memoria del proyecto. Esa continuidad es justo lo que permite trabajar por hábitos, no por improvisación.

Y aquí aparece otra cosa que, para mí, es muy reveladora: la idea de poder arrancar una sesión local y continuarla desde otro dispositivo. El concepto de Remote Control apunta a un futuro en el que programar no es “sentarse en el escritorio”, sino continuar tareas donde te toque, manteniendo la ejecución en tu propia máquina y conservando las herramientas locales y la configuración del proyecto. No es un detalle menor: es una pista clara de hacia dónde va el desarrollo asistido por agentes.

Lo que he aprendido: la inteligencia artificial rinde más cuando se le baja la incertidumbre

Si tuviera que resumir la lección en una frase, sería esta: la inteligencia artificial programa mejor cuando no tiene que adivinar.

Un CLAUDE.md bien escrito reduce la incertidumbre en puntos muy concretos:

• Qué hay que construir y qué no.
• ¿Cómo se valida que está “bien”?
• ¿Qué estilo y qué convenciones se consideran correctos?
• ¿Qué comandos forman el camino estándar (build, test, lint, ejecución)?
• ¿Qué decisiones arquitectónicas son intocables?
• ¿Qué atajos o patrones del repositorio conviene respetar?

En mi caso, ese documento es lo que convierte un “hazme una app” en un “hazme esto, así, con estas restricciones y con esta forma de comprobarlo”. Y cuando además lo refinan varios modelos antes de dárselo al agente que ejecuta, el resultado tiende a ser más consistente.

Una conclusión personal: no es nostalgia, es capacidad recuperada

Volver a programar no me ha hecho volver a 1998. Todo lo contrario: me ha recordado que el problema no era el lenguaje ni el IDE, sino el coste mental de ponerse a construir desde cero con poco tiempo y demasiadas cosas encima.

La inteligencia artificial ha reducido ese coste lo suficiente como para que vuelva a ser divertido. Y eso, para mí, es la gran noticia: no es que ahora “cualquiera programe”, sino que la barrera para experimentar ha bajado tanto que personas que llevábamos años en otros frentes podemos volver a crear, aprender y disfrutar.

Y sí, seguiré usando este enfoque de “refinar el guion” antes de tocar el repositorio. Porque, al final, la diferencia entre un agente que acierta y uno que divaga suele estar en lo mismo que diferenciaba a un buen proyecto de uno mediocre hace décadas: requisitos claros, reglas coherentes y una forma objetiva de saber si el trabajo está terminado.

Algunos experimentos que puedes visitar que me he apoyado en Claude como:

• Bitadir.com, un directorio de blogs con código de hace más de 12 años que he actualizado y refactorizado.
• Polen Madrid, como alérgico al polen, es un sitio donde consultar información y suscribirse para recibir alertas.
• FitBono, un sistema de gestión de clases para entrenadores personales hecho para iPhone, pensado para mi entrenador y que espero que pronto apruebe Apple.
• MboxViewer, otra herramienta para Mac para abrir mis backups de correo de Gmail con Google Takeout, que pesan más de 50 GB, y consultar correos electrónicos offline.
• mboxshell, la misma herramienta para leer grandes mbox, pero desde la terminal. Liberado en GitHub.
• CF football Bypass, un plugin para WordPress que si detecta que La Liga bloqueó tu sitio que usa Cloudflare lo desactiva temporalmente y lo vuelve activar cuando no estás bloqueado. No es lo ideal, pero al menos tu web funciona.
• Y muchas más cosas, tanto sin publicar como publicadas, que estoy experimentando…

Preguntas y respuestas

¿Qué es Claude Code?
Un asistente de programación agéntico que puede trabajar con un repositorio, editar archivos y ejecutar comandos desde la terminal y otras integraciones.

¿Para qué sirve CLAUDE.md?
Para dejar instrucciones persistentes del proyecto: reglas, convenciones y objetivos que el agente debe seguir en cada sesión.

¿Por qué mejorar el CLAUDE.md con varios modelos ayuda?
Porque reduce ambigüedades y contradicciones: el agente recibe un “contrato” más claro y toma mejores decisiones.

¿Esto garantiza que todo salga bien a la primera?
No, pero mejora la consistencia: cuando el contexto es claro y verificable, hay menos iteraciones y sorpresas.

La entrada Volver a programar después de décadas: cómo Claude Code y la Inteligencia Artificial han cambiado mi forma de construir aparece primero en Carrero.

El problema era el habitual en cualquier proyecto veterano que ha sobrevivido demasiados ciclos tecnológicos: Bitadir funcionaba sobre una combinación de PHP 4/5, plantillas antiguas, una capa de datos heredada, y un frontend que se había quedado clavado en el HTML de tablas. El sitio seguía operativo, sí, pero el coste invisible era alto: mantenimiento difícil, riesgo creciente protegido con capas de WAF y cada vez menos margen para adaptarlo a un entorno moderno sin que saltaran cosas por los aires.

La pregunta, por tanto, no era si merecía la pena tocarlo o simplemente cerrarlo para siempre. La pregunta real era cómo modernizarlo sin caer en el “lo reescribimos todo” que, en la práctica, suele convertirse en meses de trabajo, presupuestos disparados y un producto final que rara vez respeta todos los matices del original. La realidad es que tampoco tenía sentido porque no es un proyecto que genere ingresos, más bien solo pequeños gastos de hosting, pero de momento hay un tema de nostalgia y síndrome de Diógenes digital como con otras webs que conservo como Recursos Gratis (1995).

Lo que me encontré: deuda técnica, compatibilidad y seguridad “de otra era”

El diagnóstico inicial fue tan claro como incómodo:

• Código PHP con patrones obsoletos: uso de var, constructores con nombre de clase (estilo PHP 4), referencias & que en PHP moderno dejan de comportarse como se esperaba, y funciones directamente eliminadas o deprecadas (each(), create_function(), get_magic_quotes_gpc()).
• Acceso a la base de datos heredado, con puntos donde era necesario reforzar el escape de parámetros y reducir la superficie de ataque.
• Diseño anticuado: layout con tablas, sin diseño responsive real, tipografías rígidas y una experiencia móvil muy por debajo de lo que hoy se considera aceptable.
• El elefante en la habitación: contraseñas en MD5 sin salt, sin protección contra fuerza bruta, sin cabeceras de seguridad HTTP y formularios sin CSRF.
• De hecho, solo funcionaba en un servidor con PHP 5.4, realmente anticuado.

En un proyecto moderno, esto no pasa la revisión. En un proyecto con 29 años de historia, esto pasa… hasta que deja de pasar.

Un poco de contexto: qFramework, qDevel y la arquitectura original

Para entender por qué Bitadir “aguantó tanto”, hay que hablar del cimiento: qFramework.

qFramework fue un framework MVC para PHP, creado por Francesc Pla Prats y Carles Balaguer Lozano en qDevel (a inicios de 2000 o así). Ferca Networks (la parte de webs la gestiona hoy Color Vivo) contó con los servicios de qDevel para ese desarrollo. Y aquí hay un matiz importante: esa base no era un “código improvisado”, sino una arquitectura con ideas que, bien reinterpretadas, siguen teniendo sentido hoy:

• MVC con Front Controller
• Sistema de filtros (cadena de responsabilidad)
• Capa DAO para datos
• Integración con Smarty para templates
• Validaciones, usuarios y permisos
• Licencia GPL v2
• Versión documentada: 0,9b

Además, se notaban influencias de la cultura PHP de aquella época, incluyendo plataformas de blogging como pLog (más tarde LifeType), muy presentes en la comunidad hispanohablante entre 2003 y 2010.

¿Conclusión? No se trataba de “conservar lo viejo” solo por nostalgia. Se trataba de aprovechar lo rescatable (la separación de capas y el flujo MVC) y refactorizar con criterio todo lo que estaba desfasado o representaba un riesgo.

La estrategia: modernizar por capas, con seguridad primero y sin dramas

La hoja de ruta fue deliberadamente práctica:

1. Compatibilidad completa con PHP 8.4: primero el framework y luego la aplicación.
2. Seguridad como prioridad: hashing moderno, limitación de tasas, cabeceras HTTP, cookies y HTTPS.
3. Rediseño visual completo, pero sin meter frameworks pesados: CSS moderno, componentes, responsive.
4. Arreglo de errores históricos que afectaban la navegación y la administración.
5. Rendimiento con un sistema de caché híbrido y limpieza automática.

Elegí PHP 8.4 porque sitúa al proyecto en una rama moderna con un horizonte de soporte claro: según el calendario oficial de PHP, 8.4 mantiene soporte activo hasta el 31 de diciembre de 2026 y soporte de seguridad hasta el 31 de diciembre de 2028.

1) Refactorización a PHP 8.4: lo “invisible” que lo cambia todo

El trabajo más delicado fue actualizar el framework y la base de la aplicación archivo por archivo. En términos prácticos, significó:

• Reescribir patrones de clases antiguos (visibilidad, constructores, retornos y referencias).
• Eliminar dependencias de funciones que ya no existen o que no se recomiendan.
• Hacer que el core del proyecto volviera a ser predecible en un entorno de ejecución moderno.

En la capa de datos se reforzó la compatibilidad adoptando una abstracción actualizada basada en ADOdb para PHP 8.4, y se mejoró el escape de parámetros donde correspondía, dejando el camino preparado para un siguiente salto más contundente a PDO / prepared statements.

2) Seguridad: de “esto aguanta” a “esto se puede operar”

Aquí hubo dos cambios que, por sí solos, justifican el proyecto.

Contraseñas: de MD5 sin salt a bcrypt (sin resetear cuentas)

Se implementó una clase qPassword que usa bcrypt con coste 12, y lo hace con migración transparente:

• Si el hash ya es bcrypt, la verificación es estándar.
• Si el hash es MD5, se valida y, en ese mismo login, se rehash a bcrypt y se actualiza en la base de datos.

Resultado: se mejora la seguridad sin comprometer el acceso de los usuarios existentes. Que posiblemente ni siquiera entraban al panel de gestión. Una tarea pendiente es forzar el reinicio de contraseñas si vuelven a intentar acceder.

Fuerza bruta: rate limiting real

Se añadió qRateLimiter Para endpoints críticos (login, admin login, recuperación de contraseña y registro), con un esquema por defecto de 5 intentos en una ventana de 15 minutos y bloqueo de 30 minutos al exceder el límite.

A esto se sumaron cabeceras HTTP de seguridad, HTTPS forzado y cookies de sesión con flags HttpOnly y Secure, además de una CSP razonable.

3) Rediseño completo: del HTML con tablas a una UI moderna y responsive

Aquí no hubo “maquillaje”. Se pasó a un CSS nuevo (modern.css) con:

• Variables CSS (custom properties) para mantener colores, sombras y radios con coherencia.
• Tipografía moderna y jerarquía visual más clara.
• Layout con Grid/Flexbox y enfoque mobile-first.
• Componentes reutilizables: cards, botones con estados, mensajes de error y de éxito y badges de estado para el admin.
• Sustitución de iconos antiguos por soluciones CSS cuando tenía sentido.

También se mejoró la navegación: menú responsive con toggle, indicador de sección activa, breadcrumbs y URLs más limpias con rewrite rules por temas de SEO, algo que hasta ahora se había pasado por alto.

4) Rendimiento: caché híbrida y cron con limpieza automática

Se implementó una caché híbrida:

• Redis si está disponible (memoria y velocidad),
• caché en archivos como fallback (siempre disponible),
• TTL típico de 24 horas para categorías, noticias, blogs recientes y conteos.

Además, el cron de RSS limpia las cachés al actualizar los feeds y purga las entradas expiradas.

Los bugs “de verdad”: lo que se notaba en el día a día

Parte del éxito de modernizar un legacy es arreglar lo que se había normalizado como “cosas que pasan”:

• Pérdida de parámetros en la paginación por falta de QSA en las reglas de rewrite.
• Redirecciones con doble barra (//login) por construcción defectuosa de URLs.
• Login público que rechazaba a los administradores por un filtro de rol demasiado rígido.
• Páginas del admin que mostraban datos incorrectos debido a errores históricos de copiar y pegar.
• Menús duplicados en administración debido a includes repetidos.
• Listados que no mostraban datos debido a includes faltantes en las clases DAO.
• Sin olvidar problemas realmente graves, como inyecciones SQL, errores potenciales de código, vulnerabilidades en PHPmailer muy antiguo, etc. Que, por suerte, el WAF funcionaba bastante bien.

Son detalles que no se ven en una captura bonita, pero que determinan si un sistema se mantiene con calma o con dolor.

Métricas y resultados: lo que cambió después

En métricas internas del propio proyecto, el salto quedó reflejado así (valores aproximados):

• Lighthouse Performance: ~40 → ~85
• Lighthouse Accessibility: ~50 → ~90
• Tiempo de carga: ~3 s → ~1 s
• Responsive: No → Sí
• Seguridad de contraseñas: MD5 → bcrypt (cost 12)
• Fuerza bruta: Ninguna → rate limiting + bloqueo temporal

Tiempo, tokens y coste: el ejemplo más claro de por qué conviene adaptarse

Una de las cosas que más me interesan de esta modernización es lo que representa como lección: usar la tecnología para ser más eficiente no es una amenaza; es supervivencia operativa.

El trabajo real se midió en torno a:

• ~8 horas en total (en sesiones),
• 62 archivos modificados,
• ~4.800 líneas actualizadas,
• 780 líneas de CSS nuevo,
• ~600.000 tokens consumidos en sesiones con Claude Opus 4.5.

A partir de ahí, la comparación con “el mercado” es bastante intuitiva (e igual poco realista e injusta):

• Reescritura completa típica: 10.000 € – 20.000 € y 2–4 meses (estimación del propio documento del proyecto).
• Migración manual tradicional: 5.000 € – 10.000 € y 1–2 meses.
• Modernización asistida por IA: coste de tokens + validación humana + ejecución técnica, pero en una escala completamente distinta.

Para hacerse una idea de la magnitud del coste de tokens, Anthropic indica que el precio de Claude Opus 4.5 “empieza” en 5 $ por millón de tokens de entrada y 25 $ por millón de tokens de salida.
Con un consumo de este tamaño, el coste directo de modelo se vuelve una partida asumible frente a semanas de desarrollo, y lo importante pasa a ser otra cosa: saber qué tocar, validar bien, y no confundir velocidad con falta de rigor.

Ese, para mí, es el mensaje de fondo: en 2026, resistirse a estas herramientas por miedo es como rechazar el control de versiones porque “antes se trabajaba con FTP”. No se trata de sustituir el criterio técnico; se trata de multiplicar la productividad con cabeza.

Preguntas frecuentes

¿Qué es lo más difícil al migrar una aplicación de PHP 4/5 a PHP 8.4 sin reescritura completa?
Identificar incompatibilidades ocultas (constructores antiguos, referencias &, funciones eliminadas), refactorizar sin romper flujos y validar regresiones en rutas y panel de administración.

¿Cómo se puede migrar de contraseñas MD5 a bcrypt sin obligar a un reseteo masivo?
Con migración transparente en login: se valida el hash legacy y, si es correcto, se recalcula con bcrypt y se actualiza en la base de datos en ese momento.

¿Qué medidas mínimas debería tener un login moderno en una web legacy modernizada?
Hashing robusto (bcrypt/argon2), rate limiting con bloqueos, HTTPS forzado, cookies HttpOnly/Secure, y cabeceras básicas (anti-clickjacking, nosniff, referrer policy y CSP si aplica).

¿De verdad compensa usar IA para modernizar un sistema legacy?
Sí, si se usa como acelerador y no como “piloto automático”, reduce tiempos de refactorización y permite abordar más superficie de código, pero exige validación, pruebas y criterio técnico en cada cambio.

Fuente: Documento interno del proyecto “Bitadir.com – Caso de Éxito: Modernización de una Aplicación Web Legacy” (febrero de 2026)

La entrada Cómo modernicé Bitadir.com: de PHP 4/5 a PHP 8.4 sin reescribirlo desde cero (y por qué merecía la pena) aparece primero en Carrero.

Hace unos días leí un comentario de David Bonilla en X que me pareció una alerta muy bien formulada: la Inteligencia Artificial está “laminando” la creatividad en los mails porque muchos equipos temen que el contenido sea malinterpretado y, por tanto, los resúmenes no solicitados que muestra el cliente en el correo acaben deformando el mensaje. En otras palabras: no es que alguien te prohíba escribir con personalidad; es que empiezas a autocensurarte para no “romper” la lectura que haga la IA.

El tema no es menor, porque el email —para marcas, medios, comercios y creadores— sigue siendo uno de los canales con mayor retorno, mayor control e independencia frente a los algoritmos sociales. Y precisamente por eso preocupa: si el email se convierte en un espacio en el que el intermediario editorializa, estamos ante una mutación del canal.

Esta reflexión conecta con un análisis del sector que me parece especialmente útil: el texto de Zeta Global sobre lo que llaman la Séptima Edad de la entregabilidad. La idea central es que entramos en una etapa donde los remitentes pierden parte del “prime real estate” del inbox: asunto, texto de previsualización, incluso el espacio visible tras abrir el mensaje. Ese terreno, en muchos casos, lo ocupa ahora una capa de resúmenes generados por IA.

De la entregabilidad técnica a la entregabilidad “interpretada”

Durante años, el juego del email fue relativamente claro:

• Al principio, casi no había reglas.
• Luego llegaron las listas negras y los filtros por palabras clave.
• Después, el botón de “Reportar spam” y la disciplina impuesta por las quejas.
• Más tarde, el gran giro: ya no bastaba con no molestar; había que generar señales positivas de engagement.
• Con el tiempo, la reputación dejó de ser solo una cuestión de IP: el dominio se convirtió en tu historial permanente.
• Y después, el golpe de la privacidad (por ejemplo, con protecciones que reducían la visibilidad de las aperturas), que obligó a cambiar las métricas, la segmentación y la forma de medir.

Hasta aquí, aunque complejo, todo pertenecía al terreno del “delivery”: llegar a la bandeja de entrada y lograr la interacción.

Lo nuevo, sin embargo, va más allá. Ahora hablamos de cómo se presenta y se resume el email dentro del propio cliente, incluso cuando llega correctamente.

Y eso introduce un concepto casi incómodo: la entregabilidad ya no es solo técnica; también se vuelve editorial.

El “prime real estate” que está en disputa

Quien lleva tiempo trabajando campañas de email lo sabe: hay tres zonas críticas que deciden el destino de un mensaje en segundos:

1. Asunto
2. Preheader / texto de vista previa
3. Primer pantallazo al abrir (lo que se ve sin hacer scroll)

La Séptima Edad que describe Zeta Global sugiere que estas zonas se están erosionando porque:

• En algunos escenarios, el preheader puede sustituirse por resúmenes de oferta, elementos visuales o interpretaciones automáticas.
• Se introducen tarjetas o módulos que sintetizan el email y desplazan contenido real de la marca fuera de la zona visible.
• Se aplican agrupaciones por marca que reducen la visibilidad de múltiples asuntos (solo aparecen unos pocos), lo que obliga a competir con menos “impactos” reales.

El resultado práctico: la marca puede escribir un texto, pero el usuario puede ver otro (un resumen o una extracción). Y cuando eso ocurre, la creatividad deja de ser solo un recurso de comunicación; se convierte también en una variable de riesgo.

Por qué la creatividad empieza a “perder” (y no por falta de talento)

Aquí está la clave del comentario de Bonilla: la creatividad en emails suele apoyarse en recursos como:

• metáforas
• ironía
• doble sentido
• juegos de palabras
• sorpresa
• “punchline” en el preheader

Todo eso funciona cuando una persona lee el mensaje tal cual lo has escrito. Pero si una inteligencia artificial se dedica a resumirlo o a extraer “lo importante”, se abren varios escenarios problemáticos:

• La ironía se vuelve literal y el resumen cambia de tono.
• Una frase sugerente se convierte en una promesa comercial.
• Un guiño cultural se interpreta como algo irrelevante y se elimina.
• El “gancho” del preheader desaparece porque el sistema lo reemplaza por un resumen frío.

Esto genera un incentivo perverso: escribir “más plano”, más literal, más directo. No porque sea mejor comunicación, sino porque es más robusto frente a interpretaciones automáticas.

Y aquí hay una analogía evidente con lo que pasó en SEO: durante años, el miedo a no posicionar impulsó a usar títulos más previsibles. Ahora, el miedo a ser mal resumido impulsa emails más previsibles.

El bucle de métricas: cuando el proveedor mide su propia IA

Hay otro matiz importante: si los resúmenes o tarjetas cambian la experiencia del usuario, pueden afectar a:

• aperturas
• clics
• bajas
• quejas (“esto no era lo que parecía”)
• tiempo de lectura (si el resumen ya “resuelve” la necesidad)

Lo paradójico es que los proveedores de correo podrían terminar midiendo el engagement y las quejas sobre una experiencia que ellos mismos han alterado con sus capas de IA. Esto complica el diagnóstico: cuando una campaña cae, ya no basta con preguntarse “¿qué he hecho mal?”; también hay que preguntarse: “¿Qué ha hecho el inbox con mi mensaje?”.

En 2026, monitorizar la entregabilidad también implica monitorizar la presentación.

Qué haría yo si dependiera del email para negocio o audiencia

No hay una receta mágica, pero sí un cambio de mentalidad. Algunas ideas prácticas (muy aplicables a ecommerce, SaaS, medios y newsletters):

1) Asuntos autosuficientes, sin depender del preheader

Durante años, era habitual construir una pareja: asunto que plantea algo + preheader que remata. Si se sustituye el preheader, el diseño se rompe.
El asunto tiene que sostener su valor por sí solo, con claridad.

2) Creatividad sí, pero con “anclas” semánticas

No se trata de renunciar al estilo. Se trata de evitar que el resumen cambie de significado.
Ejemplo (conceptual): si usas humor, añade una línea literal que deje claro el beneficio o la oferta real.

3) Lo más importante, arriba y sin ambigüedad

Si una tarjeta o un resumen va a extraer “highlights”, es mejor que esos highlights estén redactados con precisión en las primeras líneas.
Esto también mejora la accesibilidad, la lectura rápida y la experiencia móvil.

4) Menos figuración en elementos críticos

Puedes reservar metáforas para el cuerpo del mensaje, pero el núcleo (qué es, cuánto cuesta, qué cambia, por qué importa) debe ser directo.
La creatividad puede vivir en la forma, pero el contenido clave debe ser difícil de deformar.

5) QA de campañas como si fueran “renderizados”

Antes probábamos en clientes de correo (Gmail, Outlook, Apple Mail) para ver el layout. Ahora hay que incorporar otra pregunta:
¿Qué podría resumir una IA de esto y cómo podría equivocarse?

6) Monitorización por proveedor y por formato

Si notas caídas, intenta segmentar el análisis por proveedor (Gmail vs Apple Mail vs Yahoo) y por tipo de mensaje (promoción, editorial, transaccional).
A veces el problema no es el contenido, sino cómo se está “enmarcando”.

7) Prepararse para una conversación incómoda: el inbox como editor

A medio plazo, esto abre un debate sobre el poder: ¿hasta qué punto una plataforma puede reescribir la comunicación entre la marca y el usuario?
No hablo solo de marketing: hablo de avisos, cambios contractuales, comunicaciones importantes… El resumen automático no siempre es inocuo.

Lo que está en juego no es el marketing: es el control del significado

Si lo pensamos fríamente, el email siempre fue un canal con una promesa: si haces las cosas bien, llegas a tu audiencia con tu mensaje.

La Inteligencia Artificial en la bandeja de entrada introduce una capa nueva: puedes llegar… pero no necesariamente con tu mensaje tal como lo diseñaste.

Y eso tiene implicaciones culturales y económicas:

• Homogeneiza el lenguaje (menos riesgo, menos voz).
• Reduce la diferenciación (si todo debe ser claro y literal, todo suena parecido).
• Traslada el poder a quien “resume” (la interfaz).
• Y complica la atribución de resultados (si el resumen cambia, las métricas se ensucian).

Volviendo al punto inicial: el comentario de Bonilla no es una exageración. Es una descripción de incentivos. Y cuando los incentivos cambian, el contenido cambia.

Preguntas frecuentes

¿Qué significa que la IA “lamina” la creatividad en el email marketing?
Que muchos equipos tienden a redactar mensajes más literales y menos figurativos para reducir el riesgo de que los resúmenes automáticos malinterpreten el contenido y alteren la percepción del usuario.

¿Cómo afectan los resúmenes generados por inteligencia artificial a la entrega de un dominio?
Indirectamente: si el resumen confunde, puede reducir el engagement y aumentar las quejas o las bajas. Eso deteriora las señales de reputación que influyen en futuros envíos, aunque el email haya llegado correctamente al inbox.

¿Qué buenas prácticas ayudan a que un email no sea mal resumido por la IA?
Asuntos autosuficientes, primeras líneas claras, beneficios y condiciones sin ambigüedad, y un diseño donde lo esencial esté arriba. La creatividad puede mantenerse, pero con “anclas” semánticas.

¿Deberían las marcas “probar” cómo se ve un email con resúmenes automáticos?
Sí, en la medida de lo posible. Igual que se testea el renderizado en distintos clientes, conviene revisar cómo los proveedores presentan y extraen elementos, y monitorizar cambios por proveedor cuando cambian las métricas.

Fuentes:

• Publicación de David Bonilla en X (enero de 2026).
• Zeta Global: “The Seventh Age of Email Deliverability”, Amber Erickson.
• Noticias De Inteligencia Artificial.

La entrada Cuando la bandeja de entrada reescribe tu email: la Inteligencia Artificial y la nueva era de la “entregabilidad editorial” aparece primero en Carrero.

Estos días he vuelto a leer varias declaraciones de Tim Cook sobre lo que Steve Jobs le fue dejando como aprendizaje (en entrevistas y perfiles en los que Cook habla de su relación profesional con Jobs y de cómo le marcó como líder). Y me ha pasado lo mismo que cuando encuentras una frase que no te deja escapar: sigues con tu día, pero la cabeza se queda rumiando.

Porque no son frases para un póster. Son lecciones de gestión. De las que, si estás liderando un proyecto, te obligan a mirarte al espejo.

1) Foco de verdad: hacer menos, pero hacerlo mejor

Lo primero que asocio a Jobs no es “hacer mucho”. Es recortar. Es el músculo para decir “no” sin que te tiemble el pulso.

Cook lo ha descrito de una forma muy simple: Jobs estaba obsesionado con el producto, con el producto y con el producto. Y esa obsesión, bien entendida, no es romanticismo creativo: es estrategia.

En cualquier empresa (da igual si vendes software, servicios o tornillos), el enemigo número uno suele ser el mismo: el catálogo infinito. La lista de “por si acaso”. La pila de funcionalidades que nadie pidió, pero que alguien dentro defendió con pasión.

Jobs puso el foco en la disciplina. Y esa disciplina suele doler, porque implica renunciar a cosas que podrían funcionar… para proteger las que deben funcionar.

2) Equipos pequeños: menos ruido, más responsabilidad

La segunda idea es casi contraintuitiva en 2026, cuando todo parece escalarse con más gente, más comités y más capas. Jobs confiaba en equipos reducidos capaces de lograr cosas enormes.

Un equipo pequeño no es una cuestión de presupuesto. Es una cuestión de fricción:

• Menos intermediarios.
• Menos “me lo apunto y lo vemos”.
• Más decisiones claras.
• Más propiedad real del resultado.

En mi experiencia, cuando un equipo crece, si no proteges la claridad, empiezas a pagar un “impuesto invisible”: reuniones, sincronizaciones, dependencias, política interna. Y de repente lo urgente se come lo importante.

Lo pequeño te obliga a priorizar. Y la prioridad, al final, es la forma adulta de decir “no”.

3) Rodéate de talento que te incomode (y que te discuta con argumentos)

Otra de las ideas que Cook repite al hablar de Jobs es la obsesión por rodearse de gente brillante: no para que te aplauden, sino para que te mejoren.

Esto también es incómodo porque toca el ego. Tener cerca a alguien que sabe más que tú en un área crítica te pone en tu sitio. Te obliga a escuchar de verdad. Y a separar dos cosas que muchos líderes mezclan:

• “Que me discutan” no es falta de alineación.
• “Que me discutan bien” es señal de salud.

Un equipo que solo dice que sí, tarde o temprano fabrica una burbuja. Y cuando la realidad pincha esa burbuja, ya es tarde.

4) No te cases con tus ideas: cambiar rápido es madurez

Esta lección, para mí, es la más brutal.

Cook ha contado que Jobs le enseñó a no quedarse “casado” con sus opiniones pasadas, a no ser tan orgulloso como para no cambiar de idea cuando aparece nueva evidencia.

Esto es oro puro para cualquiera que esté construyendo algo:

• Hay decisiones que se convierten en identidad (“yo soy el que apostó por esto”).
• Hay planes que se convierten en religión (“si cambiamos, es que fallamos”).
• Hay roadmaps que se mantienen a pesar de que el mercado haya cambiado.

Y ahí mueren proyectos prometedores: no por falta de visión, sino por exceso de apego. Confunden coherencia con rigidez.

La coherencia de verdad no consiste en repetir siempre lo mismo. Es ser fiel al objetivo, aunque tengas que cambiar de camino.

5) Innovación constante: no como palabra, sino como obligación operativa

Cook también ha explicado que Jobs le enseñó el valor de la innovación y que la creatividad no debía “vivir” en un solo departamento: tenía que estar en toda la empresa, incluso en operaciones.

Esta parte me gusta especialmente porque pone la innovación en la práctica. Innovar no es solo sacar un producto nuevo. Es mejorar cómo despliegas, cómo atiendes, cómo reduces la fricción, cómo automatizas, cómo haces que lo complejo sea simple.

La innovación no es un evento. Es una práctica.

Y aquí viene la ironía que más me ronda desde que leí todo esto: cuanto más grande se vuelve tu proyecto, más necesitas pensar como si estuvieras empezando. Como si aún tuvieras que ganarte el derecho a existir cada semana.

Porque el mundo no te “respeta” por tu tamaño. Te respeta por tu capacidad para seguir siendo relevante.

Yo me quedo con una pregunta que sirve para cualquier founder, CTO o CEO:
¿Qué parte de tu proyecto estás manteniendo por orgullo, cuando ya tienes evidencia suficiente de que deberías simplificar, recortar o cambiar?

¿Y a ti qué lección te ha tocado más?

Preguntas frecuentes

¿Qué lecciones de liderazgo dijo Tim Cook que aprendió de Steve Jobs?
En distintas entrevistas y perfiles, Cook ha destacado ideas como el foco en el producto, el valor de la innovación, la importancia de equipos pequeños, rodearse de gente excelente y la capacidad de cambiar de opinión ante nueva evidencia.

¿Por qué Steve Jobs insistía tanto en el foco y en decir “no”?
Porque para Jobs, priorizar era una forma de proteger la simplicidad y concentrar los recursos en lo esencial. Se le atribuyen reflexiones conocidas, como que el foco implica renunciar a muchas cosas para acertar en pocas.

¿De verdad funcionan mejor los equipos pequeños en tecnología?
Suelen funcionar muy bien para la iteración rápida, la claridad y la responsabilidad. El reto es mantener la coordinación cuando el producto y la empresa crecen, sin caer en exceso de capas ni en burocracia.

¿Cómo aplicar “no te cases con tus ideas” en un proyecto real?
Con métricas claras, ciclos cortos de revisión, y una cultura donde cambiar de rumbo por datos no se viva como derrota, sino como madurez operativa.

La entrada Tim Cook y las últimas lecciones de Steve Jobs: foco, equipos pequeños y el arte de cambiar a tiempo aparece primero en Carrero.

Por eso me llamó la atención la historia de Jeff Huang, que se hizo relativamente conocida por algo tan simple como efectivo: su “app de productividad” es un archivo .txt infinito. Un documento de texto sin fin donde, cada día, vuelca lo que tiene por delante y que, con el tiempo, se convierte en un registro de lo que ha hecho, de con quién se ha reunido, de ideas, decisiones y tareas.

Y lo interesante no es si su método es “el mejor”. Lo interesante es lo que hay detrás: buscar un sistema que no te estorbe y que te resulte cómodo y práctico.

Cuando el sistema te roba más tiempo que el trabajo

A mí me pasa como a mucha gente: he probado herramientas, métodos, listas, recordatorios… y siempre llega un momento en el que el propio sistema empieza a pedirte mantenimiento. Ajustar vistas, mover tareas, reordenar etiquetas, decidir si algo es “tarea”, “nota”, “proyecto” o “subproyecto”… y de pronto te descubres organizando en lugar de hacer.

Ahí es donde el enfoque de Jeff Huang me parece útil como idea general: reducir la fricción. Quitar capas. Volver a lo básico.

Cada uno encuentra su forma (y la mía es bastante simple)

En mi caso, no he terminado con un .txt como él, pero sí con algo parecido en filosofía: capturar ideas y notas rápido, sin rituales.

Y aquí lo digo tal cual: para eso, uso la app de Notas de Apple.

No porque sea la más completa del mundo, ni porque sea “la herramienta pro”, ni porque tenga la mejor IA del mercado. La uso porque cumple lo que para mí es lo más importante:

• Abrir y escribir en segundos (sin pensar). Desde el móvil, el portátil o el equipo de sobremesa de la oficina.
• Guardar ideas al vuelo, sin una estructura rígida.
• Tener un sitio para notas rápidas, borradores, listas y recordatorios mentales.
• Poder volver a ellas después para convertirlas en algo útil (un artículo, una decisión, una tarea real).

Mis “ideas” y notas son básicamente mi bandeja de entrada mental. Si se me ocurre algo, si detecto un tema interesante, si apunto un enfoque para un post, si quiero anotar una frase, un concepto o una estructura… va ahí. Sin pelearme con el formato. Aunque la idea de Jeff de utilizar el formato de texto como algo mucho más estándar me llama la atención, con Notas estoy atado a Apple.

La clave no es la herramienta: es el hábito de capturar

Lo que me gusta del método de Jeff Huang (y lo que intento aplicar a mi manera) es esta idea: no necesitas un sistema perfecto, sino uno que uses de verdad cada día, sin peros.

Porque el mayor enemigo de la eficiencia no es la falta de apps. Es esto:

• confiar en “me acordaré luego” (spoiler: no),
• dejar ideas sueltas en chats, correos, pestañas, capturas,
• O apuntar cosas en diez sitios distintos y luego no encontrarlas nunca.

Con las Notas de Apple intento evitar justo eso: que las ideas se pierdan. Que la chispa se apague por no haberla escrito.

Seguimiento: de nota rápida a idea que madura

Una nota rápida no es un proyecto. Pero puede ser el germen.

Mi flujo suele ser algo así:

1. Captura inmediata: escribo lo justo para no olvidarlo.
2. Acumulo sin culpa: no todo tiene que convertirse en algo.
3. Reviso cuando toca y como un hábito real, y algunas notas “piden” salir, porque conectan con un artículo, una necesidad, un cliente, una noticia o una reflexión.
4. Convierto lo útil en acción: lo que merece la pena se transforma en contenido, tareas o decisiones.

Y lo demás… se queda ahí. No pasa nada. La productividad real también implica aceptar que no todo lo que piensas tiene que ejecutarse.

Lo importante: un sistema que te deje pensar

Al final, para mí la eficiencia va de esto:

• quitar ruido,
• reducir la carga mental,
• Y dejar espacio para lo que de verdad importa: pensar, crear, resolver.

El archivo .txt de Jeff Huang me parece un gran recordatorio de que lo simple puede escalar sorprendentemente bien. Y mi sistema con Notas de Apple es mi versión de lo mismo: un sitio rápido, accesible y sin fricción para capturar lo que pasa por la cabeza antes de que desaparezca.

Porque al final, cada uno busca “la mejor forma” de ser eficiente y tener hábitos reales… y casi siempre la mejor forma es la que te resulta tan fácil que no puedes poner excusas para no usarla.

La entrada Mi “sistema de productividad” no es perfecto (y justo por eso funciona) aparece primero en Carrero.

Suena bien… hasta que empiezas a fijarte en los detalles:
Series que desaparecen de un día para otro, discos que se sustituyen por una versión distinta, películas que “habías comprado”, música que deja de estar disponible, que sí, y que de repente ya no están en tu biblioteca. Aplicaciones que desaparecen o dejan de tener soporte para tu sistema operativo y no puedes volver a la versión de ayer que sí funcionaba, además de que te exigen tener Internet para verificar que pagas, y si no hay Internet, no funcionará.

Ahí es donde te das cuenta de algo bastante incómodo:

👉 En el mundo digital actual, casi nunca eres dueño de nada, solo alquilas acceso con muy buena puesta en escena.

En este artículo quiero contarlo en primera persona:
Cómo hemos pasado de “tenerlo todo” en nuestros discos duros a vivir en un gigantesco videoclub alquilado, con software SaaS en la nube, y cómo estoy intentando recuperar, poco a poco, parte de esa propiedad perdida.

Cuando internet era más feo… pero era más nuestro

Los que vivimos la primera gran oleada de internet en España recordamos bien aquella época:

• módem ruidoso para conectar a nuestra BBS favorita,
• conexiones lentas con módem de 28800 bps,
• páginas horribles, aunque bonitas para su época,
• Pero una sensación de libertad brutal.

Descargábamos música, películas, juegos, aplicaciones para Windows freeware, shareware, nuestro PhotoShop que pagábamos y usábamos durante años sin actualizar, distribuciones de Linux…

Algunas cosas eran legales, otras no tanto, pero había algo muy claro:
Lo que llegaba a tu disco duro era tuyo mientras quisieras conservarlo.

Podías:

• hacer una copia en un CD o tus disquetes,
• prestarlo a un amigo,
• guardarlo en un disco externo,
• Volver a escucharlo o instalarlo dentro de 10 años sin pedir permiso a nadie.

Era un caos, sí. No idealizo la piratería ni mucho menos.
Pero había algo que hoy echamos mucho de menos: el control.

Cuando trasteaba con la BBS y bajaba software durante horas, o compraba esos disquetes o distribuciones de CD o DVD cargadas de aplicaciones libres (freeware), shareware, open source y otras. Poco después montaba servidores Linux para servicios de hosting compartido, hacía páginas web «feas» como Recursos Gratis, la primera versión de Ferca Networks, y me conectaba a FTP con CuteFTP para Windows (comprado con su caja física y todo) o a los canales de IRC con mIRC. Éramos los patrones de nuestros barcos, instalábamos, descargábamos. Internet era el medio, no el lugar donde vivían tus cosas.

Con el tiempo, esa lógica se dio la vuelta.

La era del “todo está en la nube”… mientras dure

Llegaron las RDSI, el ADSL, la fibra óptica, los móviles inteligentes o smartphones (especialmente el iPhone), las Smart TV. Pero además los ordenadores de sobremesa evolucionaron y los portátiles también llegando a poder conectarnos desde cualquier lugar, hoy lo veis como alto normal pero en el año 2000 o aseguro que no lo era tanto. Aparecieron Netflix, Spotify, Steam, Kindle, las tiendas de apps, la suite de Adobe y Microsoft Office en pago mensual… y nos convencieron de que lo lógico no era guardar cosas, sino conectarse a ellas.

En vez de comprar un disco, pagas una suscripción.
En vez de guardar una película o serie, la “tienes” en tu plataforma.
En vez de almacenar tus libros, “compras” un archivo que solo existe dentro de la aplicación.
En ves de comprar tu aplicación, pagas por usarla y tener la última versión, pero si dejas de pagar ya puedes usarla, estamos en el punto de que muchas aplicaciones funcionan en la web y con conexión, no se instalan en tu ordenador.

La palabra clave aquí es “licencia”.

Hoy, cuando “compras” una película, un juego, una aplicación o un libro digital, la mayoría de las veces lo que compras es una licencia limitada a:

• una plataforma concreta,
• unas condiciones de uso,
• las decisiones de una empresa,
• Y el humor de varios departamentos legales.

Si mañana:

• Cambian los derechos,
• suben los precios (algo que empieza a pasar de forma habitual cada año),
• Cierran acuerdos con otra plataforma,
• O deciden limpiar el catálogo para ahorrar costes…

Esa película, disco de música, aplicación o libro digital que tú creías “tuya” desaparece. Y punto.

Lo he visto con:

• series que desaparecen de varias plataformas a la vez,
• juegos retirados de tiendas digitales,
• aplicaciones de todo tipo que desaparecen y no hay vuelta atrás,
• álbumes que se sustituyen por remasterizaciones que cambian temas, duración o mezcla,
• Libros que se “actualizan” sin que puedas recuperar la versión anterior.

Y entonces te das cuenta de la frase dura pero real:

Si no puedes tenerlo offline, abrirlo cuando te dé la gana y copiarlo a otro sitio, no es tuyo.

Es un alquiler muy bien empaquetado.

¿Qué significa “propiedad” digital en 2025?

Visto así, la pregunta importante es: ¿qué significa hoy ser dueño de algo digital?

Para mí, en 2025, ser dueño de un contenido digital implica cuatro cosas muy concretas:

1. Tener el fichero
   El archivo está en tu poder: en tu disco, tu NAS, tu servidor.
   Si mañana se cae internet, sigue ahí y tienes que poder seguir accediendo a él como prefieras.
2. En un formato abierto o documentado
   Que puedas reproducirlo o leerlo con distintos programas y sistemas dentro de 5, 10 o 20 años.
   Cuanto más estándar, mejor: MP3, FLAC, MP4, EPUB, PDF, ODF… Que aún tengo ficheros en algunas de las primeras versiones de CorelDraw que tardé mucho en recuperar, o ficheros comprimidos con Q que tuve la suerte de tener guardado el EXE de MS-DOS.
3. Sin depender de llaves que no controlas
   Si hay cifrado, tú controlas la clave. Si el acceso depende de un DRM que puede caducar o revocarse, no es propiedad, sino un alquiler.
4. En un sitio que tú controlas
   Puede ser un PC en casa, un NAS, un servidor de un proveedor en el que confías, o incluso un disco guardado en un cajón.
   Lo importante es que ningún cambio en las condiciones de un tercero pueda borrarlo de un plumazo.

Cuando una de estas patas falla, vuelves al modelo de “te dejamos usarlo mientras nos interese”.

Cómo empecé a recuperar parte del control

En mi caso no hubo un momento concreto de “revelación”. Fue más bien un goteo de pequeñas broncas con la realidad:

• Una serie desaparece justo a mitad de temporada,
• Una película que había “comprado” deja de estar disponible en esa plataforma,
• Un disco que llevaba años en una playlist es sustituido por otra versión,
• Pero especialmente los servicios que suben los precios o cambian las condiciones cada pocos meses.

Al final, como muchos, volví a algo que ya conocía bien: guardar mis cosas yo mismo.

No hablo de volver a los tiempos del todo pirata, sino de otra cosa:

• Comprar música en formato digital sin DRM siempre que sea posible, de hecho volvemos a tener colección de discos en CD en casa,
• hacer copias locales de fotos y vídeos familiares,
• descargar copias legales de contenidos que realmente valoro,
• buscar software que pueda comprar y usar siempre que quiera sin cuotas y sin necesidad de validar con Internet,
• Montar servidores propios para música, películas, documentos o notas (algo que ando experimentando poco a poco).

En mi caso, con mi deformación profesional, esto pasa por:

• tener un NAS,
• alguna máquina en casa,
• Y servidores en infraestructuras que conozco muy bien.

Pero no hace falta llegar a ese nivel.
Con un PC viejo, uno o dos discos externos y algo de paciencia se puede avanzar muchísimo. Y lo más importante siempre tener copias de seguridad, además de discos duros se puede volver a grabar cosas en formatos como el DVD que para algunas cosas sigue teniendo su gracia.

Autoalojar no es solo para frikis: es un seguro de memoria

Cuando se habla de autoalojar (self-hosting), mucha gente imagina armarios de racks, ruido de ventiladores y terminales llenos de comandos.
La realidad, para un usuario normal, puede ser mucho más sencilla:

Un esquema básico puede ser algo así:

• Organizar tu biblioteca
  Empezar por poner orden en las fotos, los vídeos, la música y los documentos.
  Nombrar bien los archivos, agruparlos por año, evento, proyecto…
• Tener al menos dos copias
  Una en tu equipo o en tu NAS, otra en un disco externo que no esté siempre conectado.
  Y si puedes, una tercera fuera de casa (otro domicilio o un almacenamiento cifrado en la nube).
• Usar herramientas sencillas para acceder a tu contenido
  • Un servidor de medios (Plex, Jellyfin, etc.)
  • Un sistema de notas o documentos (por ejemplo, Nextcloud, o simplemente carpetas sincronizadas)
  • Un visor de fotos autoalojado, si te animas.
• Pensar en local primero
  Que todo funcione aunque se vaya el internet.
  El acceso remoto vendrá después si lo necesitas.

¿Tiene trabajo? Sí.
¿Requiere aprender algunas cosas nuevas? También.
¿Merece la pena para lo que realmente te importa? Para mí, sin duda.

No todo hay que poseerlo: elegir qué conservar y qué alquilar

Tampoco se trata de obsesionarse y guardar absolutamente todo.

Yo lo estoy enfocando así:

• Propiedad total
  • fotos y vídeos familiares,
  • copias de seguridad de mis proyectos,
  • música o libros que para mí tienen valor especial,
  • Contenidos que he comprado sin DRM.
• Uso mixto (local + nube)
  • Documentos de trabajo,notas,material que necesito en varios dispositivos.Siempre en formatos abiertos y con copia local, aunque use sincronización. Por entrar en un detalle, no uso formatos de Google Docs, prefiero un ODT o un DOCX que contiene el dato y no un hipervínculo a los datos en la nube de Google.
• Alquiler consciente
  • series de moda,Películas
  que solo veré una vez,música que no quiero comprar pero si escuchar, aplicaciones
  • O juegos que sé que son temporales.
  Aquí acepto que es un alquiler y nada más. Lo disfruto y lo dejo ir.

La diferencia con el modelo actual es esta:
Antes confundía “lo tengo en la plataforma X” con “es mío”.
Ahora intento tener claro que, si no vive en mi infraestructura, no es realmente mío.

El precio de recuperar la propiedad (y por qué lo pago gustoso)

Ser dueño de algo en digital en 2025 tiene un precio:

• tiempo para organizar y aprender,
• dinero para algo de hardware,
• Disciplina para hacer copias de seguridad y revisarlas de vez en cuando.

A cambio, gano algo que cada vez valoro más:
La tranquilidad de saber que parte de mi vida digital no depende de una cláusula en una página web ni de los caprichos de una empresa.

No pretendo que todo el mundo se monte un minicentro de datos en casa.
Pero sí creo que, como usuarios, tenemos que dejar de creernos el cuento de que “comprar digital” es lo mismo que comprar en físico.

No lo es.

Y si queremos que parte de nuestra cultura, nuestras memorias y nuestro trabajo no se evaporen en el próximo cambio de catálogo, tendremos que volver, aunque sea un poco, a algo muy simple:

➡️ Guardar lo que nos importa, con nuestras propias manos, en sistemas que controlamos nosotros.

Al final, se trata de elegir qué quieres recordar

Cuando echo la vista atrás, veo claramente tres etapas:

1. La época en la que descargábamos todo y lo guardábamos todo, con sus luces y sus sombras, pero con una sensación clara de control.
2. La era dorada del streaming y las suscripciones, en la que nos creímos que el acceso lo solucionaba todo.
3. El momento actual, en el que empezamos a ver los límites de ese modelo y la necesidad de recuperar parte de la propiedad perdida.

No todo merece el esfuerzo de conservarlo.
Pero algunas cosas, sí.

Música, libros, películas, fotos, proyectos, recuerdos, algunas aplicaciones y juegos…
Si dentro de 10 o 20 años quiero seguir teniéndolos, sé que no puedo delegarlo todo en plataformas que cambian más rápido que mi memoria.

Por eso, poco a poco, estoy volviendo a algo muy básico:

• ficheros que controlo,
• formatos que entiendo,
• claves que no dependen de nadie,
• Servidores y discos que puedo tocar con la mano.

En un mundo donde casi todo es alquiler, elegir qué quieres poseer de verdad es casi un acto de rebeldía tranquila.
Y, al menos en mi caso, es una rebeldía que pienso seguir practicando.

Imagen de AI free images.

La entrada No eres dueño de casi nada digital (y cómo estoy recuperando parte de lo perdido) aparece primero en Carrero.

Hoy, cuando uno lee titulares sobre multimillonarios de Silicon Valley comprando enormes extensiones de tierra en California, impulsando proyectos urbanos propios en distintas partes del mundo o negociando regímenes especiales con pequeños Estados, la sensación es extraña: muchas de aquellas ideas que parecían teoría radical de los 90 empiezan a materializarse, aunque sea de forma imperfecta, desigual y a veces bastante cutre.

Este artículo no pretende ser un panfleto anti-tecnología (al contrario, vivo de ella y creo firmemente en su potencial), pero sí una reflexión personal sobre hacia dónde nos puede conducir ese sueño recurrente de algunos magnates: construir sus propias ciudades-Estado donde ellos fijan las reglas del juego.

De la ciudad-Estado medieval al “campus-Estado” tecnológico

La metáfora de los “señores feudales de Silicon Valley” no es casualidad. En la Edad Media, el poder real estaba fragmentado: pequeñas unidades políticas controladas por señores con su ejército, su castillo y sus normas. Los campesinos dependían de ellos para todo: seguridad, justicia, trabajo.

Hoy no hay castillos de piedra, pero sí campus vallados, grandes extensiones de terreno compradas discretamente y acuerdos con autoridades locales para crear zonas urbanas “modelos de innovación” con regulaciones a medida. No hace falta mucha imaginación para ver el paralelismo:

• Ellos controlan la infraestructura crítica: redes, nubes, plataformas, pagos, incluso identidad digital.
• Ellos marcan las condiciones de acceso: términos de uso, comisiones, algoritmos invisibles.
• Ellos sueñan con territorios físicos donde las reglas tradicionales se relajen: urbanismo, fiscalidad, derecho laboral, experimentación tecnológica.

Lo que cambia no es sólo el nivel tecnológico, sino también la ambición: ya no se trata simplemente de empresas influyentes, sino de actores privados que aspiran a tener su propio “espacio soberano” en el que el Estado pase a un segundo plano.

Lo que anunciaba El individuo soberano… y lo que no vio venir

Rees-Mogg y Davidson planteaban en su libro una tesis poderosa: al pasar de una sociedad industrial a una sociedad de la información, el capital intelectual y digital podría moverse por el mundo con mucha mayor facilidad que los Estados. Eso permitiría a las personas más ricas y conectadas “arbitrar” entre jurisdicciones, elegir dónde tributan, dónde viven y bajo qué normas operan.

Varias de sus predicciones han envejecido sorprendentemente bien:

• La deslocalización del capital y las empresas que “eligen” país como quien elige hosting.
• La pérdida de poder relativo de los Estados nacionales frente a los mercados globales, los grandes fondos y las corporaciones tecnológicas.
• El auge de los activos digitales y de los sistemas de pago alternativos, desde las criptomonedas hasta nuevas formas de mover dinero casi sin fricción entre países.

Pero quizás lo que el libro subestimó fue el grado de concentración de poder en unas pocas plataformas privadas. La visión era la de individuos más libres; la realidad, de momento, se parece más a una dependencia creciente de infraestructuras controladas por muy pocos actores.

En lugar de millones de individuos soberanos y plenamente empoderados, lo que se ve es la aparición de una especie de aristocracia digital con capacidad para negociar de igual a igual con los gobiernos… o incluso para intentar diseñar sus propias ciudades-Estado desde cero.

¿Qué prometen estas nuevas “ciudades privadas”?

Cuando se analiza el discurso de los impulsores de estas ciudades-Estado de inspiración tecnológica, suelen repetirse algunos argumentos:

• Innovación sin trabas: menos burocracia, menos normas “anticuadas”, más margen para experimentar con urbanismo, movilidad, IA, drones, biometría, etc.
• Fiscalidad “eficiente”: impuestos simples y bajos, a cambio de atraer talento global y capital a gran escala.
• Gobernanza algorítmica: desde las votaciones digitales hasta los contratos inteligentes, con la promesa de menos corrupción y más transparencia.
• Seguridad y calidad de vida: entornos supuestamente más seguros, limpios, sostenibles y orientados a una élite de profesionales globales.

Sobre el papel puede sonar atractivo, sobre todo si se compara con la lentitud y torpeza de muchas administraciones públicas. Pero detrás de esa narrativa hay preguntas incómodas:

• ¿Quién decide qué se puede experimentar y qué no?
• ¿Qué pasa con los derechos laborales, la protección social o el acceso a la vivienda?
• ¿Quién representa a quienes viven allí si no son accionistas ni fundadores?
• ¿Qué mecanismos hay para limitar los abusos de poder… cuando el poder no es un Estado, sino una empresa?

De utopía libertaria a desigualdad acelerada

Una de las ideas centrales de El individuo soberano es que quienes mejor naveguen la transición tecnológica podrán “desconectarse” parcialmente de las obligaciones de los Estados tradicionales. En la práctica, eso significa que los más ricos pueden vivir donde quieran, tributar donde les convenga y negociar condiciones especiales.

Las ciudades-Estado privadas o semiprivadas encajan en esa lógica:

• Territorios pensados para atraer a una minoría de alto poder adquisitivo, con servicios de primer nivel, un buen entorno regulatorio y una digitalización extrema.
• Entornos en los que los costes sociales (sanidad pública, educación universal, infraestructuras comunes) pueden quedar fuera del modelo… y seguir recayendo en los países “normales”.
• Una brecha creciente entre quienes viven dentro de esas burbujas hiperoptimizadas y quienes se quedan en ciudades y países que siguen sosteniendo el resto del sistema.

El riesgo es evidente: que la transición hacia una economía basada en la información no traiga sólo más eficiencia, sino también más fragmentación social y territorial, con feudos de alta tecnología rodeados de zonas que se quedan atrás.

¿Y Europa? ¿Y España? Soberanía digital frente a feudos privados

Desde la perspectiva europea, todo esto se cruza con un tema del que hablo mucho: la soberanía digital. Mientras algunos sueñan con ciudades privadas diseñadas desde Silicon Valley, la Unión Europea intenta construir un modelo en el que:

• La tecnología se integra con derechos fundamentales, como la privacidad o la protección de datos.
• Las grandes plataformas no puedan actuar como legisladores de facto sin ningún tipo de control democrático.
• La innovación conviva con normas claras en materia de competencia, fiscalidad y trabajo.

No es un camino perfecto ni rápido, y muchas veces la regulación llega tarde. Pero si Europa renuncia a dar esa batalla, el vacío lo llenarán otros con su propia visión: una mezcla de capital, algoritmos y territorios a medida, donde el voto pese menos que la participación accionarial.

En España, el debate todavía suena lejano cuando se habla de “ciudades-Estado tecnológicas”, pero no lo es tanto si se piensa en:

• Zonas económicas especiales o regímenes fiscales ultraflexibles para atraer grandes empresas.
• Ciudades que compiten por convertirse en hubs tecnológicos poniendo sobre la mesa suelo, infraestructuras y normativas flexibles.
• Dependencia creciente de nubes, chips y plataformas que no controlamos ni producimos aquí.

Si la única alternativa al Estado tradicional es el feudo privado, vamos mal. La respuesta debería pasar por fortalecer instituciones democráticas capaces de regular la tecnología, garantizar los derechos y, a la vez, permitir innovar sin convertir a los ciudadanos en meros “usuarios” de un sistema cerrado.

Una reflexión personal para cerrar

Cuando leí El individuo soberano, me impresionó la capacidad de sus autores para anticipar tendencias que hoy damos por hechas: la globalización del capital, la digitalización de casi todo, la erosión de ciertas formas de poder estatal. Pero también me llamó la atención algo que se ha confirmado con el tiempo: no existe la neutralidad en la tecnología.

Las ciudades-Estado imaginadas por la élite de Silicon Valley no son simples experimentos urbanísticos. Son propuestas de un nuevo contrato social, en las que muchas de las garantías que hoy damos por sentadas (desde la sanidad pública hasta la protección de datos) pasan a depender de decisiones privadas.

Como alguien que lleva toda la vida en Internet, que cree en el emprendimiento y que vive de la nube, no me considero tecnófobo ni mucho menos. Pero precisamente por eso me parece importante hacer estas preguntas incómodas ahora, y no cuando todas las piezas estén ya colocadas sobre el tablero.

Porque quizá la verdadera disyuntiva de las próximas décadas no será sólo entre Estados fuertes y Estados débiles, sino entre democracias capaces de gobernar la tecnología y feudos privados disfrazados de ciudades inteligentes.

Y ahí, cada ciudadano —cada “individuo soberano”, si se quiere mantener la expresión— tendrá que decidir de qué lado quiere vivir.

La entrada Los nuevos feudos de Silicon Valley y el eco inquietante de El individuo soberano aparece primero en Carrero.

Quién soy y por qué esta suspensión no tiene sentido

Me llamo David Carrero Fernández-Baillo. Soy cofundador y ejecutivo en Stackscale, una compañía europea de infraestructura cloud; además, participo como inversor en proyectos como Acumbamail, Genially, Mailtrack, Product Hackers y Color Vivo, entre otros.
Mi actividad pública es fácil de verificar:

• Web corporativa: https://www.stackscale.com
• Sobre Stackscale: https://www.stackscale.com/es/sobre-nosotros/
• Perfil profesional (LinkedIn): https://es.linkedin.com/in/dcarrero
• Entrevistas y presencia en medios:
  https://producthackers.com/es/podcast/episodio-19-infraestructura-cloud-david-carrero-stackscale/
  https://www.youtube.com/watch?v=NQZ7YfMA9Zk
  https://www.youtube.com/watch?v=YjY9ZrzjZ6I
  https://elreferente.es/emprendedores/david-carrero/?refrc=1
  https://www.youtube.com/watch?v=L08cx2kEuqM
  https://www.elconfidencial.com/tecnologia/2013-05-28/los-mayores-fracasos-de-los-emprendedores-digitales-espanoles_766882/

No he participado en actividades inauténticas ni en tácticas de manipulación para amplificar contenido. Cumplo las reglas y, si hubiese algún error por mi parte, necesito que me indiquen la publicación o la conducta exacta para corregirla de inmediato.

Qué pido a X

1. Revisión manual del expediente y restablecimiento de @carrero.
2. En caso de que exista un contenido cuestionado, identificación precisa del tuit/acción y la regla concreta aplicada.
3. Posibilidad de verificación reforzada: documentación oficial, selfie de verificación, dominio corporativo y comprobante de suscripción Premium.

No he creado ni crearé cuentas alternativas para sortear la suspensión. Quiero resolver esto correctamente.

Un problema mayor: spam descontrolado y falsos positivos

Más allá de mi caso, hay un tema de fondo que muchos usuarios perciben: la red está inundada de spam, respuestas basura, suplantaciones de identidad y estafas, mientras que cuentas reales —y a menudo pequeñas— se ven sujetas a suspensiones preventivas y a procesos de apelación opacos.
La lucha contra la inautenticidad es necesaria, pero no puede hacerse a costa de castigar a quienes dan la cara con nombre y apellidos. Si el sistema automatizado se equivoca, debe existir un debido proceso: una explicación clara, plazos razonables y la posibilidad real de aportar pruebas.

Por qué esto importa

Las plataformas sociales forman parte de la identidad digital de las personas y las empresas. Perder una cuenta legítima sin explicaciones concretas genera inseguridad jurídica, desincentiva la participación y daña la confianza. Si además pagas una suscripción que promete más herramientas y soporte, lo mínimo es esperar transparencia y un trato proporcional.

Lo que haré a continuación

• He presentado la apelación formal a X, solicitando una revisión manual.
• Mantendré informada a mi comunidad a través de cuentas corporativas, en especial a través de @colorvivo y de los canales de Stackscale.
• Cuando tenga una respuesta, la compartiré públicamente aquí para que sirva de referencia para otros usuarios en situaciones similares.

Si quieres ayudar, comparte este artículo. La visibilidad no sustituye el proceso, pero ayuda a que estos casos no pasen desapercibidos y a que las plataformas mejoren.

Cierre

Agradezco de antemano a quien corresponda en X la revisión de este caso. No pido un trato de favor: pido claridad, verificación y proporcionalidad. Si ha habido un error, que se corrija. Si no, que se explique qué norma y qué acción lo justifican.
Mientras tanto, seguiré trabajando —como siempre— para hacer de Internet un lugar más útil, seguro y confiable para empresas y usuarios.

Preguntas frecuentes (por si te sirve si estás en una situación parecida)

¿Qué significa “suspensión por inautenticidad” en X?
Suele activarse cuando sus sistemas detectan señales que interpretan como automatización, suplantación o manipulación coordinada. Son modelos estadísticos: útiles a gran escala, pero con riesgo de falsos positivos.

¿Qué incluir en una apelación?
Datos de identidad verificables (documentación, dominio corporativo, enlaces públicos), historial de uso y una petición explícita para que indiquen la publicación o comportamiento concreto y la regla aplicada.

¿Ser Premium evita estos problemas?
No. Puede facilitar la verificación, pero no sustituye una revisión humana ni garantiza que un algoritmo no señale la cuenta por error. Lo que sí debería garantizar es un canal de soporte más claro y ágil.

¿Qué buenas prácticas ayudan a no parecer “inauténtico”?
Evitar cambios bruscos y constantes de identidad, no usar automatismos opacos, cuidar el uso de acortadores y enlaces, activar 2FA, verificar el dominio propio y mantener una presencia pública coherente (web, LinkedIn, menciones en medios).

Nota: este post incluye una captura de pantalla con la notificación recibida desde X.

La entrada Mi cuenta @carrero ha sido suspendida por “inautenticidad”: lo que ha pasado y por qué pido una revisión en X aparece primero en Carrero.

A diferencia de métodos populares que tienden a “favoritismos” invisibles —por ejemplo, corredores demasiado rectos o sesgos hacia esquinas—, Wilson asegura que todas las configuraciones válidas para una cuadrícula dada tienen la misma probabilidad de aparecer. No hay trucos, no hay patrones repetidos: solo aleatoriedad uniforme sobre el conjunto de árboles generadores.

A continuación, una guía para entender qué lo hace especial, cómo funciona y por qué su influencia va más allá de los pasatiempos.

¿Qué significa “laberinto perfecto”?

En jerga de grafos, un laberinto perfecto es aquel que puede verse como un árbol de expansión (spanning tree) del grafo subyacente: hay exactamente un camino entre cualquier par de celdas. No hay ciclos (bucles) ni islas inaccesibles. Esta propiedad convierte al laberinto en un desafío “justo”: todo es alcanzable y no existen atajos redundantes que rompan el encanto del recorrido.

Generar árboles de expansión no es difícil; hacerlo de forma uniforme sí lo es. El algoritmo de Wilson aporta justamente eso: uniformidad. Cada árbol posible del grafo (piense en su cuadrícula) es equiprobable.

La idea clave: caminatas aleatorias con borrado de bucles

La técnica descansa sobre un objeto precioso de la probabilidad moderna: las caminatas aleatorias con borrado de bucles (loop-erased random walks, LERW). Imagine que recorre la cuadrícula al azar. Si alguna vez vuelve a pisar una celda que ya había visitado, habrá formado un bucle. El “truco Wilson” es borrar ese bucle por completo de la trayectoria —eliminando todos los pasos entre la primera y la segunda visita a la celda— y seguir caminando desde ahí. El resultado es una traza sin ciclos.

Con esa herramienta, el algoritmo se construye así:

1. Elija una celda semilla. En una cuadrícula vacía (todas las celdas “negras”), marque una al azar como parte del laberinto (ponga esa celda “blanca”). Es la primera pieza del árbol.
2. Arranque una caminata aleatoria desde otra celda. Tome al azar una celda negra y empiece a caminar al azar (arriba, abajo, izquierda, derecha). Mantenga un registro de su trayectoria. Si la caminata se cruza consigo misma, borre el bucle: retroceda en el registro hasta la primera aparición del cruce y elimine los pasos intermedios.
3. Conecte y consolide. Siga así hasta que la caminata toque alguna celda blanca (parte ya del laberinto). En ese instante, todos los pasos de la caminata (tras borrar bucles) se fijan: se vuelven “blancos” y se incorporan al laberinto.
4. Repita. Elija otra celda negra y repita el proceso. Cuando todas las celdas sean blancas, habrá construido un árbol de expansión de la cuadrícula: su laberinto perfecto.

La magia está en que, aunque la caminata individual es azarosa y local, el resultado global —al consolidar sucesivas LERW contra el árbol— reparte la probabilidad de forma uniforme sobre todos los árboles de expansión posibles del grafo. No hay configuraciones “privilegiadas”.

Por qué funciona (sin entrar en fórmulas)

Detrás del telón, el algoritmo se apoya en una conexión profunda entre LERW y los árboles generadores uniformes (uniform spanning trees, UST). Esa conexión, explorada en la década de 1990, garantiza que el procedimiento “semilla + LERW hasta el árbol” muestra exactamente la distribución uniforme de árboles. Traducción: si imagináramos todas las formas de tender caminos sin ciclos que conecten la cuadrícula completa, Wilson recorre ese catálogo sin favoritismos.

Un detalle operativo importante: el algoritmo solo fija un trayecto cuando toca el árbol ya construido. Antes de eso, la caminata es tentativa y borra cualquier bucle que aparezca. Esa disciplina evita que se formen ciclos y asegura que cada consolidación suma ramas al árbol sin cerrarlo sobre sí mismo.

¿Cómo se compara con otros generadores de laberintos?

• Búsqueda en profundidad (DFS) con retroceso: muy popular por su sencillez y velocidad. Produce laberintos perfectos, pero suele mostrar corredores largos y pocas bifurcaciones; es sesgado hacia ciertos patrones.
• Prim/Kruskal “aleatorizados”: variantes de estos clásicos para mínimos árboles de expansión también generan laberintos perfectos. En la práctica, si la aleatoriedad no se maneja con cuidado, suelen favorecer determinadas estructuras (por ejemplo, Prim tiende a “expander” desde una frontera, Kruskal a unir componentes dispersos).
• Aldous–Broder: otro algoritmo que utiliza caminatas aleatorias para obtener uniformidad. Es conceptualmente simple, pero menos eficiente: tarda más pasos en cubrir el grafo.
• Wilson: mantiene la uniformidad de Aldous–Broder con un comportamiento práctico muy competitivo gracias al borrado de bucles. En cuadrículas grandes ofrece tiempos esperados sólidos y escalables.

En resumen, si busca uniformidad garantizada, Wilson y Aldous–Broder son la elección. Entre ambos, Wilson suele ser la opción más eficiente para cuadrículas y grafos estructurados.

Implementarlo no es (tan) difícil: consejos prácticos

Aunque su sustento teórico es rico, implementarlo en código es asequible. Algunas pautas útiles:

• Estructuras de datos simples: mantenga un mapa de celdas “en el árbol” y una lista (o stack) para la caminata actual. Un diccionario que recuerde “desde dónde llegué a esta celda” ayuda a borrar bucles.
• Detección de bucles eficiente: use un hash (con las coordenadas de celda) para comprobar si la caminata ha visitado una celda antes. Si sí, borre desde la primera visita hasta la posición actual.
• Parada clara: la caminata se consolida cuando pisa cualquier celda del árbol. No necesita volver al origen.
• Selección aleatoria imparcial: en una cuadrícula 4-conexa (N, S, E, O), elija direcciones con probabilidad uniforme. Si algunas celdas están “bloqueadas”, descarte movimientos fuera de la cuadrícula.
• Visualización y depuración: dibujar el camino provisional en un color y el árbol en otro ayuda a comprobar que los bucles se borran y las ramas se fijan correctamente.
• Parámetros: el algoritmo generaliza a otras topologías: hexagonales, triangulares, grafos arbitrarios. Solo cambian los vecinos de cada nodo.

Un pseudocódigo compacto (a alto nivel):

árbol ← {celda_semilla}
mientras existan celdas fuera del árbol:
    c ← celda_aleatoria no en árbol
    camino ← [c]
    visitadas_en_camino ← {c}
    mientras c no esté en árbol:
        c' ← vecino_aleatorio_de(c)
        si c' ∈ visitadas_en_camino:
            borrar el lazo desde la primera aparición de c' en camino
        si no:
            añadir c' a camino y a visitadas_en_camino
        c ← c'
    añadir todas las aristas de camino al árbol

Más allá del pasatiempo: dónde se usa de verdad

• Videojuegos: generación procedural de mazmorras, niveles y mapas donde se necesita jugabilidad (todo conecta) y variedad sin patrones obvios.
• Simulaciones en física: percolación, difusión, campos aleatorios; los árboles uniformes y las LERW conectan con fenómenos que modelan cómo “avanza” algo en un medio.
• Ciencias de la computación: redes y ruteo; a veces se requiere muestrear árboles de expansión con distribuciones uniformes para evaluar algoritmos o robustez.
• Matemáticas: estudio de estructuras aleatorias en grafos, límites de LERW (relación con curvas SLE en planos continuos) y propiedades de árboles uniformes.

Velocidad, memoria y tamaño: preguntas que siempre aparecen

La complejidad exacta depende del grafo, pero en cuadrículas regulares el algoritmo se comporta muy bien en la práctica. Es lineal en el número de celdas “más un factor suave” asociado a las caminatas aleatorias y a los bucles que borra. Además, su consumo de memoria es moderado: basta con guardar el árbol construido y el camino activo.

Para tamaños “de pasatiempo” (por ejemplo, 50 × 50 o 100 × 100 celdas) la generación es instantánea en máquinas actuales. Para cuadrículas mucho mayores, conviene prestar atención a la calidad del generador aleatorio y a la eficiencia en la detección/borrado de bucles.

Variantes y extensiones: cuando el purista cede al diseñador

Wilson, en su forma canónica, asegura uniformidad. Pero en videojuegos o arte generativo puede interesar sesgar levemente el resultado:

• Pesos direccionales: dar más probabilidad a ciertas direcciones (corredores “ventilados”, estética concreta).
• Obstáculos: celdas prohibidas o “caros” que obliguen a la caminata a rodear.
• Semillas múltiples: arrancar con varias celdas “blancas” (árboles iniciales), aunque esto altera la distribución.

Cada cambio implica renunciar a la uniformidad estricta; pero también es cierto que controlar la mano del azar puede ser deseable en determinados contextos estéticos o de diseño de niveles.

Un poco de historia, y por qué no fue “el primero”

Antes de Wilson, Aldous–Broder (finales de los 80 / principios de los 90) ya ofrecía una receta para obtener árboles uniformes con una sola caminata aleatoria que cubre toda la cuadrícula. ¿La pega? Que, sin borrar bucles, la caminata puede perder muchísimo tiempo revisitando nodos ya incorporados, lo que lo hace ineficiente en muchos grafos prácticos.

Wilson tomó la idea del paseante y le añadió el borrado de bucles, que ahorra trabajo y guía la consolidación hacia el árbol en construcción. El resultado es uniformidad con un rendimiento mucho más atractivo para cuadrículas y grafos “de la vida real”.

Una puerta de entrada a la aleatoriedad bien domada

En el algoritmo de Wilson conviven dos fuerzas que rara vez se llevan bien: la aleatoriedad pura y la estructura. La primera garantiza que no hay “maña” escondida; la segunda asegura que del caos no sale un amasijo de paredes, sino un laberinto perfecto, con un único camino entre cualquier dos puntos.

Esa alianza lo convierte en un ejemplo canónico de cómo las matemáticas no solo describen el azar: también lo canalizan para construir objetos útiles y bellos.

Preguntas frecuentes (FAQ)

¿Cómo implementar el algoritmo de Wilson en Python paso a paso?
A alto nivel, basta con: 1) representar la cuadrícula y sus vecinos; 2) elegir una semilla y marcarla en el árbol; 3) repetir: seleccionar una celda fuera del árbol, lanzar una caminata aleatoria con borrado de bucles hasta tocar el árbol, y consolidar esa traza; 4) terminar cuando todas las celdas estén en el árbol. Use un set para detectar visitas y una lista para el camino. Para visualizar, dibuje muros eliminando los que atraviesa el árbol.

¿En qué se diferencia Wilson de Prim/Kruskal para generar laberintos perfectos?
Prim/Kruskal “aleatorizados” también generan laberintos perfectos, pero su distribución no es uniformemente aleatoria a menos que se controlen muchos detalles. Suelen mostrar sesgos de estructura. Wilson (como Aldous–Broder) sí garantiza uniformidad sobre los árboles de expansión, con un rendimiento práctico mejor en cuadrículas gracias al borrado de bucles.

¿Por qué el algoritmo de Wilson produce laberintos “verdaderamente aleatorios”?
Porque su mecánica (caminatas con borrado de bucles que se consolidan al tocar el árbol) está demostrada para muestrear árboles de expansión con distribución uniforme. En una cuadrícula dada, cada árbol posible tiene la misma probabilidad de aparecer.

¿Dónde se usa el algoritmo de Wilson en videojuegos y generación procedural?
En mazmorras y mapas donde se busca que todo conecte (sin zonas muertas) y que las partidas no repitan patrones. Wilson es ideal para roguelikes, puzles, niveles con exploración, e incluso para distribuir habitaciones o pasillos con garantía de accesibilidad y variedad sin sesgos.

Si alguna vez se pierde entre paredes de papel, quizá haya detrás un caminante aleatorio borrando bucles con precisión quirúrgica. Y si le apetece construir sus propios laberintos, Wilson ofrece una puerta de entrada perfecta: pocas líneas de código, mucha teoría debajo y resultados impecables.

Idea sacada del artículo de Cruz Dogar

La entrada El algoritmo de Wilson: la receta matemática que fabrica laberintos “perfectos” sin sesgos aparece primero en Carrero.

Traducción libre: de un día para otro, he dejado de existir para la red social en la que llevo casi 20 años. La causa: un videoselfie para confirmar que soy humano. La consecuencia: bloqueo total de mi perfil y, con él, el acceso a páginas de proyectos, páginas de empresas, Business Manager y campañas. Y, por supuesto, cero margen de maniobra mientras “revisan” si sigo siendo yo.

La escena es absurda si uno piensa en la selva de bots y cuentas falsas que campan a sus anchas en la plataforma. Pero es también sintomática de algo más incómodo: el internet que estamos tolerando es uno en el que una sola empresa puede suspender tu identidad digital y tu actividad profesional por un algoritmo opaco, sin garantías ni contrapesos.

La paradoja del “verifica que eres humano”

Que una plataforma pida verificaciones puntuales tiene sentido. Lo que no lo tiene es que:

1. La verificación suspenda todo acceso antes de completarse.
2. El proceso sea unilateral, con plazos vagos y sin vía de contacto humano.
3. El coste del “mientras tanto” lo pague el usuario: páginas sin gestión, campañas pausadas, clientes sin servicio.

Estamos ante un riesgo de plataforma de manual: dependes de un rentero digital que pone las reglas, ejecuta la sanción y, cuando quiere, te devuelve la llave.

La ironía es doble. Por un lado, piden pruebas de humanidad a usuarios reales mientras la plataforma no logra frenar redes de spam, granjas de engagement y cuentas automatizadas. Por otro, el modelo de negocio que monetiza atención y datos penaliza al usuario legítimo que, por precaución, evita compartir más biometría de la necesaria. ¿Cuántos videoselfies más habrá que entregar para seguir “existiendo” en la plaza pública privatizada? ¿Harán algo más con esos videoselfies en la era de la inteligencia artificial?

El “apagón” invisible: cuando tu perfil arrastra a tu negocio

Para cualquiera que gestione proyectos, el perfil personal en Facebook no es un adorno: es la llave maestra que abre páginas, cuentas publicitarias, catálogos y activos compartidos. Si la llave desaparece:

• Pierdes acceso a páginas corporativas y Business Manager.
• Se interrumpen campañas y optimización.
• Se bloquea la atención al cliente en canales donde la marca conversa a diario.
• Se complica la facturación y los reportes.

Lo grave no es solo quedarse fuera. Es que la plataforma asume que este daño colateral es aceptable y no ofrece continuidad operativa. No hay un “modo seguro” que permita a un administrador secundario tomar el control temporal mientras dura la verificación del propietario inicial. Para quien gestiona marcas, eso es una deuda de fiabilidad difícil de justificar.

¿Es este el internet que queremos?

La pregunta es incómoda pero necesaria. No se trata de demonizar a Facebook (Meta) —que, como cualquier infraestructura masiva, sufre abuso, fraude y ataques—. Se trata de reconocer el desequilibrio:

• Centralización extrema: una compañía decide quién entra, quién sale y bajo qué criterios (a menudo, no auditable por usuarios o reguladores en tiempo real).
• Opacidad operativa: ni plazos, ni SLA, ni soporte humano predecible para incidencias que afectan a actividad económica.
• Asimetría de responsabilidad: el usuario pone su identidad, sus activos y su trabajo; la plataforma se reserva el derecho de desconectarte por “dudas” y luego verifica.

Mientras tanto, el ruido automatizado (bots, scrapers, spam) persiste porque los incentivos del modelo de negocio premian el volumen de actividad por encima de la calidad de comunidad. Es un peaje que muchos aceptan porque “ahí está la audiencia”. Hasta el día en que te dicen que, a efectos prácticos, no existes.

Qué hacer (ya) para reducir el riesgo de plataforma

Este episodio tiene moraleja. Si tu presencia en redes forma parte —aunque sea pequeña— de tu actividad profesional, conviene blindar cuatro frentes:

1) Gobernanza y roles

• Nunca dependas de un solo perfil como administrador de páginas y cuentas publicitarias.
• Añade 2–3 administradores de confianza en cada activo crítico (páginas, Business Manager, catálogos, píxeles, Conversion API).
• Crea un usuario del trabajo dedicado (con 2FA robusta y correo corporativo) para tareas de administración.

2) Redundancia operativa

• Documenta accesos y asigna permisos por rol, no por persona.
• Mantén métodos de pago alternativos y copias de creatividades, audiencias y reglas fuera de la plataforma.
• Automatiza reportes en herramientas externas para no depender del acceso diario a la cuenta.

3) Canales propios

• Fortalece activos de primera parte: dominio, lista de correo, CRM y analítica.
• Reparte la comunidad en más de un canal (web, newsletter, RSS, Fediverse/Mastodon, LinkedIn/Twitter/X) para no concentrar todo el riesgo en un solo jardín amurallado.

4) Cumplimiento y derechos

• Exige tus derechos de acceso y portabilidad (RGPD): descarga de datos, registro de actividad, justificante de bloqueo.
• Si hay impacto económico cuantificable (campañas interrumpidas, multas contractuales), documenta evidencias; la trazabilidad ayuda en reclamaciones.

Cómo debería ser un proceso de verificación responsable

No todo es queja. También hay buenas prácticas que cualquier plataforma podría adoptar sin sacrificar seguridad:

1. Verificación paralela, no punitiva: confirma identidad sin desconectar al usuario de activos comerciales cuando haya administradores redundantes.
2. Modos degradados: si hay dudas sobre el perfil, limita acciones de riesgo, pero mantén funciones críticas (atención al cliente, gestión de páginas) en manos de otros administradores.
3. Plazos y SLA claros: compromisos de tiempo máximo de resolución para cuentas con activos empresariales vinculados.
4. Soporte humano escalable: un canal verificable para incidencias económicas (no todo puede resolverse con bots y formularios).
5. Menos biometría, más señales: reforzar señales contextuales (historial, dispositivos, actividad) antes de pedir videoselfies a usuarios legítimos.

El coste silencioso de la centralización

El problema de fondo es que hemos delegado identidad, comunidad y distribución a plataformas privadas cuya prioridad no es —ni tiene por qué ser— nuestra continuidad operativa. A corto plazo, el coste escondido parece asumible: alcance rápido, herramientas potentes, segmentación fina. A largo plazo, la factura llega en forma de dependencia, bloqueos inexplicados y tiempos muertos que nadie compensa.

No se trata de “irse” de las plataformas. Se trata de rebalancear: usar lo que aportan, sin entregar las llaves de tu negocio o tu proyecto. La soberanía digital empieza en cosas tan prosaicas como tener copia de tus audiencias, otro admin con 2FA, y una newsletter que no puede cerrar un algoritmo.

¿Y Facebook? ¿Y yo?

Yo he cumplido con su videoselfie y esperaré su “idealmente en 1 día”. Si me devuelven la existencia, perfecto. Si no, tomaré nota y redistribuiré mi esfuerzo hacia canales que controlo. No por despecho, sino por prudencia operativa.

Porque nadie debería perder un día de trabajo —o una relación con sus clientes— por el capricho de una caja negra que decide, sin explicación y sin interlocutor, si sigues siendo humano. Y porque el internet que queremos no puede ser una ventanilla única con derecho de admisión cambiante.

Checklist exprés para quien está bloqueado ahora mismo

• Revisa desde ya quiénes son administradores en cada activo (página, cuenta publicitaria, píxel, catálogo). Añade 2–3 personas.
• Activa 2FA en todos los perfiles con acceso. Yo lo tenía activado.
• Exporta audiencias, creatividades y reportes a almacenamiento propio.
• Abre o refuerza un canal directo (newsletter, blog, RSS) y avisa a tu comunidad.
• Documenta impacto económico (fechas, campañas, presupuestos) por si necesitas reclamar.
• Solicita copia de tus datos y el motivo del bloqueo. Es tu derecho.

En resumen

Facebook puede tener sus razones, y el fraude es real. Pero la solución no puede ser desconectar a usuarios legítimos y paralizar su trabajo hasta que un algoritmo termine la ronda. Si una plataforma se erige en árbitro de tu identidad, debe ofrecer debidas garantías: procesos proporcionales, plazos razonables, soporte humano y continuidad cuando hay negocio en juego.

Mientras llega ese futuro, toca ser prácticos: menos dependencia, más redundancia y más canales propios. Porque el día que una pantalla te diga que ya no existes, no debería también desaparecer tu trabajo.

La entrada Así se las gasta Facebook: cuando una plataforma decide si existes (o no) aparece primero en Carrero.

Frente a ellos se extendía un universo infinito de posibilidades: olas que saltar, pelotas que van y vienen, cubos de arena esperando convertirse en castillos a orillas del agua, piedras y conchas marinas perfectas para coleccionar, cangrejos jugando al escondite, peces brillando bajo el agua. El verano les ofrecía bucear en el mar cristalino, chapotear en la piscina, incluso intentar hacer surf en las olas más pequeñas. La vida real, en toda su magnificencia, esperándolos.

Pero ellos no veían nada de eso. Sus pequeños dedos deslizándose mecánicamente por una pantalla de pocas pulgadas mientras la inmensidad del océano o la piscina los llamaba sin respuesta.

Esa imagen me obsesionó durante días. Y me hizo reflexionar sobre mi propio hijo, Bruno, que con 6 años para 7, sigue sin tocar un móvil. Durante esas mismas vacaciones lo vi disfrutar cada momento: atesorar recuerdos de olas superadas y olas surfeadas, hacer grandes amigos nuevos cada día, participar en juegos de verano y gimkanas, correr detrás de un balón de fútbol, jugar a las palas en la orilla, quedarse embobado mirando las estrellas por la noche. Viviendo cada momento intensamente para llevárselos siempre consigo.

La diferencia era abismal. Mientras otros niños de su edad permanecían inmóviles frente a una pantalla, Bruno coleccionaba experiencias reales, emociones auténticas, recuerdos que formarán parte de él para siempre.

Porque esa escena que presencié en la playa no es una excepción: se repite con alarmante normalidad en los parques, en las salas de espera, en restaurantes, en las casas. Un bebé de apenas un año con los ojos clavados en una pantalla. No es un caso aislado. Es la nueva normalidad. No grita, no molesta, no exige atención. «Mira qué atento está», dice alguien. «Así aprende», añade otro. Pero lo cierto es que, tras esa falsa calma, se está gestando una tormenta silenciosa.

Vivimos en la era de las pantallas y las excusas. Se dice que estimulan, que enseñan colores, formas, sonidos. Se cree que entretienen, que relajan, que facilitan la vida de los adultos. Y sí, lo hacen. Pero a costa de algo mucho más profundo: el desarrollo humano. Empezamos entregándoles un móvil a los 8 meses para que estén «quietos», y cuando queremos darnos cuenta, a los 8 años ya no sabemos cómo recuperar su atención sin una pantalla.

La responsabilidad es nuestra

Pero antes de continuar con los datos y estudios, hay algo fundamental que debemos dejar claro: los máximos responsables somos los padres. Ni los colegios y profesores, ni mucho menos las empresas tecnológicas o los gobiernos. La educación y protección de nuestros menores empieza por nosotros.

YO NO quiero que un gobierno o una gran empresa decida cómo debo controlar mi libertad ni la de mis hijos. Para eso los educamos: para que piensen por sí mismos y sepan elegir bien. La libertad real no es darles acceso ilimitado a todo, sino enseñarles a discernir, a valorar, a elegir conscientemente.

Es cómodo culpar al sistema, a las escuelas sobrecargadas, a las empresas que diseñan aplicaciones adictivas. Pero la realidad es más incómoda: somos nosotros quienes ponemos el móvil en sus manos. Somos nosotros quienes decidimos si un berrinche se calma con una pantalla o con paciencia. Somos nosotros quienes elegimos entre el silencio artificial de un dispositivo y el «ruido» natural de un niño siendo niño.

Los datos no mienten

Los números son devastadores. Un 40% de niños de 2 años ya tienen su propia tablet, según el último informe de Common Sense Media de 2025. Los niños de 0 a 2 años están expuestos a pantallas una media de 49 minutos al día, muy por encima del tiempo cero recomendado por las autoridades sanitarias.

La Organización Mundial de la Salud es categórica: los menores de 1 año no deberían estar expuestos a pantallas en absoluto, y los niños de 2 años no deberían superar 1 hora diaria. Sin embargo, solo 1 de cada 4 niños menores de 2 años cumple estas recomendaciones. Aquí personalmente iría más allá, cuando más tarde tenga exposición a un móvil mejor, no estoy de acuerdo con que la OMS hable de no más de 1 hora para más de 2 años de edad, debería ser CERO.

¿Las consecuencias? Un estudio australiano reveló que a los 6 meses de edad, los bebés ya están expuestos a una media de 1 hora y 16 minutos de pantallas diarias, aumentando a 2 horas y 28 minutos a los 24 meses. Más preocupante aún: algunos niños de 6 meses están siendo expuestos a más de 3 horas de pantallas al día.

El cerebro en construcción

Lo que está en juego no es solo el comportamiento: es el desarrollo cerebral. Un estudio pionero del Hospital Infantil de Cincinnati, publicado en JAMA Pediatrics, utilizó resonancias magnéticas para examinar los cerebros de 47 niños sanos de 3 a 5 años. Los niños expuestos a más tiempo de pantalla del recomendado mostraron menor integridad de la materia blanca cerebral, especialmente en áreas cruciales para el lenguaje y las habilidades de alfabetización.

Dr. John Hutton, director del estudio, explica que «esto es importante porque el cerebro se desarrolla más rápidamente en los primeros cinco años. Ahí es cuando los cerebros son muy plásticos y absorben todo, formando estas conexiones fuertes que duran toda la vida».

Los escáneres cerebrales mostraron una maduración acelerada en ciertas áreas básicas como el procesamiento visual, pero un subdesarrollo en otras áreas de orden superior que apoyan habilidades más complejas como el desarrollo del lenguaje, las habilidades de lectura y las habilidades sociales.

El déficit invisible

La neurocientífica Patricia Kuhl, una de las investigadoras más prominentes en desarrollo cerebral infantil, es contundente: «Lo que hemos descubierto es que los bebés pequeños, menores de un año, no aprenden de una máquina. Incluso si les muestras videos cautivadores, la diferencia en el aprendizaje es extraordinaria. Obtienes un aprendizaje genial de un ser humano vivo, y obtienes cero aprendizaje de una máquina».

Un estudio longitudinal israelí siguió a 179 familias y encontró que la exposición a pantallas a los 6 y 12 meses se asoció con un mayor riesgo de déficits de lenguaje y comunicación a los 36 meses, especialmente en familias de nivel socioeconómico medio y alto.

Los niños de 12 a 24 meses que pasaban dos horas al día frente a una pantalla mostraron hasta seis veces más probabilidades de desarrollar retrasos en el lenguaje. Y el problema se agrava si comenzaron antes: los riesgos de retraso en el lenguaje empeoraron si comenzaron el tiempo de pantalla antes de los 12 meses.

La televisión de fondo: el enemigo silencioso

Incluso cuando los niños no están mirando directamente, las pantallas causan daño. Los estudios muestran que cuando hay televisión de fondo, los padres tienden a hablar menos y ser más pasivos en sus interacciones con sus hijos. La televisión de fondo ha demostrado tener efectos negativos en el uso y adquisición del lenguaje, la atención, el desarrollo cognitivo y la función ejecutiva en niños menores de 5 años.

No estamos educando. Estamos anestesiando.

Y las consecuencias no se verán solo hoy. Las veremos —las estamos viendo ya— cuando esos niños entren en la adolescencia. Cuando necesiten resolver conflictos sin emojis, cuando deban esperar y no puedan soportar la frustración, cuando busquen relaciones reales y no sepan sostener una mirada. Los estudios asocian el tiempo excesivo de pantalla con mayor ansiedad, síntomas depresivos, menor calidad de vida, menor bienestar psicológico, menor funcionamiento escolar, menor rendimiento académico y menor autoestima.

Estamos criando generaciones impacientes, frágiles, hipersensibles al aburrimiento y cada vez más desconectadas del mundo real.

Habrá quien diga que esto es catastrofismo, que cada época ha tenido sus miedos. Pero este es distinto. Porque nunca antes habíamos delegado tanto la crianza en una interfaz táctil. Nunca antes habíamos confundido estimulación con dopamina instantánea, ni aprendizaje con scroll infinito. Les hemos robado la oportunidad de aburrirse, de imaginar, de descubrir el mundo con las manos y no con el pulgar.

La realidad de las familias

No se trata de demonizar la tecnología. Se trata de recuperar el control, de entender que las pantallas no son niñeras, ni consuelo, ni recompensa. Son herramientas, y como tales deben usarse con criterio, con límites, con conciencia.

Los niños pequeños ahora promedian dos horas y media de tiempo de pantalla diario, principalmente viendo contenido de video de formato corto. Y sabemos por qué: muchos programas, aplicaciones y juegos para niños pequeños están diseñados para ser especialmente atractivos en dispositivos portátiles. Cuanta más autonomía tienen los niños sobre estos dispositivos, más peligro representan.

Lo preocupante no es solo lo que hacen frente a la pantalla. Es todo lo que no hacen mientras están frente a ella. No corren. No trepan. No se ensucian. No exploran. No se pelean ni se reconcilian. No practican la espera. No experimentan el error. Los niños pequeños necesitan su dosis de aburrimiento. Les enseña a lidiar con la frustración y controlar sus impulsos. Si los niños pequeños están siendo constantemente estimulados por pantallas, olvidan cómo depender de sí mismos o de otros para entretenerse.

El camino de vuelta

La investigación ha demostrado que el tiempo de pantalla inhibe la capacidad de los niños pequeños para leer caras y aprender habilidades sociales, dos factores clave necesarios para desarrollar empatía.

Sí, este texto generaliza. Porque a veces hay que sacudir con fuerza para que algo se mueva. Porque si no lo decimos así, seguiremos mirando hacia otro lado. Es urgente poner freno. Es urgente devolver la infancia a los niños. Volver a hablar, a leer juntos, a jugar, a aburrirse. Apagar la pantalla. Encender el vínculo.

Como dice la OMS: «Lo que realmente necesitamos hacer es devolver el juego a los niños. Se trata de hacer el cambio del tiempo sedentario al tiempo de juego, mientras protegemos el sueño».

Quizás aún estemos a tiempo. Pero no lo estaremos mucho más.

Fuentes principales:

• Common Sense Media (2025). The 2025 Common Sense Census: Media Use by Kids Zero to Eight
• Hutton, J.S. et al. (2020). Associations Between Screen-Based Media Use and Brain White Matter Integrity in Preschool-Aged Children. JAMA Pediatrics
• Organización Mundial de la Salud (2019). Guidelines on Physical Activity, Sedentary Behaviour and Sleep for Children under 5 Years of Age
• Slobodin, O. et al. (2024). Infant screen media and child development: A prospective community study. Infancy
• Sociedad Canadiense de Pediatría (2024). Screen time and preschool children: Promoting health and development in a digital world

La entrada Los estamos perdiendo… y ni siquiera tienen cinco años aparece primero en Carrero.

¿Qué era el formato Q (Quantum)?

El formato .Q, conocido como Quantum, creado por la empresa Cinematronics, fue un compresor de archivos diseñado para sistemas MS-DOS, muy utilizado entre 1989 y mediados de los 90. Su objetivo era ofrecer una compresión rápida y aceptable sin necesidad de requerimientos avanzados. Era especialmente útil para programadores, usuarios técnicos y entornos donde el tamaño del archivo debía reducirse drásticamente para caber en un solo disquete.

Características destacadas:

• Extensión: .q
• Plataforma original: MS-DOS
• Rendimiento: muy rápido en compresión y descompresión
• Licencia: freeware / shareware
• Última versión conocida: alrededor de 1994–1995
• Fin de uso aproximado: ~1996, aunque hay reportes de uso esporádico en entornos legacy incluso después
• En los enlaces os dejo una copia del compresor para descargar y usar en MS-DOS.

Una herramienta que marcó una época… y desapareció

El programa Q.EXE ofrecía una utilidad de línea de comandos con opciones mínimas pero funcionales. Su rapidez lo convirtió en una herramienta muy atractiva en una época en la que se valoraban tanto los recursos como el tiempo de procesamiento.

Pero a diferencia de formatos como ZIP o RAR, Quantum nunca ganó adopción masiva ni continuidad de desarrollo. Al llegar Windows 95 y la progresiva estandarización de ZIP, el formato Q quedó relegado al olvido. No existe documentación oficial completa y los ejecutables circulaban principalmente por BBS, disquetes y colecciones personales de utilidades.

Mi experiencia personal: la odisea de descomprimir un archivo .Q en 2025

En uno de mis recientes proyectos de recuperación de datos antiguos, decidí digitalizar y analizar el contenido de disquetes de 3,5″ que usaba durante mis primeros años como programador. Estos discos contenían utilidades en Basic y Pascal, código fuente, ejecutables y documentos. Para mi sorpresa, varios archivos estaban comprimidos en formato .Q.

El problema fue inmediato: ningún sistema actual reconocía el archivo ni encontraba cómo descomprimirlo. Los motores de búsqueda no ofrecían una solución clara. Proyectos como The Internet Archive, WinWorld o Vetusware tampoco tenían copia de Q.EXE en sus catálogos. Herramientas modernas como 7-Zip, PeaZip o Bandizip no soportan el formato .Q.

Cuando estaba a punto de desistir, recordé que en uno de mis disquetes antiguos había guardado una copia del ejecutable. Efectivamente, Q.EXE estaba ahí, funcionando en un entorno DOSBox bajo Linux. Así pude recuperar mis archivos comprimidos más de tres décadas atrás.

Ahora también tienes disponible un UnQuantum de código abierto que te permite descomprimir tus .Q en Linux, Mac o Windows sin problemas.

Enlaces útiles para entornos de recuperación

Si te encuentras con una situación similar, estos recursos pueden ayudarte:

• DOSBox – emulador de MS-DOS para ejecutar utilidades antiguas como Q.EXE.
• Vetusware – repositorio de software abandonado para DOS y Windows 3.x/95.
• Internet Archive – Software Collection – incluye paquetes antiguos y herramientas comprimidas.
• WinWorldPC – archivos históricos de utilidades, sistemas operativos y programas de la era DOS/Windows 3.x.
• Copia de Quantum completo (mi colección particular) disponible para descargar desde mi sitio web, para usar en MS-DOS o compatibles.
• UnQuantum es una versión moderna para descomprimir ficheros .Q en sistemas modernos.

Nota: A día de hoy no se encuentra una copia pública del compresor Quantum. Si tienes una, considera preservarla y compartirla con la comunidad.

Recomendaciones para preservar archivos antiguos

1. Digitaliza disquetes y CDs cuanto antes: estos soportes tienen vida limitada (15–30 años).
2. Guarda versiones de ejecutables antiguos: como Q.EXE, ARJ.EXE o LHA.EXE.
3. Usa emuladores como DOSBox o PCem para abrir entornos antiguos sin necesidad de hardware original.
4. Crea imágenes ISO o IMG de disquetes con herramientas como WinImage o dd en Linux.
5. No reconviertas formatos sin antes comprobar integridad, ya que podrías perder datos por fallos de compresión o compatibilidad.

Conclusión

El caso del compresor Q (Quantum) es solo un ejemplo de los muchos formatos que formaron parte de la historia del software personal y empresarial, y que hoy son difíciles de rastrear. Para quienes crecimos en la era MS-DOS, estos pequeños programas eran esenciales para exprimir cada byte de espacio. Ahora, décadas después, recuperar esos archivos se ha convertido en una tarea de arqueología digital.

Gracias a la copia de Q.EXE que encontré en uno de mis disquetes, pude rescatar datos valiosos y recuerdos personales que habrían quedado inaccesibles. Esta experiencia me ha recordado la importancia de preservar el software tanto como los datos, y de compartir herramientas que puedan servir a futuras generaciones o a quienes, como yo, aún buscan respuestas en sus archivos del pasado.

Documentación original en PDF

La entrada Rescatando el pasado digital: el formato de compresión Q (Quantum) en MS-DOS aparece primero en Carrero.