Los posts anteriores son la idea. Este es un extra, sobre por qué mi cabeza va a Drupal para eso, y qué creo que deberíamos hacer al respecto.
Nada de la idea necesita una herramienta en particular. Pero la siguiente pregunta obvia es sobre qué lo construiría, y la respuesta honesta empieza con un sesgo que prefiero nombrar antes que esconder. Conozco Drupal. He trabajado en él por años y contribuyo a él.
Cuando vibeas algo, tú no eliges el stack. Lo elige la IA. Los dos proyectos que revisé estaban construidos con herramientas y modelos distintos, y ambos terminaron con un front end en JavaScript y Supabase atrás. Eso funciona. Pero Supabase es una base de datos con algunos servicios alrededor. Sin modelo de contenido, sin revisiones, sin flujo editorial, sin roles.
Drupal tiene todo eso, y cada vez lo hace mejor.
Entonces esto es lo primero que le diría a cualquiera que esté construyendo esto. Pídele a la IA que use Drupal como framework. Apúntala al módulo de IA y a todo lo que la comunidad ya ha construido alrededor de él, y lo que devuelve es una herramienta más capaz que la versión de JavaScript y Supabase que obtienes por defecto. El front end puede seguir siendo el framework de JavaScript que quieras. Drupal lo ha permitido por años.
También tiene la mayor parte de la maquinaria para lo que describí antes. Funciona con Activepieces, n8n y Maestro a través del módulo de orquestación, y esa integración mejora cada día. Así que puede vivir dentro de un flujo de trabajo o alimentar uno. Puedes configurar agentes desde una interfaz. Y le importa poco qué modelo hay detrás.
Ese último punto vale un momento, por algo que pasó en el meetup. La gente se reía de lo difícil que es cambiar tu backend de IA una vez que construiste sobre uno. Alguien juró que sus resultados empeoraron justo después de mencionar que estaba cambiando de proveedor. Todos se rieron. Todos en esa sala estaban atrapados.
Quizás deberíamos tener un Drupal AI como tenemos Drupal CMS.
Por eso creo que Drupal es la respuesta aquí. La forma en que el trabajo de IA fue construido en Drupal básicamente enmascara quién es el proveedor backend. Y no se detiene en el proveedor. Agentes, el centro de control de contexto, traducciones, metering, y una larga lista de cosas ya construidas y funcionando, ninguna atada a quien esté detrás del modelo este mes.
Y ahí es donde entra el deseo. Para que Drupal sea la respuesta que la IA da cuando alguien le pide construir esto, quizás deberíamos tener un Drupal AI como tenemos Drupal CMS.
Kristof Van Tomme seguía diciendo, en API Days y de nuevo en Drupal Pivot, que Drupal es bueno en aplicaciones de IA nativas y podría enfocarse ahí. Tiendo a estar de acuerdo. Mira lo que está haciendo la gente ahora mismo. Están forzando la IA sobre frameworks que nunca la tuvieron, y construyendo sus propias conexiones, sus propios controles, su propia administración. Esas son las cosas que Drupal pasó años resolviendo.
Nada de eso está terminado, y la comunidad lo dice en voz alta. Las personas que trabajan en esto publicaron su propia evaluación, y dice claramente que Drupal "todavía hace que los agentes trabajen demasiado para llegar a la ventaja." Ellos mismos criticando su propia plataforma en público.
La misma evaluación tiene una línea sobre configuración, que en Drupal significa los ajustes exportados que definen cómo está construido un sitio. Tipos de contenido, permisos, flujos de trabajo. Todas las decisiones acumuladas, guardadas como datos.
"La configuración registra lo que se decidió, rara vez el porqué."
Eso es todo lo que he estado tratando de decir sobre el hotel. El sistema guarda lo que se decidió. No guarda el porqué. Quizás no soy el primero en notarlo.
Entonces necesita trabajo, y el trabajo está pasando. Lo cual está bien, porque la alternativa es peor.
Esta es la misma regla que le pido a mi IA que siga antes de escribir cualquier cosa. Busca arte previo. Reutiliza antes de extender, extiende antes de construir, y solo construye cuando nada encaja. Esa regla no deja de aplicarse cuando lo que estás eligiendo es la base. Construye el tuyo y lo posees para siempre, cada versión y cada corrección de seguridad, y gastarás tu tiempo manteniendo el andamiaje en lugar de la cosa que realmente te importa.
Y está la parte que más me importa. Si el conocimiento operativo de una empresa le pertenece a la empresa, entonces la capa que lo sostiene tiene que ser algo que posean en lugar de algo que rentan. De lo contrario, tomaste lo más valioso que tienen y lo pusiste en algún lugar de donde pueden ser desalojados.
El código abierto no es una preferencia en esa oración. Es lo que hace que el argumento sea honesto.
Entonces esto no es que Drupal sea la única respuesta. Puede haber otras opciones que encajen bien, y espero que las personas que las conocen presenten su caso como yo estoy presentando el mío. Pero todo lo que acabo de recorrer, la maquinaria editorial, el enmascaramiento del proveedor, la propiedad, una comunidad que mantiene la base contigo, hace de Drupal una opción que encaja muy bien para esto. Lo que falta es convertirlo en una de las respuestas que la IA realmente da, y ese es un trabajo que esta comunidad sabe hacer.
Todo esto es opinión. También es una decisión, la que estoy tomando sobre hacia dónde va mi propio trabajo a partir de aquí. Puedo estar equivocado. Prefiero estar equivocado en algo que elegí que tener razón en algo que la IA eligió por mí.