AI-generated Rector rules for Drupal

Drupal's upgrade story has improved significantly over the years, but the maintenance burden of Core API change is still real.

Every deprecation introduced in Drupal Core eventually becomes work for someone else: module maintainers, platform teams, agencies, and in-house engineering groups responsible for custom code. A single deprecation may be easy to fix by hand. Hundreds of them, spread across multiple modules and repositories, are not.

That is the context for Dries Buytaert's recent note on AI-generated Rector rules for Drupal. The core idea is straightforward: if Drupal Core changes can be understood systematically, then at least part of the upgrade work can also be generated systematically.

Why hand-written Drupal Rector rules do not scale

The Drupal ecosystem already has Drupal Rector, and it remains one of the most practical tools available for modernizing Drupal codebases.

Rector works well when there is a reliable rule that can transform an old API usage into a newer one. The challenge is not whether Rector is useful. The challenge is the amount of human effort required to keep writing, reviewing, and maintaining rules as Drupal Core continues to evolve.

Hand-written rules do not always scale well because:

• Drupal Core introduces a steady stream of API changes over time.
• Each change may require someone to interpret intent from code, issues, and discussion.
• Writing a safe automated transformation still takes engineering time.
• Edge cases often need iteration and follow-up fixes.
• The backlog of possible upgrade rules can grow faster than volunteers or maintainers can process it manually.

In other words, the bottleneck is often not the transformation engine. It is the production of enough high-quality rules to keep up with change.

What Drupal Digests is doing differently

According to Dries Buytaert's newsletter, Drupal Digests now analyzes several inputs together:

• Drupal Core commits
• related issues
• discussions
• code changes

From that material, the system generates Rector rules automatically.

That matters because deprecations are rarely fully described in one place. The code shows what changed. The issue explains intent and migration guidance. The discussion may reveal constraints, edge cases, or implementation nuance. Looking across these signals gives a much better foundation for generating a meaningful rule than reading only a diff.

This is also why the announcement is notable beyond a single tooling improvement. It points to a broader shift in upgrade automation: not just running transformations automatically, but deriving the transformations themselves from project history and technical context.

Over 175 Rector rules have already been generated

One of the strongest details in the source material is the current output volume: over 175 Rector rules have already been generated.

That number is large enough to be strategically interesting.

It suggests the approach is not a one-off experiment around a handful of easy deprecations. It is becoming a repeatable method for translating Drupal Core change into upgrade automation.

At the same time, it is important to stay realistic. AI-generated rules will not all be equally robust. Some rules will have bugs. Some will miss edge cases. Some may need human review or refinement before they should be trusted across large codebases.

That does not reduce the value of the work. It clarifies where the value is.

For experienced Drupal teams, the upside is not "perfect automation." The upside is a reduction in repetitive migration work, a faster path to first-pass refactoring, and a better ability to focus human effort where human judgment is actually needed.

How to try it

The source notes include the exact command sequence to try the generated rules.

git clone https://github.com/dbuytaert/drupal-digests.git
composer require --dev rector/rector
vendor/bin/rector process web/modules/custom \
  --config drupal-digests/rector/all.php --dry-run

This is a sensible way to evaluate the output.

Use --dry-run first. Review the proposed changes. Compare them against your codebase conventions and module assumptions. Then decide whether a subset of rules is ready for broader use in CI or migration workflows.

For teams managing enterprise Drupal estates, the practical evaluation path is usually:

1. Run on a narrow set of custom modules.
2. Inspect diffs for false positives or partial transformations.
3. Test affected paths, especially entity handling and custom integrations.
4. Promote the approach gradually rather than applying every rule everywhere at once.

Example: modernizing $entity->original

One of the most concrete examples from the source material is the modernization of the deprecated $entity->original property.

In Drupal 11.2, $entity->original was deprecated in favor of:

• $entity->getOriginal()
• $entity->setOriginal()

The property is removed in Drupal 12.

This is exactly the kind of change that fits Rector well. The old and new forms are explicit, the migration intent is clear, and many codebases may contain the same pattern.

Before

$entity->original->field->value;
$entity->original = $unchanged;

After

$entity->getOriginal()->field->value;
$entity->setOriginal($unchanged);

This example is useful because it shows both kinds of replacement that upgrade tooling needs to understand:

• property read to method call
• property assignment to setter call

That distinction matters. A simplistic search-and-replace would not be sufficient. The transformation has to recognize intent and convert usage into the appropriate accessor pattern.

Why this matters for Drupal 12 migration planning

For teams already thinking about Drupal 12 migration, this approach can improve planning in a few ways.

First, it can reduce the amount of manual inventory work needed to understand what deprecations are fixable through automation.

Second, it can shift upgrade effort earlier. Instead of waiting until migration pressure is high, teams can run automated refactors incrementally as deprecations appear.

Third, it creates a more scalable model for large organizations with many custom modules. When the same deprecation pattern appears across dozens of repositories, a generated Rector rule can save substantial repeated effort, even if it still needs review.

This is particularly relevant in enterprise environments where platform owners need predictable upgrade motion. Manual refactoring does not disappear, but automated first-pass modernization can make roadmaps less reactive and less dependent on last-minute cleanup. That is closely aligned with a disciplined Drupal version upgrade approach rather than treating major-version work as a one-time scramble.

The tradeoff: speed versus certainty

The most useful way to think about AI-generated Rector rules is not as a replacement for maintainers, but as a force multiplier.

There is an obvious tradeoff:

• Speed improves because rules can be generated from project change history at much higher volume.
• Certainty varies because generated rules may contain bugs or fail to capture edge cases.

Senior teams will recognize this pattern immediately. Many forms of automation are valuable before they are perfect, provided they are reviewed within a disciplined engineering workflow.

That means the right posture is neither blind trust nor dismissal.

A practical posture looks like this:

• treat generated rules as accelerators
• validate them against real code
• use tests and code review to catch unsafe changes
• feed findings back into the rule set over time

If adopted that way, AI-generated rules can make upgrade automation materially more effective without lowering engineering standards.

A meaningful step for the Drupal ecosystem

The significance of this work is larger than a single repository of generated rules.

It suggests a future where Drupal can respond to its own evolution faster. As Core APIs change, the ecosystem may be able to convert more of that change into reusable upgrade intelligence, rather than relying exclusively on manual translation by a limited set of maintainers.

That could help reduce friction for module maintainers, improve modernization velocity for custom applications, and make long-term platform stewardship more sustainable.

It is also worth noting the ecosystem context around this work, including Drupal Rector, Drupal Digests, Rector, and contributors such as Bjorn Brala referenced in the source notes. None of these tools or people eliminate the need for engineering judgment. What they do is increase the leverage available to teams doing the work.

In practice, that kind of leverage becomes most valuable when it is paired with broader Drupal platform modernization work and proven delivery patterns from large estates such as Veolia, where predictable rollout, governance, and upgrade sequencing matter as much as the code changes themselves.

Final thought

AI-generated Rector rules will not eliminate all Drupal upgrade work.

Some rules will have bugs. Some will miss edge cases. Some API changes will remain too context-dependent for safe automation.

But that is not the standard they need to meet in order to matter.

If tools like Drupal Digests can reliably reduce repetitive upgrade tasks, help teams modernize custom code earlier, and turn more Drupal Core change into usable automation, they can lower a meaningful portion of migration cost while helping Drupal evolve faster.

That makes this a practical and important development for Drupal developers, module maintainers, technical leads, and platform engineers.

This article is based on source material from Dries Buytaert's newsletter, "AI-generated Rector rules for Drupal."

References

• Drupal Rector: https://www.drupal.org/project/rector
• Drupal Digests: https://github.com/dbuytaert/drupal-digests
• Introducing Drupal Digests: https://dri.es/introducing-drupal-digests
• Rector: https://getrector.com/
• Generated rules repository: https://github.com/dbuytaert/drupal-digests/tree/main/rector/rules
• Bjorn Brala: https://www.drupal.org/u/bjorn-brala