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.
Llevo bastante tiempo escribiendo sobre centros de datos, cloud e inteligencia artificial y cada vez tengo más clara una cosa: hablamos muchísimo de GPU/NPU/TPU, modelos, refrigeración, refrigeración líquida y nuevos centros de datos, pero bastante menos de aquello que permite que todo funcione.
La electricidad.
Y cuanto más crece la inteligencia artificial, menos sentido me parece que tenga plantear el debate energético como una competición entre nuclear y renovables. No creo que la pregunta sea cuál de las dos debe ganar. La pregunta importante es otra: ¿cómo vamos a garantizar toda la electricidad que necesitaremos, cuando la necesitemos y a un precio razonable?
Porque un centro de datos necesita electricidad las 24 horas, pero también un hospital, una fábrica, una vivienda, un tren, una red de telecomunicaciones o una ciudad.
La Inteligencia Artificial simplemente está haciendo mucho más visible un problema que ya estaba delante de nosotros.
Las claves de energía, nuclear e IA en 20 segundos
Los centros de datos podrían consumir alrededor de 945 TWh anuales en 2030, más del doble que en 2024.
Solar y eólica crecerán con fuerza, pero su producción depende de las condiciones meteorológicas.
El mundo mantiene más de 400 reactores nucleares en funcionamiento y construye decenas más.
España conserva siete reactores y acaba de prolongar Almaraz hasta 2030.
El reto será combinar generación, almacenamiento y redes para garantizar electricidad disponible cuando exista demanda.
Estamos entrando en la era de la electricidad
Hay algo que va mucho más allá de ChatGPT, Claude, Mistral o de los nuevos centros de datos.
La Agencia Internacional de la Energía (AIE) espera que el consumo mundial de electricidad crezca una media del 3,6 % anual entre 2026 y 2030. En 2025 el planeta consumió aproximadamente 28.200 TWh y para 2030 podríamos alcanzar los 33.600 TWh.
Y la Inteligencia Artificial es solo una parte. La que quizás más energía podrá demandar.
Estamos electrificando vehículos, climatización, procesos industriales y otras actividades que antes dependían directamente de combustibles fósiles. Al mismo tiempo queremos fabricar más semiconductores, desarrollar nuevas industrias y construir centros de datos cada vez mayores.
La propia AIE habla ya de una nueva “era de la electricidad”.
Los centros de datos son especialmente interesantes porque concentran enormes cantidades de consumo en ubicaciones concretas. La AIE estima que su demanda mundial podría superar los 945 TWh en 2030, más del doble que actualmente. Estados Unidos y China concentrarán buena parte de ese crecimiento.
Eso cambia bastante las reglas del juego.
Se puede tener dinero para comprar 100.000 GPU y disponer del terreno para construir un centro de datos, pero si la red eléctrica no puede entregar 500 MW donde hacen falta, todo lo demás sirve de poco.
Cada vez estoy más convencido de que la próxima gran limitación de la IA puede no estar en los chips, sino en los megavatios.
Las renovables son imprescindibles, pero el sol y el viento no obedecen a la demanda
España tiene una posición privilegiada en energía renovable. Tenemos sol, viento, territorio y una industria que durante años ha adquirido experiencia construyendo grandes proyectos renovables.
Sería absurdo no aprovecharlo.
Y las cifras mundiales van precisamente en esa dirección. La AIE espera que las renovables crezcan alrededor de un 8 % anual hasta 2030. Solo la solar fotovoltaica podría añadir más de 600 TWh de generación cada año durante este periodo.
Pero existe una diferencia que a veces desaparece de la conversación: capacidad instalada no significa electricidad disponible permanentemente.
Un panel solar produce cuando existe radiación suficiente. Un aerogenerador depende del viento.
No es una crítica a esas tecnologías. Es simplemente su naturaleza.
El problema aparece cuando la demanda no coincide con la producción.
Podemos tener una enorme capacidad fotovoltaica instalada y necesitar electricidad a las diez de la noche. Podemos tener miles de aerogeneradores y atravesar varios días con una producción eólica mucho menor de lo esperado.
Y la demanda sigue ahí.
Por eso necesitamos almacenamiento, centrales hidroeléctricas, bombeo, mejores interconexiones, gestión de demanda y redes eléctricas mucho más potentes.
Pero también necesitamos generación firme.
Y ahí vuelve inevitablemente la conversación sobre la energía nuclear.
Más de 400 reactores funcionando y otros 77 en construcción
A veces en España se tiene la sensación de que la energía nuclear pertenece al pasado. Cuando se mira el mapa mundial la imagen es bastante diferente.
Los últimos datos del Organismo Internacional de Energía Atómica (OIEA) contabilizan 417 reactores nucleares en operación en 31 países, con aproximadamente 380 GW de capacidad instalada. Otros 77 reactores se encuentran en construcción.
Estados Unidos continúa siendo la mayor potencia nuclear mundial, con 94 reactores operativos. Francia operó 57 durante 2025 y obtuvo aproximadamente el 68 % de su electricidad de esta fuente. China tenía 58 reactores que produjeron electricidad durante 2025 y está protagonizando buena parte de la expansión mundial.
La AIE espera que la generación nuclear mundial siga aumentando hasta 2030, con China aportando aproximadamente el 40 % del crecimiento previsto. Japón está recuperando reactores y otros países asiáticos están construyendo nuevas centrales.
Mientras tanto, las grandes tecnológicas también han empezado a mirar hacia esta fuente.
Microsoft ha respaldado mediante un contrato eléctrico a largo plazo la recuperación de 835 MW de capacidad nuclear en Pensilvania. Google trabaja con Kairos Power para desplegar reactores avanzados y Meta ha cerrado varios acuerdos relacionados con capacidad nuclear existente y futura.
No creo que Microsoft, Google o Meta se hayan convertido repentinamente en activistas nucleares.
Necesitan electricidad. Mucha. Y necesitan saber que estará disponible.
Nuclear sí, pero con una condición que no admite discusión: seguridad
Defender que la nuclear forme parte de la combinación energética no significa ignorar sus problemas.
Una central nuclear exige niveles extraordinariamente altos de seguridad durante su diseño, construcción, funcionamiento, mantenimiento y posterior desmantelamiento.
Y así debe ser.
Chernóbil y Fukushima forman parte de la historia de esta tecnología y sería absurdo hablar de energía nuclear intentando esconder sus accidentes.
Precisamente por las consecuencias potenciales de un fallo grave, la seguridad nuclear tiene que estar por encima de las necesidades económicas, industriales o tecnológicas.
Prolongar la vida de una central tampoco debería ser una decisión política tomada simplemente porque necesitamos más electricidad. Tiene que existir una evaluación técnica independiente que determine que puede continuar funcionando con seguridad.
Una central nuclear con 40 años no tiene que cerrarse automáticamente porque haya alcanzado una fecha determinada, pero tampoco debería continuar funcionando simplemente porque resulte conveniente.
Debe hacerlo si técnicamente es seguro.
Ese matiz me parece esencial.
España decidió caminar hacia el cierre mientras otros países miraban en otra dirección
Y aquí llegamos a España.
Nuestro país mantiene siete reactores nucleares operativos, que en 2025 aportaron aproximadamente el 18,9 % de la electricidad nacional, según los datos del OIEA.
Durante los últimos años España había establecido una dirección bastante clara: cierre progresivo del parque nuclear entre 2027 y 2035.
Mientras tanto el contexto internacional ha ido cambiando.
China construye reactores. Estados Unidos intenta conservar y recuperar capacidad. Japón ha reactivado instalaciones. Francia mantiene la nuclear como una pieza central de su sistema eléctrico. Otros países están estudiando pequeños reactores modulares (SMR).
La AIE resume bastante bien el cambio: la energía nuclear está recuperando importancia estratégica en numerosas economías avanzadas, entre otras cosas mediante extensiones de vida de reactores existentes.
España parecía remar en dirección contraria.
Pero este mismo agosto hemos visto un movimiento interesante.
El Gobierno ha autorizado que Almaraz I y II continúen funcionando hasta el 8 de junio de 2030. La ampliación es de 31 meses para una unidad y 19 para la otra.
Y me parece especialmente interesante leer los argumentos utilizados por el propio Ministerio para la Transición Ecológica.
Habla de incertidumbre en los mercados energéticos internacionales, dependencia del gas, posibles picos de precios y seguridad de suministro. Al mismo tiempo insiste en continuar desplegando renovables y almacenamiento.
Es decir, estamos empezando a hablar precisamente de lo que deberíamos haber hablado desde el principio.
No de nuclear o renovables.
De nuclear y renovables, junto con almacenamiento, redes e interconexiones.
Por ahora el Gobierno mantiene 2035 como fecha para el cierre completo del parque nuclear español. Quizá sea la decisión correcta. Quizá dentro de unos años descubramos que fue demasiado pronto.
El tiempo lo dirá.
Pero creo que sería razonable que las decisiones futuras dependiesen más de la situación tecnológica, energética y de seguridad que exista entonces que de calendarios establecidos muchos años antes.
El problema tampoco son solamente los centros de datos
Hay además algo que me preocupa de cómo estamos enfocando esta discusión.
Resultaría muy sencillo convertir los centros de datos en culpables del crecimiento del consumo eléctrico.
“Estamos gastando toda la electricidad en inteligencia artificial”.
No creo que esa sea una lectura correcta.
Si Europa quiere electrificar el transporte, descarbonizar la industria, fabricar más dentro de sus fronteras, desarrollar inteligencia artificial, atraer centros de datos y reducir su dependencia energética exterior, necesitará mucha más electricidad.
La solución no debería ser impedir que aparezca nueva demanda.
Debería ser aumentar la oferta y mejorar las infraestructuras.
Y hacerlo de forma sostenible.
La propia AIE calcula que las renovables cubrirán aproximadamente la mitad del crecimiento mundial de electricidad destinada a centros de datos hasta 2035. La nuclear también aumentará su aportación y, lamentablemente desde el punto de vista de las emisiones, el gas continuará teniendo bastante peso.
En Europa la combinación puede ser especialmente interesante: la AIE estima que renovables y nuclear podrían proporcionar conjuntamente el 85 % de la electricidad consumida por los centros de datos europeos en 2030.
Quizá ahí tengamos una pista.
No necesitamos elegir una única tecnología capaz de resolver todos nuestros problemas energéticos.
Necesitamos mucha solar donde tenga sentido. Mucha eólica. Hidráulica y bombeo. Baterías. Redes eléctricas reforzadas. Mejores interconexiones europeas. Gestión inteligente de la demanda.
Y probablemente también nuclear mientras pueda operar con seguridad y resulte necesaria para garantizar el sistema.
Porque la transición energética no debería medirse solamente por cuántos GW instalamos.
También debería medirse por nuestra capacidad para encender la luz, una fábrica, un hospital o un centro de datos cualquier día del año y a cualquier hora, haga sol, llueva, sople el viento o no.
Ese es para mí el verdadero debate energético que está poniendo encima de la mesa la inteligencia artificial.
Preguntas frecuentes
¿Cuántos reactores nucleares hay actualmente en el mundo?
El OIEA contabiliza 417 reactores en operación en 31 países, con cerca de 380 GW de potencia instalada. Además, registra 77 reactores en construcción.
¿Cuántas centrales nucleares funcionan en España?
España cuenta con siete reactores nucleares operativos. En 2025 produjeron alrededor del 18,9 % de la electricidad del país.
¿España ha cancelado el cierre de sus centrales nucleares?
No. El Gobierno ha ampliado la autorización de explotación de Almaraz I y II hasta junio de 2030, pero mantiene actualmente 2035 como fecha de cierre completo del parque nuclear.
¿Las renovables pueden alimentar los centros de datos de IA?
Sí y tendrán un peso creciente. El desafío está en combinar su producción variable con almacenamiento, redes, interconexiones y fuentes de generación gestionables que permitan garantizar el suministro durante las 24 horas.
