Why Drupal, If an LLM Can Build the Site?

Generating a full-stack app is cheap. Governing the content an organization has to live with is not.

In an afternoon, Cursor, Claude, or another coding assistant can produce a Next.js app or a custom backend that looks finished. That makes an old question sharp again: why commit to a heavy, twenty-year-old CMS like Drupal?

Language models are good at generating code. Enterprises fail on governance, state, and permissions. A bespoke app is inexpensive to spin up. A body of content — tens of thousands of multilingual entities, edited by many teams, under compliance rules, with a real answer to who may change what — is where that kind of building runs out.

Drupal is more useful in that setting than it was before assistants existed. It is the governed layer those assistants can work against, instead of a rival way to produce pages.

Structure is what the model can use

Models struggle with undifferentiated page blobs, and with codebases whose schema changes whenever someone prompts it to. Retrieval, agents, and editorial tools all need fields they can name.

Drupal’s long-standing advantage is a typed, relational content model: fields, content types, taxonomies, and structured components such as Paragraphs. A retrieval pipeline, a Model Context Protocol agent, or an in-editor assistant can be handed entities with a schema, rather than a pile of markdown or a database whose shape lives in whoever last edited the prompt.

A CMS that already refuses to store a page as a blob gives the model less room to invent structure the organization does not actually have.

An assistant writes code, not governance

Cursor can build a React component or an API route in seconds. Generating more code does not settle the operational questions an organization actually argues about.

• Who may edit a field, and who may publish it? Draft access on one regional site is not the same permission as publish access on another. Role-based access control that would survive an audit is tedious to invent from prompts, and easy to get subtly wrong. Drupal ships granular permissions in core, and that system has been hardened for years.
• What state is this content in? Marketing, legal, and compliance do not work in an IDE. They need visible moderation states — draft, in review, published, archived — and a revision history they can look at. Drupal keeps that workflow in the editorial interface, separate from the code an assistant is writing.

The split is the point. Assistants can speed up the code. The people who own the content still need a place to govern it without opening Git.

An agent needs a harness

The Drupal AI Initiative treats agents as something the platform has to hold. It describes the work in two directions.

Inside the editorial tools, an assistant can stay on brand, suggest taxonomy terms, write alt text, and search across structured content, because the rules and the source material already live in Drupal. The Context Control Center stores brand voice, terminology, and domain knowledge as governed configuration, and supplies the relevant slice before the model answers. Canvas, the visual page builder, can assemble a page from a short prompt because the components it is allowed to use already exist.

Outside those tools, developers can use an assistant to write modules, themes, and API-first front ends. Site builders still compose pages without writing that code.

Read as a stack, the arrangement is simple. The model drafts, assists, and generates. Drupal enforces the entity schema, the permissions, the revisions, the translations, and the API. Websites, mobile apps, search, and other agents sit on the far side of that API. The model is not the system of record.

Faster code is not faster publishing

An assistant increases developer speed. It does not, by itself, increase the speed at which a marketing team can publish.

If a banner, a landing-page layout, or a localized sentence requires a developer, a prompt, and a Git pipeline, the assistant has become a bottleneck with a nicer interface. The workflow that holds is narrower. Developers use the assistant to write modules, schemas, and front ends. Editors use Drupal’s admin UI to compose pages, run translation workflows, and publish.

The data has to stay somewhere you control

Proprietary headless platforms and closed AI-native CMSs add a risk that is financial and legal, not only technical.

• Cost. Per-request and per-seat pricing looks reasonable on a prototype and becomes hard to predict once a large editorial team is using it every day. Drupal is open source. It runs on infrastructure you operate.
• Where the content goes. Government, higher education, healthcare, and finance often cannot send their content and user data through a third-party AI platform as a condition of publishing. Drupal can keep that data local, or send model calls only to an enterprise endpoint such as a private Azure OpenAI or Amazon Bedrock deployment.

Where each approach wins

The comparison is not AI against Drupal. It is an ad-hoc generated stack against Drupal used as the governed layer, with assistants doing the work they are good at.

• A first version. An ad-hoc stack is faster to a demo. Drupal is slower until the content model exists, and then ordinary pages stop requiring a developer.
• A year later. Generated codebases tend to lose their shape as prompts accumulate. A typed entity API and a shared schema give later changes a place to land.
• Security and compliance. Permissions invented in a prompt are a liability. Drupal’s access system is part of core, not a one-off module someone asked a model to sketch.
• Editors who do not write code. If every update needs a developer, content operations stall. The editorial UI is built for the people who own the content.
• Using the content in other AI systems. Unstructured pages make poor retrieval context. Schema-aware entities make better context, because the model is told what a field means.

Assistants do not make Drupal obsolete. They remove much of the historical friction of working in it: the boilerplate, the render arrays, the weeks spent learning the framework before anything ships. What they do not remove is the part that was always hard to generate — a durable answer to who may change what, what the content is, and which revision the public is allowed to see.