Insights

Clients running enterprise Drupal platforms have stopped asking whether AI can write code. The question we get now is narrower and much more useful: does it shorten the time between "the site is behaving strangely" and "we know why"?

That is a question about maintenance economics, not about developer replacement. On a platform that has been live for six years, carries forty contrib modules and three rounds of inherited custom code, diagnosis is where the hours go. The fix is usually small once you know what to fix.

We have been using Claude as part of that diagnostic loop on production Drupal work for the better part of a year. Here is an honest account of where it earns its place, where it confidently misleads, and the guardrails that make the difference.

What it catches fast

The pattern is consistent: AI is strong wherever the answer is already present in text you can hand it, and weak wherever the answer lives in runtime or database state.

• Stack traces and white screens. Paste a WSOD backtrace with the surrounding dblog entries and the relevant module file, and you get a ranked set of candidate causes in seconds. This is the single highest-value use. A senior developer reaches the same conclusion — just fifteen minutes later, after mentally walking the call chain.
• Cache invalidation chains. Drupal's cache metadata is genuinely hard to hold in your head: contexts, tags and max-age compose across render arrays, and a missing tag three levels down produces stale output nowhere near the code that caused it. Given the render array and the entity involved, AI traces that composition reliably.
• Query pathology in Views. Hand it a slow query log alongside the exported View configuration and it spots the N+1 pattern, the missing relationship, or the filter that forced a full scan. It reads EXPLAIN output well.
• Hook ordering and interference. When two modules implement the same alter hook and the outcome depends on weight, describing the symptom plus the two implementations usually surfaces the collision immediately.
• Deprecated API usage. Ahead of a major version upgrade, it is quick and accurate at flagging removed APIs in custom modules and explaining the replacement — a genuinely tedious task done well.

Where it gets things wrong

These are the failure modes we have actually hit, not theoretical ones. Every one of them cost us time before we learned to design around it.

• Configuration sync state. AI cannot see what is in your active configuration versus your exported YAML, and it will not say so. It infers a plausible state and reasons confidently from it. On config-related bugs its suggestions are frequently wrong in ways that read as authoritative.
• Patched contrib modules. A model reasons about the published version of a module. If you are carrying three patches against it — which every long-lived Drupal platform is — its mental model of that file is wrong, and nothing about the conversation reveals the mismatch.
• Anything database-shaped. Orphaned field data, half-finished migrations, entity revisions in inconsistent states: none of it is visible in code, so none of it is visible to the model.
• Version drift. Drupal's API surface has moved considerably across recent major versions. Answers sometimes blend idioms from different versions into code that looks right and does not run. Always state your exact version.
• Invented hooks and services. The most dangerous failure, because it is the most plausible. Hook and service names that ought to exist get produced with complete confidence. Verify every unfamiliar API against the actual codebase before acting on it.

The unifying rule: it is a strong reasoner over text you give it, and an unreliable guesser about state you did not. Most bad outcomes trace back to someone expecting the second thing.

The workflow we actually use

Three practices convert the above from a novelty into something we are willing to bill against.

A project context file. The same approach we described for Next.js and AI agents applies directly to Drupal, and matters more here because Drupal's conventions are less guessable. Ours records the exact core version, the contrib modules carrying patches and what those patches do, the custom module namespaces, whether config sync is authoritative, and the local development stack. It removes an entire category of wrong answers before they are produced.

Evidence before opinion. No diagnostic conversation starts with a description of the symptom in prose. It starts with artifacts: the drush watchdog:show output, the relevant drush config:status, the actual file, the actual query. Prose descriptions of bugs are where human assumptions leak in, and the model will adopt those assumptions wholesale.

Reproduce, then fix. A proposed cause is a hypothesis until it is reproduced locally. This sounds obvious and is the step most often skipped, because a confident explanation feels like a finished diagnosis. It is not one.

What we never delegate

Some work stays entirely human, and the boundary is not about capability — it is about what happens when the output is wrong.

• Security advisories. Patches get read and applied by a person. The blast radius of a confidently wrong answer here is the whole platform.
• Major version upgrades. AI helps enormously with the deprecation inventory; it does not drive the upgrade.
• Data migrations. Anything that writes to production data, where a subtly wrong transform is discovered weeks later and is expensive or impossible to reverse.
• Anything touching personal data. Production content containing PII does not go into a prompt. Reproduce with synthetic data instead.

What it actually changes

The honest summary is unglamorous: it compresses diagnosis, and diagnosis is most of the cost. Investigations that used to consume an afternoon frequently resolve in under an hour. The fix takes exactly as long as it always did, the review is unchanged, and the deployment discipline is unchanged.

What it does not do is reduce the expertise required. Every failure mode above is caught by someone who knows Drupal well enough to recognise a wrong answer — and invisible to someone who does not. Used by a team without deep Drupal experience, this tooling produces confident, plausible, wrong changes faster than before. That is a worse position than not using it.

That is why we treat it as leverage on an existing maintenance capability rather than a substitute for one. If you are weighing how to keep a Drupal platform healthy after launch, our approach to running Drupal at scale and our managed services team cover the operational side. Get in touch if you would like to talk it through.