En abril escribí que la soberanía digital europea era un espejismo mientras siguiéramos fragmentados. Decía entonces que a Europa no le falta talento, ni tecnología, ni dinero, y que la compra pública era la palanca más potente que teníamos y la estábamos desperdiciando. Cinco meses después han pasado dos cosas que merecen un artículo.
La primera es que han empezado a aparecer contratos de verdad: Airbus, el Gobierno federal alemán y la Generalitat de Catalunya han firmado en los últimos meses acuerdos con requisitos de soberanía escritos en el pliego. La segunda es que me he puesto a repasar la historia, y resulta que esto que estamos haciendo ahora Europa ya lo intentó cuatro veces desde 1966. Y perdió las cuatro.
Las claves de la soberanía tecnológica europea en 30 segundos
Francia lanzó el Plan Calcul en 1966 tras un veto estadounidense y lo cerró en 1975 sin alcanzar sus objetivos.
Unidata, el Airbus de la informática, llegó al 13,2 % de las ventas europeas de ordenadores en 1973 y lo disolvió el propio Gobierno francés.
Siemens y Philips cumplieron el calendario técnico del proyecto MEGA y Siemens admite hoy que no fue un éxito económico.
De JESSI no salió la industria de memorias que se buscaba, pero sí el apoyo temprano a ASML.
Airbus, Alemania y la Generalitat ya han firmado contratos con requisitos explícitos de soberanía.
Repasar esos cuatro intentos no es nostalgia. Ninguno falló por falta de presupuesto público ni por incapacidad técnica, y entender por qué cayó cada uno explica bastante mejor lo que nos pasa hoy que seguir comparando catálogos de servicios entre un proveedor europeo y un hiperescalar americano.
Un veto de Estados Unidos y una respuesta en dos meses
En mayo de 1966 Estados Unidos se negó a entregar dos superordenadores CDC 6600 al Commissariat à l’énergie atomique francés. Los motivos que se invocaron fueron la salida de Francia del mando integrado de la OTAN y el tratado de no proliferación. El golpe llegaba después de otro: en 1964 General Electric había tomado el control de la Compagnie des Machines Bull y había cancelado dos modelos de ordenador franceses.
De Gaulle aprobó el Plan Calcul en julio de 1966, dos meses después del veto. En diciembre nació la Compagnie Internationale pour l’Informatique, bajo tutela directa del primer ministro. Francia gastó más de 100 millones de dólares en los cinco primeros años y esperaba que la nueva compañía facturase 200 millones antes de 1975.
Y el negocio creció de verdad. La facturación pasó de 370 millones de francos en 1970 (unos 56 millones de euros al tipo fijo de conversión de 1998, sin ajustar por inflación) a 1.350 millones en 1974 (unos 206 millones), y su cuota del parque instalado francés subió del 7,5 % al 10 %. Aun así el plan se dio por terminado en 1975 y la empresa acabó fusionada con la estadounidense Honeywell. Entre 1977 y 1980 las subvenciones sumaron 812 millones de francos, unos 124 millones de euros, frente a 724 millones de beneficios acumulados, unos 110 millones. El Estado puso más de lo que la compañía ganó.
El argumento con el que Bruselas legisla en 2026 es exactamente el mismo que el de París en 1966: no depender de un proveedor extranjero para infraestructura considerada estratégica.
Unidata: el Airbus que sí se intentó, y que Francia desmontó
En abril usé la comparación con Airbus para explicar lo que Europa debería hacer con la infraestructura digital. Lo que no sabía entonces, y me parece el hallazgo más incómodo de todo este repaso, es que el Airbus de la informática se intentó de verdad, y llegó a funcionar.
Se llamaba Unidata y reunía a la francesa CII, a la alemana Siemens y a la neerlandesa Philips. El reparto de trabajo estaba claro: Philips ponía los semiconductores, Siemens los periféricos y el almacenamiento magnético, y CII la arquitectura, el software y la dirección del proyecto. El acuerdo se firmó en Ámsterdam el 4 de julio de 1973.
Panel frontal de un CII Mitra 15, de la empresa creada por el Plan Calcul francés. Foto: Damien.b, CC BY-SA 4.0, vía Wikimedia Commons.
En 1973 el consorcio reunía el 13,2 % de las ventas europeas de ordenadores y el 9,8 % del parque instalado. Las primeras máquinas se entregaron en 1974.
Lo que lo detuvo no fue el mercado. En 1975, recién elegido, Valéry Giscard d’Estaing denunció de forma unilateral el acuerdo. Detrás de la ruptura estuvo Ambroise Roux, presidente de CGE y accionista de peso en CII, que temía que Unidata acabara compitiendo con sus intereses en telecomunicaciones. Francia prefirió entregar su participada a Honeywell y el consorcio se disolvió en diciembre de ese año.
Aquí está la diferencia que importa, y que matiza mi propio argumento de abril. Airbus voló porque las aerolíneas compraron aviones. Los Estados no podían garantizar a Unidata una cuota equivalente en un mercado informático abierto, y sin demanda asegurada el consorcio dependía de que tres accionistas con intereses distintos siguieran remando en la misma dirección. Bastó con que uno dejara de remar.
Un Bull KBU de 1971. La empresa fue nacionalizada por Francia en 1982 y vuelta a comprar por el Estado francés en marzo de 2026. Foto: Myoth, dominio público, vía Wikimedia Commons.
Bull, la empresa que estaba en el origen de todo aquello, fue nacionalizada en 1982, privatizada en los noventa y vendida a Atos en 2014. El 31 de marzo de 2026 el Estado francés la compró entera otra vez, por un valor de empresa de hasta 404 millones de euros.La nota oficial habla de nuevo de soberanía digital. Cuarenta y cuatro años para volver al punto de partida.
Cumplir el calendario y perder igual
El tercer intento fue industrial y tenía fecha de entrega. En julio de 1984, en Estocolmo, el presidente de Siemens, Karl Heinz Kaske, presentó el proyecto MEGA junto a Philips. Siemens comprometiía 1.400 millones de marcos (unos 716 millones de euros al tipo fijo de conversión de 1998, sin ajustar por inflación), 800 de ellos en investigación. El desarrollo conjunto se presupuestó en 1.500 millones de marcos (unos 767 millones de euros), con 700 millones de participación neerlandesa (unos 358 millones). El Gobierno alemán aportaba 300 millones de marcos (unos 153 millones de euros) y el neerlandés 200 millones de florines (unos 91 millones de euros, siempre con el cambio fijo de 1998 como indicaba antes).
El calendario declarado era concreto: memorias de 1 megabit fabricándose a partir de 1987 y de 4 megabit entre 1989 y 1990.
Y lo cumplieron. En 1987 Siemens fue, junto a Toshiba, la primera compañía occidental en producir en serie chips de 1 megabit, y los de 4 megabit llegaron en 1989. Lo llamativo es lo que la propia Siemens escribe hoy en su cronología corporativa: que aspiraba al liderazgo mundial en cinco años y que el proyecto no fue un éxito económico, aunque le permitiera acercarse a sus competidores.
Un chip de memoria Siemens de la serie HYB, heredera del linaje de DRAM que arrancó con el proyecto MEGA. Este modelo concreto es posterior, de finales de los noventa. Foto: Raimond Spekking, CC BY-SA 4.0, vía Wikimedia Commons.
Ese es el dato que hay que retener, y viene de la empresa que lo protagonizó, no de sus críticos. No falló la ingeniería ni el plazo. Falló el negocio.
Hay además un detalle que redondea la historia. La tecnología CMOS de 1 megabit llegó a Siemens mediante un acuerdo de licencias con Toshiba. El programa europeo para dejar de depender de los fabricantes japoneses licenció a un fabricante japonés la tecnología con la que pensaba conseguirlo.
Philips llegó a ser el mayor fabricante de chips de Europa y el séptimo del mundo. Los beneficios fueron decepcionantes y después vino la reorganización Operation Centurion, con 50.000 empleos suprimidos a escala global entre 1990 y 1997.
Lo que salió de JESSI no fue lo que se fue a buscar
El cuarto intento fue el más ambicioso. JESSI, la Joint European Submicron Silicon Initiative, arrancó el 1 de julio de 1989 dentro del marco EUREKA, coordinada desde Múnich, con 157 participantes de trece países. Alemania aportó 59 y Francia 53. España, tres. Un informe estadounidense de 1992 preveía una financiación de 8.000 millones de dólares, con más de 4.500 millones procedentes de gobiernos comunitarios. La ficha oficial del programa, por cierto, nunca ha publicado su presupuesto.
Bernhard Dachs, del Austrian Institute of Technology, publicó en septiembre de 2025 el análisis retrospectivo más completo que he encontrado. Su conclusión tiene tres partes y las tres se leen hoy como una advertencia. El cambio tecnológico dejó obsoletos objetivos iniciales importantes. El propósito de forjar una alianza europea chocó con las estrategias globales de las propias multinacionales participantes, que buscaban a la vez socios fuera de Europa. Y, pese a todo, el programa dejó beneficios a largo plazo que nadie había planificado, entre ellos el apoyo temprano a ASML.
Instalaciones de ASML en Veldhoven. El apoyo temprano del programa JESSI fue uno de los pocos resultados duraderos de aquella iniciativa. Foto: Minister-president Rutte / Rijksoverheid, CC BY 2.0, vía Wikimedia Commons.
Merece la pena detenerse ahí. ASML es hoy la única empresa del mundo capaz de fabricar las máquinas de litografía ultravioleta extrema con las que se producen los chips más avanzados, y cerró 2025 con 32.700 millones de euros de ventas. Europa no consiguió en 1989 lo que fue a buscar, que era una industria de memorias propia. Consiguió otra cosa, más valiosa, que no estaba en el plan.
El mismo Dachs escribía en 2023, sobre la Ley Europea de Chips, que caben dudas razonables porque varias iniciativas similares no alcanzaron sus objetivos en el pasado. Citaba JESSI como ejemplo.
Lo que ha cambiado desde abril: han empezado a firmarse contratos
Los datos de hoy no invitan al triunfalismo. El Tribunal de Cuentas Europeo concluyó en 2025 que alcanzar el 20 % de la producción mundial de chips en 2030 exigiría cuadruplicar la capacidad europea, y que no estamos cerca. La previsión de la propia Comisión es del 11,7 %. El Cloud and AI Development Act sigue siendo una propuesta en tramitación, no derecho aplicable.
Lo que sí ha cambiado es más aburrido y más eficaz que cualquier reglamento: alguien ha empezado a firmar.
Airbus seleccionó a Scaleway en julio de 2026 para alojar parte de sus aplicaciones críticas en un entorno soberano, sin abandonar el resto de su cartera cloud. En Alemania, un consorcio liderado por SVA, con Codesphere y Schwarz Digits a través de STACKIT, figura entre los adjudicatarios de la plataforma de inteligencia artificial del ministerio federal de Digitalización, un contrato marco de alrededor de 250 millones de euros. Y en España, la Generalitat de Catalunya licitó en julio una nube pública soberana por 481 millones de euros a ocho años, con certificación SEAL 3 y la exigencia de que el proveedor esté sujeto de forma exclusiva a legislación europea.
La operación catalana es la más interesante de las tres, porque convierte la soberanía en un requisito de pliego mientras el marco europeo sigue siendo un texto en discusión. Es justo lo que pedía en abril: compra pública con criterios, no declaraciones.
Lo que dicen las empresas cuando les preguntas en serio
Conviene meter aquí el contrapeso, porque si no este artículo se convierte en otro texto optimista de los que ya hay demasiados. Capgemini encuestó en abril de 2026 a 1.300 directivos de grandes organizaciones, España incluida, y publicó los resultados este mes.
El 59 % considera irrealista la soberanía digital plena. El 36 % calcula que cambiar de proveedor crítico le llevaría más de doce meses y un 10 % reconoce que no tiene alternativa viable. Solo el 14 % tiene visibilidad completa de sus dependencias tecnológicas. Y casi la mitad no está dispuesta a asumir el sobrecoste que atribuye a la soberanía, que el propio estudio estima en un 23 %.
Ese último dato es el que más me interesa, porque es el que separa el discurso de la factura. Llevo años oyendo en reuniones que la soberanía importa. Importa hasta que aparece el 23 %.
Plan Calcul, Unidata, MEGA y JESSI tuvieron presupuesto, tecnología y respaldo político. Lo que ninguno tuvo fue alguien obligado a comprar. Si esta vez sale distinto no será por el reglamento que se apruebe en Bruselas, sino por cuántas administraciones y cuántas empresas europeas hagan lo que acaban de hacer Airbus, el Gobierno alemán y la Generalitat. Y por si están dispuestas a pagar la diferencia cuando llegue la factura.
Preguntas frecuentes
¿Qué fue el Plan Calcul?
Un programa francés aprobado en julio de 1966 para crear una industria informática nacional, después de que Estados Unidos vetara la venta de dos superordenadores al programa nuclear francés. Se cerró en 1975 sin alcanzar sus objetivos de facturación.
¿Por qué fracasó Unidata si tenía cuota de mercado?
Porque su continuidad dependía de decisiones políticas y accionariales, no de sus ventas. En 1975 el Gobierno francés denunció el acuerdo de forma unilateral, presionado por intereses industriales internos, y prefirió entregar su participada a un socio estadounidense.
¿Puede la Ley Europea de Chips alcanzar el 20 % de cuota mundial en 2030?
El Tribunal de Cuentas Europeo lo considera muy improbable y calcula que exigiría cuadruplicar la capacidad de producción actual. La previsión de la propia Comisión Europea es del 11,7 %.
¿Qué diferencia hay entre los intentos anteriores y la situación actual?
Los cuatro programas históricos financiaron oferta sin asegurar demanda. En 2026 han empezado a aparecer contratos con requisitos explícitos de soberanía, firmados por clientes concretos como Airbus, el Gobierno federal alemán y la Generalitat de Catalunya.
Mi última etapa realmente intensa programando pertenece a una época de Turbo Pascal, Turbo C y Delphi, y fue allá por 1998. Treinta años después he vuelto a escribir software con una frecuencia que no esperaba recuperar. La diferencia es que ahora buena parte del trabajo la hago acompañado por agentes de inteligencia artificial como Claude Code y Codex. El cambio ha sido tan grande que mi problema ya no es si puedo construir una idea, sino decidir cuáles merecen realmente convertirse en un proyecto.
Las claves de volver a programar con IA en 20 segundos
Claude Code y otros agentes han reducido muchísimo la barrera para volver a desarrollar software después de años alejado del código diario.
En pocos meses he creado herramientas open source, aplicaciones nativas y servicios web que utilizo personalmente.
Generar más código no elimina la necesidad de arquitectura, pruebas, seguridad y revisión humana.
La nueva escasez ya no es técnica: son el tiempo, la atención y saber abandonar proyectos.
Todavía recuerdo perfectamente aquella pantalla azul de Borland, hecho hace unos meses encontré la caja original de Borland Pascal con manuales y disquetes de 3,5″, una joya para conservar. Para quienes aprendimos a programar en los años ochenta y noventa, Turbo Pascal era algo más que un compilador. Editor, compilación y ejecución estaban integrados en una experiencia que entonces parecía extraordinariamente rápida.
Turbo Pascal apareció en 1983 por 49,95 dólares, un precio muy agresivo para la época. Las primeras versiones eran tan compactas que el compilador, el entorno de desarrollo y las herramientas cabían en un disquete. Los programas .COM estaban limitados a 64 KB. Visto desde 2026 parece prehistoria informática, pero entonces aquello abría un mundo.
Después llegaron Turbo C y, sobre todo, Delphi. Delphi 1.0 se presentó en febrero de 1995 y consiguió algo que me sigue pareciendo importante: acercar el desarrollo visual sin renunciar a compilar aplicaciones nativas.
Hay además una continuidad histórica que me resulta especialmente curiosa. Anders Hejlsberg estuvo detrás del compilador que dio origen a Turbo Pascal, fue arquitecto jefe de Delphi y posteriormente, ya en Microsoft, diseñó C# y TypeScript. Una parte importante del código que hoy puede generar un agente de IA utiliza lenguajes descendientes de la carrera profesional de la misma persona que estaba detrás de las herramientas con las que muchos empezamos.
Y Delphi tampoco ha muerto. A septiembre de 2026 Embarcadero mantiene RAD Studio 13.1 y prepara la versión 13.2. Incluso dispone ya de Kai, su propia plataforma de IA agéntica integrada en RAD Studio.
Treinta años después hemos acabado juntando las dos épocas.
De escribir cada línea a dirigir el desarrollo
El cambio para mí llegó con herramientas como Claude Code.
No me refiero simplemente al autocompletado que propone la siguiente función. Claude Code puede leer un proyecto, localizar ficheros, modificar código, ejecutar pruebas, utilizar herramientas de terminal y trabajar durante bastante tiempo sobre un objetivo.
Ahí cambia la relación con la programación.
Durante muchos años podía tener una idea y saber aproximadamente cómo construirla, pero el coste en horas hacía que no tuviera sentido empezar. Había que recuperar conocimientos, estudiar nuevas librerías, preparar interfaces, gestionar dependencias y dedicar fines de semana enteros a detalles que no eran precisamente la parte divertida del proyecto.
Ahora puedo concentrarme mucho más en definir qué quiero construir.
Eso no significa escribir «hazme una aplicación» y esperar.
De hecho mi experiencia está siendo casi la contraria. Cuanto más utilizo agentes de programación, más importancia doy al orden. Ficheros como CLAUDE.md, documentación de arquitectura, instrucciones concretas, tests, hooks y pequeñas especificaciones terminan marcando una diferencia enorme. De hecho me queda mucho por aprender para organizarme mucho mejor.
La propia documentación de Claude Code recomienda que las instrucciones sean específicas. «Ejecuta los tests antes de hacer commit» es mucho mejor que decir simplemente «prueba los cambios». Y Anthropic reconoce algo todavía más importante: que Claude intente seguir CLAUDE.md no garantiza su cumplimiento. Para las reglas que no pueden incumplirse existen mecanismos deterministas como los hooks.
Esa diferencia entre pedir y verificar me parece esencial.
También ha cambiado el entorno que rodea al código. El Model Context Protocol (MCP), presentado por Anthropic en noviembre de 2024, fue adoptado después por otras compañías y terminó bajo la Agentic AI Foundation de la Linux Foundation. Resulta difícil imaginar algo más distinto de los entornos bastante cerrados con los que aprendimos a programar hace tres décadas.
De las ideas a programas que realmente utilizo
La consecuencia más evidente de esta nueva forma de trabajar está en mis repositorios y en mi carpeta de aplicaciones.
Uno de los proyectos que he liberado como open source es CrawlForge, un crawler de SEO técnico escrito en Rust. Puede rastrear una web por HTTP, analizar directamente una versión generada antes de desplegarla y comparar dos crawls para detectar qué ha cambiado.
En una prueba real ha procesado 487.621 URLs de un medio con quince años de archivo y millones de imágenes. En otro ensayo comparé 1.800 valores obtenidos por CrawlForge y por una herramienta consolidada: estados HTTP, títulos, descripciones, H1, canonical e indexabilidad.
No hubo diferencias.
Bueno, sí apareció una. Era un <br> dentro de un <h1> y el error estaba en la otra herramienta.
Ese tipo de casos me ha enseñado algo importante sobre programar con IA: el modelo puede producir código, pero la responsabilidad sobre lo que ese código afirma sigue siendo mía.
Otro ejemplo es FlarePurge, una pequeña aplicación para purgar la caché de Cloudflare. Está disponible para diferentes plataformas y su código es abierto para si quieres compilar tu propia versión.
Lo interesante para mí no es todo lo que hace, sino precisamente lo que decidí que no hiciera.
FlarePurge purga caché. Nada más.
DNS, WAF, analítica y otras funciones quedan fuera deliberadamente. Los tokens se almacenan utilizando los mecanismos seguros del sistema y la recomendación es conceder únicamente el permiso necesario para purgar caché.
Poder desarrollar más rápido genera una tentación enorme de añadir funcionalidades porque «cuestan poco». Pero cada función que se añade hoy es código que habrá que entender, probar y mantener mañana.
Otro proyecto al que tengo especial cariño es mboxShell, un visor y buscador de archivos MBOX para terminal, también escrito en Rust y publicado con licencia MIT. Una idea para poder leer mis backups de correo de Google Takeout y del que podéis encontrar una versión con GUI para MacOS y Windows en Mbox Viewer pro que también cito más abajo.
Está pensado para poder trabajar con buzones enormes sin cargar todo el fichero en memoria. Un MBOX de 100 GB puede utilizar aproximadamente la misma memoria que uno de 1 GB porque el procesamiento se realiza en streaming.
Y aquí apareció uno de esos bugs que explican por qué sigo sin fiarme ciegamente del código generado.
Trabajando con una exportación de Google Groups descubrí un formato de fecha peculiar. Cuando el parser no entendía correctamente una de esas fechas, el fallback no fallaba de forma espectacular. Hacía algo bastante peor: devolvía una fecha aparentemente válida pero incorrecta.
Ese es el tipo de error peligroso.
Un programa que se cae obliga a investigar. Uno que devuelve silenciosamente un dato plausible puede permanecer equivocado durante meses.
También encontré un problema de precedencia en las búsquedas booleanas. En un buzón de 6.787 mensajes, una consulta que debía devolver 49 resultados podía terminar mostrando 2.102.
Ninguna inteligencia artificial sustituye comprobar que 49 siguen siendo 49.
Construir cosas para resolver mis propios problemas
Hay además una categoría de proyectos que probablemente explica mejor por qué he vuelto a disfrutar programando: herramientas que quería utilizar yo mismo.
Polen Madrid nació para consultar de forma sencilla los datos de polen de la Red Palinológica de la Comunidad de Madrid. Incluye mapa, histórico, calendario y alertas. Los datos proceden de 11 estaciones y cubren numerosos tipos de polen.
Una de las decisiones que más me gusta no tiene nada de técnicamente espectacular: las alertas solo se envían durante la temporada del alérgeno elegido. Además de una API en el que tenemos ya como 10 usuarios que se conectan de manera gratuita para consumir los datos del polen.
Poder mandar un correo todos los días no significa que haya que hacerlo.
meteo.es es otro proyecto en el que he trabajado para automatizar gran parte de la publicación y organización de información meteorológica. Combina fuentes como AEMET OpenData, Open-Meteo y RainViewer y tiene cientos de páginas de contenido estructurado. Incluso publica un llms.txt para facilitar que sistemas de IA entiendan el sitio.
Resulta bastante curioso haber pasado de aprender a programar cuando Internet apenas formaba parte de nuestra vida a preparar ahora una web para que también pueda ser interpretada por modelos de lenguaje.
También he construido spy on web, que cruza dominios, direcciones IP, nameservers, certificados y determinados identificadores para encontrar relaciones entre sitios web. Surgió porque necesitaba recuperar una funcionalidad que ya no encontraba de forma suficientemente fiable en las herramientas que utilizaba.
Esta última tiene algo especialmente divertido. Su viejo <title> todavía contiene una sucesión de términos de otra época: Ajax, Ruby on Rails, PHP, MySQL, ASP, Java, Perl, CGI, Linux, Windows… y Delphi.
He acabado regresando a Delphi aunque sea dentro de una etiqueta HTML.
Cuando una idea termina en la App Store
La Inteligencia Artificial también me ha permitido entrar en un terreno en el que antes probablemente no habría invertido el tiempo necesario: las aplicaciones nativas.
DocProtect (para MacOS, iOS y Android) nació para una necesidad muy concreta: poder preparar documentos que hay que enviar a terceros añadiendo marcas de agua o ocultando información sensible. El procesamiento se realiza en el dispositivo. Algo que existe, no he inventado nada, pero me apetecía crear mi propia versión gratis.
Con Files.co PDF Suite (para MacOS y Windows) he seguido una filosofía parecida. Muchas operaciones sobre PDF pueden ejecutarse localmente mediante WebAssembly, sin que los documentos tengan que viajar a un servidor para ser procesados.
Mbox Viewer Pro (para MacOS y Windows) lleva la idea de mboxShell a una aplicación gráfica para macOS y Windows. La filosofía sigue siendo bastante sencilla: trabajar offline una copia de seguridad de un mbox, en modo lectura y sin convertir un archivo privado de correo en un fichero que haya que subir a la nube.
Pero quizá el proyecto que mejor representa todo este reencuentro sea iSkitch.
Utilicé Skitch durante años. Evernote retiró en 2016 las versiones para iOS, Android y Windows, mientras que la edición de Mac continuó disponible. El problema es que su última actualización en la Mac App Store data de julio de 2020.
Así que terminé construyendo mi propia alternativa.
iSkitch es una aplicación nativa para macOS, ocupa alrededor de 1,8 MB y ofrece herramientas de anotación, flechas, texto, formas, pixelado y desenfoque.
Hace unos años probablemente habría pensado que desarrollar, traducir, empaquetar y publicar una alternativa nativa era demasiado trabajo para una necesidad tan concreta.
Ahora la ecuación ha cambiado.
Y precisamente por eso aparece un problema nuevo.
Producir más código no significa producir mejor software
Los datos disponibles sobre programación asistida por IA son bastante menos triunfalistas de lo que podría parecer viendo la velocidad a la que se están adoptando estas herramientas.
La encuesta de desarrolladores de Stack Overflow de 2025 encontró que el 84 % utilizaba o tenía previsto utilizar herramientas de IA. Sin embargo, solo un 3,1 % declaraba confiar mucho en la precisión de sus resultados y un 46 % desconfiaba activamente.
La principal frustración, citada por un 66 %, eran las soluciones que están «casi bien».
Ese «casi» me parece una descripción magnífica del problema.
Un estudio de METR publicado en 2025 añadió un resultado todavía más incómodo. Dieciséis desarrolladores experimentados trabajando sobre repositorios que conocían bien esperaban que la IA los hiciera un 24 % más rápidos. En aquel experimento terminaron tardando un 19 % más.
Lo interesante es que después seguían creyendo que habían sido aproximadamente un 20 % más rápidos.
METR ha actualizado posteriormente sus conclusiones y advierte de que esos resultados no deben generalizarse. La adopción ha cambiado rápidamente y los propios investigadores consideran probable que sus mediciones infravaloren parte del beneficio actual.
Mi caso, además, es casi el opuesto al estudiado inicialmente por METR.
No estoy intentando que un agente comprenda de repente un repositorio gigantesco en el que llevo diez años trabajando. Muchos de mis proyectos empiezan desde cero, con un objetivo muy delimitado y una arquitectura que puedo adaptar desde el primer día al trabajo con agentes.
Ahí la inteligencia artficial me está resultando extraordinariamente productiva.
Pero productividad y calidad siguen sin ser sinónimos.
DORA lo resumió muy bien en su investigación sobre desarrollo asistido por IA: la Inteligencia Artificial funciona como un amplificador. Un proceso ordenado puede hacerse mejor; uno desordenado puede producir desorden a mayor velocidad.
El código compila. Ahora hay que comprobar si es seguro
La seguridad es probablemente la parte en la que menos margen existe para dejarse llevar por la sensación de velocidad.
Veracode ha probado más de 150 modelos en tareas de programación y encontró una tasa de aprobado de seguridad del 55 %, pese a que la corrección sintáctica superaba ampliamente el 95 %.
Ese contraste debería estar pegado al monitor de cualquiera que utilice agentes.
El código sintácticamente correcto ya no es el problema. El seguro, sí.
Hay riesgos menos evidentes. Una investigación presentada en USENIX Security estudió 576.000 muestras generadas por 16 modelos y encontró más de 205.000 nombres únicos de paquetes inexistentes inventados por los modelos.
El peligro no es únicamente que una IA se invente una dependencia. Algunos nombres se repiten. Si un atacante registra uno de esos paquetes imaginarios, puede convertir una alucinación predecible en un ataque contra la cadena de suministro.
GitGuardian encontró además 28,65 millones de nuevos secretos expuestos en commits públicos de GitHub durante 2025 y miles dentro de configuraciones MCP públicas.
Por eso intento tratar al agente como lo que es: una herramienta extremadamente capaz a la que no se debe conceder confianza ilimitada.
Las dependencias se comprueban. Los secretos se escanean. Los tests se ejecutan. El código sensible se revisa. Los permisos se limitan. Y las reglas que deben cumplirse siempre no deberían depender únicamente de que el modelo recuerde una frase escrita en un fichero Markdown.
La velocidad cambia el proceso, pero no elimina la ingeniería.
El problema que no tenía hace 30 años: saber qué no construir
Hay una consecuencia de todo esto que me está resultando incluso más interesante que la propia programación.
Tengo demasiadas ideas que ahora son técnicamente posibles. Y poco tiempo en mis fines de semana para llevarlas a cabo.
Antes existía un filtro natural. Una idea podía parecer buena, pero si requería tres meses de desarrollo moría antes de empezar. Ahora ese filtro se ha debilitado muchísimo.
Y eso puede ser peligroso.
Porque crear la primera versión cuesta cada vez menos, pero mantener veinte proyectos sigue costando más que mantener cinco. Hay dominios, actualizaciones, certificados, dependencias, tiendas de aplicaciones, soporte, traducciones, documentación, seguridad y usuarios.
La Inteligencia Artificial reduce el coste de creación. No convierte la atención humana en infinita.
GenPic utilizaba inteligencia artificial para transformar fotografías en retratos con decenas de estilos. El usuario obtenía una vista previa gratuita con marca de agua y solo tenía que pagar si quería descargar el resultado final.
Funcionaba técnicamente.
El problema era el producto.
Una vista previa gratuita suficientemente buena ya podía servir para enseñársela a los amigos o compartir la broma por WhatsApp. En cierto modo GenPic competía contra su propia versión gratuita.
Así que he decidido dejar de aceptar nuevos retratos y compras (aunque seamos francos he vendido un total de 0 euros).
Hace unos años probablemente habría mantenido el proyecto durante más tiempo simplemente porque ya había invertido horas en él. Ahora intento verlo de otra manera.
El desperdicio no es lo que ya se ha gastado. El desperdicio puede ser el siguiente minuto dedicado a algo que ya no merece ese minuto.
La idea conecta con los kill criteria que Annie Duke desarrolla en Quit: definir de antemano qué condiciones justifican seguir invirtiendo tiempo y cuáles deberían obligar a parar.
Me parece una disciplina especialmente importante ahora que construir software es tan barato.
Mi experiencia con Claude Code no me ha llevado a pensar que todo el mundo pueda convertirse mágicamente en desarrollador ni que los programadores hayan dejado de ser necesarios. Más bien me ha devuelto algo que había perdido durante años: la capacidad de convertir una idea pequeña en software real sin que el coste inicial la mate.
Eso es extraordinariamente divertido.
También obliga a aprender otra habilidad.
Hace treinta años el reto era conseguir que aquello que tenía en la cabeza cupiera en memoria, compilara y funcionara. Hoy puedo levantar proyectos que entonces me habrían parecido imposibles para una sola persona.
Mi escasez ya no está en las herramientas.
Está en decidir dónde merece la pena utilizarlas.
Y quizá ese sea el aprendizaje más importante de esta vuelta al código: he pasado de preguntarme si soy capaz de construir algo a preguntarme si debería construirlo.
Preguntas frecuentes
¿Se puede volver a programar después de muchos años gracias a la Inteligencia Artificial?
Los agentes de programación reducen mucho el esfuerzo necesario para recuperar conocimientos y trabajar con lenguajes o frameworks nuevos. Aun así, entender arquitectura, datos, seguridad y lógica sigue siendo muy importante para detectar cuándo el código generado está equivocado.
¿Qué diferencia hay entre Claude Code y un autocompletado tradicional?
Claude Code puede trabajar sobre un proyecto completo: leer y modificar varios archivos, ejecutar comandos y tests y seguir instrucciones de desarrollo. Eso permite delegar tareas más amplias que completar unas líneas de código.
¿Es seguro utilizar código generado por inteligencia artificial?
No debe darse por seguro simplemente porque compile o pase pruebas funcionales. Estudios de seguridad han encontrado vulnerabilidades, dependencias inexistentes y exposición de secretos, por lo que siguen siendo necesarios revisión, análisis de seguridad y controles automáticos.
¿Cuál es el mayor problema de programar más rápido con IA?
En mi caso ya no es conseguir construir el software, sino seleccionar proyectos y mantenerlos. La reducción del coste inicial hace mucho más fácil comenzar ideas que después compiten por tiempo, mantenimiento y atención.
Fuentes:
Dossier interno de trabajo y comprobaciones de proyectos propios, actualizado el 6 de septiembre de 2026.
Embarcadero, documentación e historia de Turbo Pascal, Delphi y RAD Studio. A 6 de septiembre de 2026, RAD Studio 13.1 está disponible y 13.2 sigue anunciada como próxima versión.
Anthropic, documentación oficial de Claude Code, CLAUDE.md, Agent Skills y Model Context Protocol.
OpenAI, documentación y anuncio de Codex.
Stack Overflow Developer Survey 2025.
Google Cloud / DORA, State of AI-Assisted Software Development y ROI of AI-assisted Software Development.
METR, estudio sobre productividad de desarrolladores con IA y actualización de febrero de 2026.
Veracode, GenAI Code Security Report.
USENIX Security, investigación sobre alucinaciones de paquetes en código generado por modelos.
La semana pasada escribía sobre energía, inteligencia artificial y centros de datos y llegaba a una idea que cada vez me parece más importante: el problema no es únicamente producir electricidad, sino conseguir tenerla donde y cuando hace falta. El nuevo borrador del Gobierno de España para regular los centros de datos vuelve a poner esa cuestión encima de la mesa, pero desde otro ángulo. Y después de leerlo sigo pensando que comparto bastante el objetivo, pero tengo muchas más dudas sobre el camino elegido.
Las claves de la nueva regulación en 30 segundos
Los nuevos centros de datos de 1 MW o más tendrían que cubrir con nueva generación renovable al menos el 80 % de su consumo en cada hora.
España tiene abundante generación renovable, pero también congestiones, limitaciones de red y vertidos de energía.
Hay 11,8 GW de nueva demanda con acceso concedido en la red de transporte que todavía no están en servicio.
El Gobierno prevé invertir 13.590 millones de euros hasta 2030 en la red de transporte.
La duda es si estamos intentando solucionar mediante regulación un problema que también exige mucha más infraestructura.
Lo primero es recordar que no hay todavía una norma aprobada. El proyecto de Real Decreto está en audiencia pública hasta el 04/09/2026 y, por tanto, puede modificarse. ¡Espero que lo modifiquen por el bien del sector!
Y tampoco creo que pedir sostenibilidad a los centros de datos sea el problema.
Si España va a incorporar varios gigavatios de nueva demanda eléctrica para infraestructura cloud e inteligencia artificial, me parece razonable que esa demanda contribuya a financiar nueva generación. También me parece razonable exigir eficiencia energética, controlar el consumo de agua y evitar que alguien reserve cientos de megavatios durante años para un proyecto que nunca llega a construirse.
Mi duda es otra.
¿Estamos poniendo el foco suficiente en la red eléctrica?
Tenemos renovables que algunas veces no podemos aprovechar
España ha hecho una inversión enorme en generación renovable y va a seguir haciéndola.
Pero producir electricidad y conseguir que llegue al lugar donde alguien quiere consumirla son dos problemas diferentes.
El sistema eléctrico tiene que mantener permanentemente el equilibrio entre generación y demanda. También tiene límites físicos: las líneas y subestaciones pueden transportar una determinada cantidad de electricidad y aparecen congestiones cuando la capacidad disponible no permite trasladar toda la generación hacia donde existe demanda.
El resultado es algo que a primera vista parece absurdo: puede existir energía renovable disponible y, aun así, ser necesario reducir su producción.
La Comisión Nacional de los Mercados y la Competencia (CNMC) habla expresamente de minimizar los vertidos renovables derivados de congestiones, mientras que Red Eléctrica gestiona restricciones técnicas cuando la producción prevista no puede integrarse manteniendo las condiciones de seguridad del sistema.
No significa que España esté desperdiciando permanentemente cantidades enormes de electricidad que simplemente podríamos entregar mañana a los centros de datos. El problema eléctrico es bastante más complejo.
Pero sí demuestra algo importante: añadir generación no resuelve por sí solo el problema de añadir nueva demanda.
Hace falta red.
Hace falta almacenamiento.
Hace falta capacidad de transformación.
Y hace falta que generación y consumo estén conectados geográfica y temporalmente.
Los números ayudan a entender la escala.
Red Eléctrica señalaba en febrero de este año 2026 que en la red de transporte existían permisos de acceso concedidos para unos 129 GW de generación eólica y fotovoltaica, 16 GW de almacenamiento y 19 GW de demanda.
Además desde 2022 se habían concedido 11,8 GW de nueva capacidad de acceso para demanda que todavía no había entrado en servicio.
Es decir, el cuello de botella no puede analizarse únicamente preguntando cuántos paneles solares podemos instalar.
El 80 % renovable no me preocupa tanto como el «hora a hora»
Aquí llegamos a la parte que más dudas me genera del nuevo Real Decreto.
El proyecto plantea que los nuevos centros de datos con al menos 1 MW de potencia de acceso cubran un mínimo del 80 % de su consumo mediante nueva generación renovable.
Pedir que esa nueva demanda venga acompañada de nueva generación renovable me parece razonable.
Si alguien va a incorporar 100 MW de nueva demanda durante los próximos 15 o 20 años, tiene sentido pedirle que ayude a financiar nueva capacidad de generación mediante autoconsumo o contratos de compraventa de electricidad a largo plazo, los conocidos PPA.
El salto está en exigir además correlación horaria.
No bastaría con producir durante el año tanta electricidad renovable como corresponda al consumo contratado.
Habría que demostrar que en cada hora el 80 % del consumo está respaldado por generación renovable producida durante esa misma hora.
Una planta solar puede producir muchísimo a las dos de la tarde.
A las tres de la mañana produce cero.
El centro de datos sigue funcionando. Son infraestructuras que operan 24×7 sin poder parar un segundo su operación.
Se puede combinar solar con eólica. Se puede añadir almacenamiento. Se pueden contratar diferentes instalaciones y utilizar la red para completar el suministro.
Todo eso es técnicamente posible.
Pero tiene un coste.
Y aquí creo que deberíamos preguntarnos si queremos utilizar la regulación para incentivar esa evolución o exigir desde el primer momento que cada nuevo proyecto resuelva por sí mismo buena parte de un problema estructural del sistema eléctrico.
Vamos a gastar 13.600 millones en la red porque sabemos que falta red
Hay otro dato que me parece especialmente relevante.
El objetivo incluye precisamente integrar más renovables, electrificar la economía, atender nueva demanda, mejorar interconexiones y reforzar la red.
Por tanto, el diagnóstico ya lo tenemos.
Necesitamos mucha más infraestructura eléctrica.
Y aquí es donde creo que los centros de datos podrían verse también como parte de la solución y no únicamente como nueva demanda que hay que controlar.
Estamos hablando de una industria dispuesta a comprometer inversiones de cientos o miles de millones durante décadas y cuyo principal recurso es precisamente la electricidad.
Quizá deberíamos estudiar mecanismos que permitan que parte de esa inversión privada contribuya también a acelerar redes, almacenamiento, subestaciones y nueva generación allí donde sea necesario.
No estoy hablando de entregar la planificación eléctrica a los operadores de centros de datos ni de que quien pague más se quede con la red.
Estoy hablando de alinear incentivos.
Si para atender varios gigavatios de nueva demanda España necesita invertir miles de millones en infraestructura eléctrica, parece razonable preguntarse cómo conseguir que quienes van a utilizar una parte importante de esa nueva capacidad participen también en hacerla posible.
Eso me parece más interesante que limitarnos a añadir otra obligación al BOE.
Podemos convertir nuestra principal ventaja en una barrera
España tiene algo que muchos países europeos querrían tener.
Sol.
Viento.
Suelo.
Conectividad internacional y Cables submarinos.
Un mercado eléctrico conectado con Europa.
Y un enorme interés por construir aquí infraestructura para cloud e inteligencia artificial.
Precisamente por eso deberíamos tener cuidado.
Los más de 12 GW de derechos concedidos a centros de datos no significan que vayan a construirse 12 GW.
Un permiso eléctrico no es un centro de datos.
El dinero puede irse.
Un operador puede construir en Madrid, Aragón, Andalucía o Castilla-La Mancha, pero también puede hacerlo en Portugal, Francia, Italia o los países nórdicos.
Y la decisión no depende únicamente del precio del megavatio hora.
Importan la disponibilidad eléctrica, los plazos, la fiscalidad, la conectividad y, sobre todo, la previsibilidad.
El borrador añade además otros requisitos exigentes: un PUE máximo provisional de 1,15, que mide la relación entre toda la electricidad que consume el centro de datos y la que utilizan directamente sus equipos informáticos, y un WUE máximo de 0,1, que mide la eficiencia en el uso del agua. A eso se suman la nueva generación renovable, la correlación horaria y las obligaciones relacionadas con soberanía digital europea.
Cuanto más se acerca el PUE a 1, menos energía se dedica a refrigeración y otros sistemas auxiliares, así que un límite de 1,15 obliga a operar con niveles de eficiencia bastante exigentes.
Por separado muchas de estas medidas pueden tener sentido.
El problema puede ser la suma.
Porque llega un momento en el que quizá no estamos seleccionando los centros de datos más eficientes.
Estamos seleccionando únicamente a quienes tienen suficiente tamaño y capacidad financiera para gestionar toda esa complejidad.
Y paradójicamente eso puede favorecer a los mayores hiperescalares, muchos de ellos empresas estadounidenses, frente a operadores europeos y nacionales más pequeños.
No bajaría las exigencias. Cambiaría cómo las aplicamos
No creo que España deba entrar en una carrera para ver quién pone menos requisitos ambientales.
Sería un error.
Seguiría exigiendo que la nueva demanda venga acompañada de nueva generación renovable.
Mantendría objetivos exigentes de PUE y WUE.
Mantendría las obligaciones de transparencia.
Y exigiría compromisos reales para evitar que alguien reserve capacidad durante años sin construir nada.
Pero estudiaría una implantación progresiva de la correlación horaria.
Por ejemplo, podría empezarse exigiendo que el consumo anual esté respaldado por nueva generación renovable mediante PPA y elevar después el porcentaje de correlación horaria conforme aumenten el almacenamiento, las redes y las posibilidades reales del mercado.
También podría convertirse en un criterio para repartir capacidad.
Si hay dos proyectos compitiendo por 100 MW y uno puede demostrar un 80 % de correlación horaria mientras el otro alcanza un 40 %, parece razonable favorecer al primero.
Eso genera un incentivo.
Convertir directamente el 80 % hora a hora en una condición de entrada genera una barrera.
Y añadiría otra variable que echo de menos en muchas discusiones sobre centros de datos: qué deja cada megavatio en España.
No todos los centros de datos son iguales.
Un proyecto que atrae empresas de inteligencia artificial, ingenieros, investigación, servicios de infraestructura cloud europeos y capacidad de computación disponible para nuestras empresas aporta algo diferente a un edificio que simplemente consume electricidad y presta la mayor parte de sus servicios fuera.
Si la capacidad eléctrica es escasa, quizá deberíamos empezar a elegir proyectos también por eso.
Porque estamos decidiendo mucho más que dónde colocar unos servidores.
El riesgo es resolver con regulación lo que también necesita infraestructura
España tiene delante una oportunidad enorme.
La inteligencia artificial está convirtiendo la electricidad, los centros de datos y la capacidad de computación en política industrial.
Al mismo tiempo necesitamos electrificar transporte, industria y hogares.
No será sencillo.
Pero precisamente por eso creo que deberíamos evitar una discusión demasiado simple donde los centros de datos aparecen únicamente como consumidores gigantes a los que hay que poner límites.
Pueden financiar renovables. Y porque no también energía nuclear, que es posible siga formando parte de nuestro futuro con seguridad.
Pueden contratar energía durante décadas.
Pueden ayudar a justificar almacenamiento.
Pueden atraer inversión hacia nuevas infraestructuras.
Y pueden convertir electricidad producida en España en servicios digitales exportados desde España.
La semana pasada terminaba hablando de la necesidad de disponer de energía cuando realmente se necesita.
Después de leer este borrador añadiría otra idea:
no basta con producir más electricidad renovable y tampoco basta con regular quién puede consumirla. Hay que construir la infraestructura necesaria para conectar ambas cosas.
España ya sabe que necesita hacerlo. Los 13.600 millones previstos para la red hasta 2030 lo demuestran.
La cuestión es si vamos suficientemente rápido.
Porque puede darse una paradoja bastante absurda.
Construimos aquí la solar.
Construimos aquí la eólica.
Tenemos momentos en los que incluso necesitamos reducir generación renovable por las limitaciones del sistema.
Y después hacemos tan complejo conectar nueva demanda que los servidores, las GPU, los ingenieros y la inversión tecnológica terminan unos cientos de kilómetros más allá de nuestra frontera.
Eso no sería una política energética especialmente inteligente.
Ni tampoco una gran política digital.
España necesita centros de datos más eficientes y necesita mucha más infraestructura eléctrica.
Quizá deberíamos dedicar algo menos de tiempo a enfrentar ambas cosas y bastante más a conseguir que crezcan juntas.
En determinadas situaciones puede ser necesario reducir generación renovable por congestiones, restricciones técnicas o falta de capacidad para integrarla de forma segura. Eso no significa que toda esa electricidad pudiera trasladarse automáticamente a un centro de datos: la ubicación, la hora, la red y el almacenamiento son determinantes.
¿Cuánto quiere invertir España en la red eléctrica?
La propuesta de planificación eléctrica con horizonte 2030 contempla una inversión de 13.600 millones de euros en la red de transporte, destinada entre otros objetivos a integrar renovables y atender nueva demanda.
¿Qué exige el borrador a los nuevos centros de datos?
Entre otras medidas, plantea para instalaciones de al menos 1 MW un 80 % de suministro respaldado por nueva generación renovable y correlación horaria. También establece requisitos de eficiencia energética, agua y soberanía digital.
¿Los centros de datos podrían ayudar al sistema eléctrico?
Su demanda estable y sus contratos a largo plazo pueden contribuir a financiar nueva generación, almacenamiento e infraestructura asociada. Cómo integrar esa inversión privada con la planificación de la red es una cuestión diferente que requiere regulación y coordinación pública.
