I was “just” a CMS developer.
Then came AI

Soy desarrollador y he hecho CMS.

He pasado buena parte de los últimos veinte años trabajando con ellos. CMS solía significar WordPress, y WordPress significaba webs. Es una asociación comprensible, pero solo cuenta una parte del trabajo.

Un título, una foto y un botón «Publicar» pueden ser todo lo que se ve. Detrás puede haber redacciones, traducciones, permisos, integraciones y años de contenido que deben sobrevivir a la siguiente actualización. Trabajar en esos problemas es lo que más me ha enseñado.

Hoy la IA permite a muchas más personas construirse una aplicación, una herramienta de gestión o incluso su propio CMS. Me entusiasma. Y reconozco en esos proyectos muchos de los problemas en los que llevamos años trabajando.

Cuanto más fácil resulta generar software, más útil es saber qué debe poder hacer ese software a lo largo del tiempo. De esa experiencia quiero hablar.

El software empieza por quien va a usarlo

Quien abre un CMS suele tener un trabajo que terminar: publicar un artículo, actualizar un catálogo, organizar un evento. Nuestro modelo de datos debe encajar con ese trabajo. Un campo obligatorio puede tener todo el sentido en la base de datos y ser imposible de rellenar cuando alguien apenas está esbozando un contenido. Tarde o temprano escribirá «por definir», y la restricción habrá producido peores datos.

Es una lección de producto que enseguida se convierte en arquitectura: distinguir un borrador de un contenido publicable, pedir la información en el momento adecuado, hacer comprensible el error y posible la recuperación.

En el software empresarial, quien compra y quien usa suelen ser personas distintas. Un empleado puede convivir años con una interfaz incómoda. En productos de consumo, más fáciles de abandonar, esa misma dificultad puede costar un cliente. Muchos CMS están a medio camino: herramientas de trabajo en manos de personas con capacidades, hábitos y paciencia muy diferentes. Han sido una buena escuela para combinar estructura y facilidad de uso.

Esa familiaridad se reconoce en las aplicaciones actuales. Un CRM, un gestor inmobiliario, un panel administrativo: filtro información, elijo cómo verla y hago algo. Consulta, vista, acción. La tabla, el calendario y el kanban pueden ser tres maneras de trabajar con los mismos datos.

Esta gramática también tiene raíces en las bases de datos y los sistemas de gestión. Los CMS la han practicado durante años ante personas que debían usarla a diario sin conocer las claves foráneas. Ahora la IA permite generar una vista para una sola tarea, quizá destinada a durar diez minutos. Debajo, el significado de los datos y las reglas para modificarlos deben seguir siendo reconocibles.

Anatomía de un CMS

Tomemos Directus, porque trabajo con él y puedo observarlo de cerca. Decir «una base de datos con API y un panel» es tan acertado como describir un animal como algo con piel y órganos. Para entender qué compramos, reutilizamos o pensamos reconstruir con IA, hay que separar sus responsabilidades.

Empiezo por fuera. La piel es el Data Studio: formularios, vistas y paneles hacen utilizable el sistema. Pero ocultar un campo en el formulario no lo protege en el servidor. El esqueleto es el modelo de datos: tablas y relaciones SQL junto con los metadatos con los que Directus describe campos, interfaces y configuraciones. El significado de «cliente», «proyecto» o «aprobado» debemos establecerlo nosotros. Después abrimos el conejo.

La distinción decisiva es entre lo que Directus sabe hacer y las decisiones que debemos tomar nosotros. Ofrece colecciones, relaciones, permisos, versiones y automatizaciones. Decidir quién puede aprobar un gasto, cuándo un borrador es publicable o cómo reconocer al mismo cliente en dos sistemas exige un modelo de nuestro trabajo. El producto ofrece herramientas para expresarlo; que ese modelo sea correcto sigue siendo responsabilidad nuestra.

Sigamos un cambio concreto: un editor modifica el precio de un producto. El Data Studio recoge el valor; la API recibe la petición; los servicios la ejecutan en el contexto del usuario y los permisos configurados. La base aplica sus restricciones. El historial, si está configurado, conserva el cambio. Un Flow puede iniciar la actualización de un catálogo externo. Son responsabilidades distintas: si ese último servicio no responde, el precio guardado y el visible en otro lugar pueden divergir. Hace falta una regla de recuperación y una forma de detectarlo.

Los límites también importan al ampliar la plataforma. La documentación de servicios pide atención al contexto de autorización, llamado accountability: omitirlo puede otorgar permisos administrativos al servicio.³ Y un campo oculto en el Data Studio no sustituye una política de datos.⁴ El valor de la plataforma depende también de lo bien que respetemos sus límites.

Fuera del animal quedan la operación y el mantenimiento: base de datos y almacenamiento, secretos, copias de seguridad verificadas, supervisión, actualizaciones y compatibilidad con clientes. Podemos delegar una parte en un servicio gestionado, pero debemos saber quién la cubre. Migrar el esquema o restaurar una revisión solo resuelve parte del problema, no un plan completo de recuperación.

Las decisiones de licencia también señalan el coste del conjunto. Directus utiliza hoy la MSCL, una licencia source-available: el código es consultable; su uso depende de las condiciones aplicables.⁵ Quien valore una alternativa debe incluir cuánto costará mantener en el tiempo las responsabilidades que decida asumir.

Facilidad de uso, también fuera del navegador

El mismo cuidado debe llegar a quienes trabajan con código, scripts y automatizaciones. La developer experience, o DevEx, es otra forma de usabilidad: documentación clara, tipos explícitos, comandos previsibles, errores comprensibles. Permite ser precisos y repetir una operación sabiendo qué esperar.

En Directus, esta atención toma formas concretas. El SDK de JavaScript y TypeScript ofrece un cliente componible para API, autenticación y tiempo real, con soporte de tipos del propio esquema.⁶ La CLI de sincronización de entornos permite exportar esquema y configuración, examinar diferencias y aplicarlas a instancias compatibles, también en una pipeline.⁷ El servidor MCP expone datos y operaciones a asistentes de IA mediante el Model Context Protocol, respetando los permisos de la identidad con la que se conectan.⁸

Esto da una libertad concreta: usar el panel, escribir una integración, lanzar un comando o trabajar con el propio agente en el propio entorno. Se puede elegir la interacción y encontrar el mismo modelo de datos, con las autorizaciones necesarias para cada operación. Así, la IA entra en un sistema que ya tiene estructura y reglas.

Para mí, «bonito y cómodo» también incluye un software que una persona pueda orquestar, incluso mediante su agente. Puedo componer un flujo, delegar pasos, comprobar resultados e intervenir. La automatización se convierte en una forma de ejercer más control sobre el trabajo. Una DevEx cuidada lo hace posible hoy.

«Solo es una galería de imágenes»

Tomemos una petición habitual: la imagen principal de un artículo debe convertirse en una galería ordenada. Añadimos miniaturas al formulario y permitimos arrastrarlas. Parece una tarde tranquila.

Pero el modelo pasa de una referencia única a una relación con varias imágenes y un orden. Los artículos existentes deben conservar su foto. API y plantillas deben entender la nueva estructura. Los permisos deben dejar a los editores gestionar también la relación, sin dar acceso indebido a archivos. Y los editores siguen trabajando mientras tanto.

Podemos avanzar por etapas: añadir la relación, convertir las referencias existentes en la primera imagen de cada galería, actualizar las lecturas y retirar el campo antiguo. Durante la transición también hay que decidir cómo tratar las escrituras nuevas: si alguien cambia la imagen antigua tras la primera migración, ese cambio debe llegar a la galería. Un despliegue compatible se diseña también para lo que sucede mientras lo ejecutamos.

Esquema, datos, archivos y código deben funcionar juntos en cada fase del cambio. Pueden evolucionar en momentos distintos si existe un camino que mantenga su compatibilidad.

Por eso promover el esquema de desarrollo a producción y transferir contenidos son operaciones distintas.⁹ Por eso volver al código de ayer puede dejar el sistema roto si entretanto transformamos los datos. Y por eso una copia de la base puede no bastar: si referencia imágenes eliminadas del almacenamiento, hemos recuperado enlaces a algo que ya no existe.

De una galería hemos llegado a la recuperación ante desastres. Hay que saber qué archivos conservar, con qué versiones del código podemos reabrir los datos y cómo reiniciar integraciones sin repetir acciones ya ejecutadas. Un correo enviado o una operación en un servicio externo no retroceden junto con la base de datos.

Aquí entra el taller construido alrededor del CMS: infraestructura, pipelines CI/CD, observabilidad, ensayos de restauración. Sirve para desplegar en un orden preciso, distinguir un permiso incorrecto de un servicio caído y comprobar cuánto trabajo podríamos perder en un incidente. Y están las personas: quién aprueba el cambio, quién interviene, quién sabe por qué existe esa regla extraña.

En welance, nuestra nube y los procesos construidos a su alrededor forman parte de esta experiencia colectiva. Quien ha trabajado con CMS complejos suele llevar consigo toda una manera de trabajar, mucho menos visible que una pantalla.

La IA también puede ayudarnos a escribir migraciones, pruebas y procedimientos de recuperación. La experiencia sirve para reconocer cuáles pedir y entender si las pruebas demuestran lo que nos importa. El prototipo muestra que algo puede funcionar; el trabajo posterior establece en qué condiciones seguirá haciéndolo.

La C significa contenido

Hasta aquí he hablado de artículos y fotografías. Pero un contenido también puede ser un requisito, un inmueble, una disponibilidad, una decisión o la relación entre un proyecto y una persona. Esa apertura siempre me ha interesado en los CMS.

Un sistema suficientemente flexible puede ser la base de un gestor inmobiliario, un CRM o partes de un ERP. Ya ofrece un lugar para describir entidades, relacionarlas, asignar accesos y construir interfaces. Sobre él se añade el conocimiento del dominio: una reserva debe impedir solapamientos incluso si llegan dos solicitudes simultáneas; una decisión contable tiene restricciones que un artículo no tiene.

El CMS me interesa precisamente como contenedor de estas posibilidades. Mucho de lo que llamamos «software de gestión» consiste en estructurar información y permitir que las personas adecuadas actúen sobre ella. Con la IA se suma un interlocutor capaz de leer, proponer y operar. La calidad de la estructura importa aún más.

Cuando la memoria se vuelve operativa

Una memoria compartida se vuelve operativa cuando podemos remontarnos de un dato a su fuente, de una decisión a sus motivos y de una acción a las reglas que la autorizan.

El conocimiento se vuelve racional en la medida en que podemos reconstruirlo y verificarlo. Un movimiento registrado, una estimación y una conclusión del modelo deben seguir siendo distinguibles. Las reglas de cálculo y las conexiones deben poder inspeccionarse. Esta base permite a distintas personas, con distintos agentes, trabajar sobre los mismos hechos y discutir interpretaciones.

Veo una conexión con la LLM Wiki propuesta por Andrej Karpathy: un modelo lee fuentes y mantiene conocimiento persistente mediante síntesis y enlaces que se actualizan con el tiempo.¹¹ En un CMS podemos asociar ese conocimiento a proyectos, responsabilidades y estados: qué requisito está aprobado, quién puede modificarlo, qué tarea depende de él.

Las fuentes pueden ser un documento, una grabación o una fotografía. Las herramientas que las interpretan deben conservar su procedencia para que una persona pueda revisar y corregir la síntesis. El modelo puede cambiar; los datos, las decisiones y las relaciones deben poder permanecer. Así, el sistema pasa a formar parte de la inteligencia de la empresa.

Pasar a la acción requiere autorizaciones precisas. Leer un requisito no da automáticamente derecho a modificar el proyecto o enviar algo a un cliente. Cada conector debe verificar la acción solicitada y utilizar credenciales apropiadas en el servicio externo. MCP ofrece una forma común de conectar herramientas; hay que diseñar la correspondencia entre permisos de distintos sistemas. Incluso una síntesis de documentos confidenciales debe respetar esos límites.¹²

Esa es la evolución que imagino al pensar en un AI Management System, o AI MS: un sistema de gestión donde personas y agentes trabajan sobre la misma memoria operativa. Cada cual interactúa a su manera y las reglas, responsabilidades e historial siguen siendo verificables. Es un nombre de trabajo para una dirección prometedora.

El CMS podría ser la pieza que sobra

La objeción más seria a mi tesis es que la IA podría dar más importancia a datos y reglas y hacer menos necesario el CMS que los reúne. Las responsabilidades de la lámina anatómica pueden recomponerse de otra manera. Las competencias descritas pertenecen a la ingeniería de software. Haberlas aprendido con CMS no demuestra que un CMS siga siendo la mejor elección.

Si construir herramientas específicas sale más barato, cambia la ventaja de adaptarse a una plataforma generalista. Una aplicación pequeña, construida alrededor del trabajo propio, puede resultar preferible a un CMS lleno de extensiones. SDK, CLI y MCP también apoyan esa alternativa: hacen cada producto accesible y componible sin asignarle necesariamente un papel central.

El modelo común también cuesta. Un proyecto para quien planifica y un encargo para quien factura pueden tener límites distintos. El diseño guiado por el dominio aborda esa pluralidad delimitando modelos y explicitando sus relaciones.¹³ Forzarlos a una sola estructura puede crear traducciones frágiles, copias obsoletas y un punto por el que deba pasar cada cambio.

Una alternativa sensata conserva los sistemas de referencia en sus ámbitos y los conecta mediante contratos explícitos. El agente coordina operaciones; los servicios siguen aplicando sus reglas. El CMS puede quedarse donde lo necesitan los editores o salir por completo de ese flujo. Debo considerar esta posibilidad también para evitar reconocer en el futuro, sobre todo, la herramienta que mejor conozco.

Para mí, el CMS merece ese lugar cuando relaciones, permisos y procesos editoriales compartidos son una parte sustancial del trabajo. Si usarlo exige duplicar reglas fiables en otros sistemas y mantener sincronizaciones continuas, la ventaja puede desaparecer. La prueba concreta es imaginar que lo quitamos: ¿qué responsabilidades habría que reconstruir, qué integraciones desaparecerían y cuánto más difícil sería comprender o subsanar un error? La mejor elección reduce el trabajo total manteniendo las garantías necesarias.

Las herramientas que quisiera usar mañana

Esta perspectiva influye en las herramientas que me interesan. Me atrae Railway, donde servicios y entornos son partes visibles del proyecto. Lovable parte de construir la aplicación y también ofrece un backend gestionado con base de datos, autenticación y almacenamiento.¹⁴ Son maneras distintas de hacer accesible un sistema que sigue teniendo dependencias por debajo.

Prefiero plataformas que hagan comprensibles esas dependencias y ayuden a gobernarlas. Imagino la construcción conversacional como una capacidad de una plataforma más amplia que acompaña al software después de su primera entrega.

Quisiera pedir «convierte esta imagen en una galería» y ver qué datos cambiarán, cómo se tratarán los existentes, qué servicios participarán y dónde hará falta aprobación. También quisiera saber cómo recuperarnos si algo falla. Dibujar componentes en un lienzo es un buen principio; el valor está en gestionar el cambio que los atraviesa.

El próximo CMS podría nacer de aquí o de la evolución de herramientas actuales. Me importa que una persona pueda elegir su interfaz y su agente y seguir trabajando sobre una base compartida. La diferencia estará en acompañar un cambio desde la intención de quien lo pide hasta sus consecuencias en el sistema.

Viva el CMS

En el mundo de los CMS también hay mucho trabajo hecho por inercia: instalar un tema, acumular plugins y entregar sin preguntarse cómo aguantará el sistema. Haber trabajado con CMS no es, por sí solo, una señal de cuidado o competencia. La facilidad para empezar puede fomentar tanto la curiosidad como la pereza.

Al ver lo que construimos hoy con IA, me encuentro sobre todo con algo que siempre ha sido evidente: el buen software es buen software. Se reconoce por cuánto ayuda a quienes lo usan y por cómo resiste el paso del tiempo y los cambios. Los nombres, las siglas y la tecnología de moda dicen poco por sí solos.

A quien hoy construye su herramienta de gestión con IA le dejaría cuatro preguntas, las mismas que seguiría haciéndome:

• ¿Qué reglas deben seguir siendo ciertas mientras cambia el sistema?
• ¿Quién puede actuar, sobre qué datos y con qué consecuencias?
• ¿Qué hemos intentado realmente recuperar después de un error?
• ¿Qué sabrán quienes lleguen después de nosotros?

Los CMS fueron el contexto en el que aprendí a hacerme estas preguntas. Me llevo lo aprendido, incluso cuando me ayuda a elegir otra arquitectura.

CMS is dead. Long live the CMS.