Drupal is good for AI to use and hard for AI to build. Both are true.

Strong for consumption, weak for development, and why the distinction changes what you should do.

Over the past year, the Drupal community has invested seriously in a story about why Drupal is well positioned for the AI era. There is now a funded AI Initiative with a published roadmap, dedicated workstreams, and a coordinated message that runs through keynotes, blog posts, and agency essays. The investment is real and the message is largely coherent.

And yet the conversation still feels unresolved. I think that is because two genuinely different questions are being asked as if they were one, and the honest answers to them point in different directions. Separating them does not weaken the case for Drupal and AI. It makes it clearer.

I run a Drupal agency. I also build AI products in TypeScript and Python. I've spent the past year using Claude Code and other agents to work across all of these stacks daily. From that vantage point, "is Drupal good for AI?" is the wrong question, because the honest answer changes completely depending on what you mean by "good for AI."

There are two distinct questions, and they need distinct answers.

Question one: is Drupal a good platform for AI to consume?

When someone in your organization wants to use AI to summarize documentation, generate answers based on a knowledge base, translate content into ten languages with workflow oversight, or build semantic search across your taxonomies, they're using AI to consume content from your platform. The platform is the source. AI reads from it, sometimes writes back to it, and produces output for humans elsewhere.

For this question, Drupal scores high. Genuinely high.

Drupal's content model was built for structure long before AI needed it. Every piece of content in Drupal is an entity with typed fields, taxonomies, metadata, revisions, and relationships. This isn't HTML in a body field; it's queryable, structured data. When you feed structured data to an LLM as context, you get dramatically better results than feeding it free-form text. The same property that made Drupal good for SEO (schema.org markup, semantic relationships) makes it good for AI.

The AI module ecosystem is more mature than it appears from outside. The Drupal AI module shipped its first production release in January 2025, stabilized its API and provider structure with the 1.2.0 release in October 2025, and is reported in use on at least 13,980 sites as of April 2026 (a floor, since drupal.org usage statistics only count sites that opt into reporting). It exposes a vendor-agnostic abstraction layer connecting to 48+ AI providers, including OpenAI, Anthropic, Google Gemini, Mistral, and self-hosted Ollama. Swap one for another without rewriting code. This is real architectural achievement, not a slide deck.

MCP server support is in. Drupal can now act as a Model Context Protocol server, meaning external AI agents can consume Drupal content and capabilities through a standardized interface. If you're building agent infrastructure that needs structured content access, Drupal is first-class citizen now, not afterthought.

AI Translate and AI Logging matter for enterprise. AI Translate works through TMGMT with translation memory and proper multilingual database storage. AI Logging records every AI interaction for audit and compliance, which sounds boring but is required reading in regulated industries. AI Image Alt Text generates compliant alt text at scale, addressing the European Accessibility Act (EAA), which came into force on June 28, 2025.

Governance is built in. Drupal has spent twenty years refining permissions, workflows, content moderation, and audit trails. When AI agents act on your content, you want gates, not autonomy. Drupal has the gates already wired.

The institutional investment is real. The Drupal AI Initiative has 28 supporting organizations and 23+ FTE contributors (over 50 individuals total), and hit its $1 million funding goal at DrupalCon Vienna in October 2025, composed of $200,000 in cash and $800,000 in committed FTE hours from 22 agency partners. This isn't a community side project; it's coordinated effort.

If you have an existing Drupal site and you want to add AI capabilities, the answer is not "migrate to something else." The answer is "use what's there." For a hospital network adding AI search to an intranet, a publisher integrating AI workflows into editorial, or a government site adding AI translation for accessibility, Drupal is competitive, often superior to building from scratch.

Question two: is Drupal a good platform for AI to help develop?

This is the question being conflated with the first, and it has a different answer.

When you, as a developer, sit down to build features in Drupal with an AI coding agent assisting (Claude Code, Cursor, GitHub Copilot, whichever), you're using AI to develop on the platform. The platform is the environment. The agent navigates code, suggests changes, generates implementations. The quality of this loop depends on properties of the platform that have nothing to do with content structure.

For this question, the answer runs the other way. The reasons are structural, and adding more AI modules does not address them, because the difficulty is not a missing feature.

From building on hostile and friendly platforms alike, I keep coming back to five properties that determine how well an AI coding agent can collaborate with a developer:

Code-first versus UI-driven configuration. Drupal's configuration lives partly in code (YAML files) and partly in the database (managed through admin UI). The agent reads code. It doesn't navigate UIs. Every time a feature involves configuration changes, the human becomes the translator between agent suggestions and admin clicks. Modern alternatives like Payload or Medusa keep configuration purely in TypeScript files, which agents handle natively.

Explicit types versus implicit types. PHP 8 supports types, but Drupal core and most contrib modules use them inconsistently. When the agent hallucinates a function signature or wrong return type, nothing catches it before runtime. TypeScript with strict mode, by contrast, fails the build on these errors. The more you use AI agents, the more you need this safety net. Rust takes it further with the borrow checker; either way, the principle holds.

File-based routing versus magic hooks. In Next.js, a file at app/users/[id]/page.tsx handles URLs like /users/1 or /users/abc, where id is a dynamic segment. SvelteKit works the same way: src/routes/blog/[slug]/+page.svelte serves /blog/hello-world, and the +page.server.js next to it is, by its name alone, the part that runs on the server. The agent reads the file tree and knows what runs where. In Drupal, behavior gets injected through hooks invoked dynamically from anywhere in the system. To understand what runs when a request comes in, you need conventions that exist only in human knowledge, not in any single file.

Explicit composition versus metaprogramming. Drupal generates significant behavior at runtime through plugin derivatives, entity API magic, and configuration management. Code that doesn't exist as text gets executed. The agent reads text. Behavior that doesn't exist as text doesn't exist for the agent. The result is hallucination rates that compound over the conversation.

Clear conventions versus multiple ways. To render content in Drupal, you can use render arrays, blocks, views, derivatives, paragraphs, entity displays, or field formatters. Each has its place; each has different syntax and idioms. The agent suggests one approach; the senior developer would have used another; the codebase fragments over time.

I'll be specific. I asked Claude Code to add a base field to block_content with proper install and update hooks, on a Drupal 10.6 site. This was not a throwaway exercise: it was the first version of a module I have since released on drupal.org. The generated code looked right and passed phpcs cleanly. Then drush updatedb failed. The code called module_load_install() and drupal_set_installed_schema_version(), two functions removed in Drupal 10, and used a field type whose storage contract the update hook then violated, leaving the schema half-applied. Three distinct failures in one task, none caught by linting, all surfacing only at runtime. The module works today because I found and fixed what the platform let through, not because the agent got it right. I asked for an equivalent feature in our Payload and Next.js setup and the generated code ran clean, because the type system rejected the equivalent mistakes before they reached me.

Drupal 11.1 introduced object-oriented hooks with PHP attributes, expanded in 11.2 and 11.3, which is genuine architectural progress. But procedural hooks still coexist throughout core and contrib, with removal not planned until a future major version. The training data the agent learned from spans Drupal 7, 8, 9, 10, and now 11, with no easy way to distinguish current from deprecated. The fundamental complexity isn't going to shrink soon.

Why both answers are true

The two answers seem contradictory, but they aren't. They flow from the same source: Drupal's accumulated architectural sophistication, built up over twenty years to handle complex content management at enterprise scale.

This sophistication is exactly what makes Drupal good for AI to consume. Content is highly structured. Permissions are granular. Workflows are mature. The schema is rich. AI agents reading this content benefit from all of it.

This sophistication is exactly what makes Drupal hard for AI to help build with. Hooks invoked dynamically. Configuration split between code and UI. Multiple ways to express the same logic. Behavior generated at runtime. The agent has to navigate complexity that humans evolved to handle but that AI does not.

You don't get one without the other. The properties that make Drupal good as a content platform make it harder as a development platform. The properties that make modern alternatives easier as development platforms make them less mature as content platforms.

This isn't a failure of Drupal. It's the natural consequence of optimizing for one thing across decades. Modern alternatives like Payload, Sanity, and Strapi have less mature content governance because they haven't yet had twenty years of enterprise requirements pushed into them. They will, eventually. Drupal has higher architectural complexity because it has accumulated capability that modern alternatives haven't yet built.

What this means for decision-makers

Three practical implications.

If you already run Drupal and you want AI features, don't migrate. Add AI capabilities through the existing module ecosystem. The investment you've made in content modeling, permissions, workflows, and editorial processes is what makes AI useful. Throwing it away to start fresh is throwing away the asset that makes AI work for you.

If you're starting a new project, evaluate honestly. The question isn't "Drupal or modern stack." The question is "what is this project optimizing for?" If you're building a content-heavy site with complex governance, multilingual workflows, and editorial complexity in a regulated sector, Drupal may still be the right answer. If you're building a modern application, a SaaS, a DTC commerce site, or anything where development velocity matters more than content depth, modern alternatives are now strong enough to be the better choice.

If your team uses AI agents for development daily, this should factor into stack choice. Stack choice used to be about what humans on the team know. It's increasingly also about what AI agents work well with. Code-first, strongly typed, file-based platforms have a productivity advantage that compounds with every hour of agent-assisted work. This is a genuine new criterion, not yet captured in most stack comparisons.

A note on the discourse

The reason this distinction has been getting lost is that the people writing about Drupal and AI have legitimate interests in one side of the answer being more visible.

Acquia, Dropsolid, and other commercial players in the Drupal space have a stake in Drupal being seen as a serious AI platform; valuations and product roadmaps depend on it. Modern stack vendors like Vercel, Sanity, and others have the opposite incentive: to position Drupal as legacy and themselves as the future. Neither set of arguments is bad-faith. Both are partial. Each emphasizes the half of the picture that serves its position.

The honest position is that both sides are right about half the picture. Drupal is a strong AI consumption platform, particularly in regulated sectors with content complexity. Drupal is a weak AI-assisted development platform, particularly compared to TypeScript-first alternatives built in the last five years.

Question two is not a verdict. It is a current state that the community can change.

Everything I wrote about the development side describes Drupal as it is today. None of it is permanent. The five structural properties are hard to change because they are the accumulated architecture. But the thing that actually determines agent productivity is not the architecture in isolation. It is the feedback loop the agent operates inside. And the feedback loop is buildable.

I learned this in the most hostile environment I have worked in, and not as a commercial exercise. My doctoral research is on human-AI collaboration in organizational contexts, and I needed to build a research tool as a Zotero plugin. Zotero plugin development runs in the Firefox/XUL engine: privileged JavaScript context, non-standard DOM, sparse training data, opaque plugin lifecycle. By every property in this article, building a complex Zotero plugin with an AI agent should be close to impossible. It was not. The plugin came out nearly bug-free, because before building it I built a development bridge that gave the agent screenshots, DOM inspection, JavaScript execution in context, log streaming, and automated UI tests. The architecture stayed hostile. The feedback loop became excellent. That was enough.

This is the constructive implication for the Drupal community, and it is a real one. The AI Initiative's $1M and 23 FTEs are currently pointed mostly at the consumption side: better content generation, better RAG, better governance. That work is valuable and should continue. But there is a second, underinvested frontier: tooling that gives AI agents real introspection and automated testing inside Drupal's own development loop. Entity and field introspection the agent can query as structured data instead of inferring. Automated UI and behavioral testing the agent can run and read. Hot reload with structured error feedback the agent can act on. Drupal already has the raw materials (Drush, the entity API, the testing framework). What is missing is the agent-facing layer that turns them into a tight feedback loop.

If the community builds that, the Question two answer changes. Not because Drupal's architecture became simpler, but because the loop the agent works inside became tighter. The accumulated sophistication that today is a liability for AI-assisted development could stop being one. The same property that makes Drupal strong on the consumption side would no longer have to be a weakness on the development side. That is a future worth building toward, and it is within reach of an initiative already funded and staffed.

I would rather end here than on the diagnosis, because the diagnosis without the path is just discouragement, and the path is real.

The single sentence to take away

Today, Drupal is a strong AI consumption platform and a weak AI-assisted development platform. The first half is durable. The second half is a current state, not a verdict, and the community has both the materials and the funding to change it.

Disclosure

I run BloomIdea, a Drupal and AI agency that has built AI in production for our own e-commerce and our clients' systems. Our revenue rests on Drupal, and we are also investing in modern stacks for new projects where development-side properties matter more.

We also build and maintain a family of open source MIT bridges that let AI agents work with platforms that are otherwise hard for them. Some are commercial, built under BloomIdea for our client stack: drush-mcp for Drupal, mautic-cli for Mautic, saft-mcp for Portuguese tax files. One is academic, built for my doctoral research: the Zotero development bridge linked above. That the same pattern emerged independently in both a commercial and an academic context, without me planning it as a strategy, is part of why I trust it is a real principle and not a sales narrative. They are all concrete attempts at the agent-platform boundary this article argues for: the agent stays on the AI-friendly side, the bridge absorbs the platform's complexity. I mention this not as a pitch but because it would be dishonest to write about this boundary without disclosing that I have built several and have a view shaped by that.

So I have skin in both games. That's the position from which this article is written. The distinction it makes serves my own clarity as much as anyone else's. If it serves yours too, use it.

José Fernandes is the founder of BloomIdea, a Drupal and AI agency based in Braga, Portugal. He is the author of Digital Marketing with Drupal (Packt, 2022), with a foreword by Drupal creator Dries Buytaert, and is completing a PhD on human-AI collaboration in organizational contexts at the University of Minho.