Keeping Drupal codebases current across major releases has always been labor-intensive — and that labor is almost entirely billable time that clients don't enjoy paying for. Dries Buytaert published a post this week describing an experimental system that uses AI to generate the Rector rules responsible for automating those API migration steps. It's early-stage, but it's pointed at a real problem agencies deal with on every Drupal project.
What shipped
Rector is a PHP refactoring tool that applies automated code transformations — if your module calls a deprecated API, a Rector rule can rewrite that call to the new pattern without a developer doing it by hand. Drupal's community already ships some official Rector rules, but authoring them has always required a developer who deeply understands both the old API and the new one, plus the syntactic nuances of Rector's own rule format.
Dries's experiment extends the existing Drupal Digests project — which already summarizes changelog data from Drupal core — with an AI step: it ingests the deprecation notices and change records published with each Drupal core release, then uses a large language model to draft the corresponding Rector rule. The generated rules are reviewed before being merged, so there's a human gate in the loop, but the heavy pattern-matching work — "this API changed in this way, here's the before/after transformation" — is offloaded to the model.
The post is candid about the current state: some generated rules are correct out of the box, some need meaningful edits, and the coverage is still incomplete relative to the full deprecation surface of a major release. The system is not a one-click upgrade button. What it does is shift the bottleneck from writing rules to reviewing and correcting them — which is a fundamentally faster and cheaper workflow when the underlying transformations are repetitive and well-documented.
For context: Drupal core ships roughly 100–200 deprecation notices per major version cycle. Each one that has a Rector rule attached means a developer running rector process instead of hunting down every usage by hand. Each one that doesn't have a rule is manual work billed by the hour.
Our take
We've been running Rector on Drupal upgrade engagements for a couple of years now, and the coverage gap is real. On a recent Drupal 10 → 11 upgrade for a mid-size higher-ed client, we had solid Rector coverage for maybe 60–70% of the deprecated API surface. The remaining third was still a manual grep-and-fix exercise. That's where most of the upgrade hours come from — not the straightforward substitutions, but the deprecations where no rule exists yet and someone has to trace through change records and write the transformation themselves.
What Dries is describing would, if it reaches production quality, compress that last 30–40% meaningfully. Even if AI-generated rules are right 70% of the time and require correction 30% of the time, that's still faster than authoring from scratch. A developer reviewing and tweaking a mostly-correct Rector rule takes 15–30 minutes. Writing one cold, with research, takes 2–4 hours on an unfamiliar API change.
The honest trade-offs, though, are worth naming:
- Quality is uneven. The AI doesn't always understand the intent behind a deprecation — it sees the before/after pattern in the change record, but some API changes carry semantic differences that a naive text transformation will get wrong. A Rector rule that applies silently to hundreds of files and introduces a subtle behavioral bug is worse than no rule at all. Review is not optional.
- It doesn't solve the module ecosystem problem. Generated rules help with your custom code. Contributed modules still need their maintainers to run Rector and ship updated releases. The upgrade bottleneck on most real projects isn't core's deprecated APIs — it's the 20–40 contrib modules that are stuck on older patterns. This tooling doesn't change that equation.
- It depends on change records being well-written. Drupal's change record quality is inconsistent. Some are detailed and include code examples; others are sparse. The AI is only as good as what it's trained on, and a vague change record produces a vague (or wrong) rule.
That said — the direction is right. The Drupal upgrade story has historically been a harder sell to clients than WordPress major versions, partly because the automation tooling has lagged. Anything that narrows that gap is good for the ecosystem and good for agencies trying to make the "stay on Drupal" case.
Practical recommendations
If you maintain contrib modules: Start watching this project. If AI-generated rules start shipping in quantity, early adopters who incorporate Rector into their release process will have a meaningful QA advantage. Add palantirnet/drupal-rector to your dev dependencies if you haven't.
If you're planning a Drupal major-version upgrade this year: Don't wait for this tooling to mature before starting. The current Rector coverage is already useful — run it first, then handle the remainder manually. This AI layer will improve coverage over time, but it's not a reason to delay an upgrade that's already overdue.
If you're evaluating Drupal for a new project: The upgrade automation story is improving. It doesn't change our recommendation calculus today, but the trajectory is worth noting if you're projecting a 5–7 year platform horizon.
If you're a site owner on Drupal 10: Drupal 10 EOL is approaching. Drupal 11 is stable and the upgrade path is well-worn. Start the conversation with your development team now — upgrade cost is consistently lower when it's planned rather than reactive.
Originally referenced: AI-generated Rector rules for Drupal on Dries Buytaert.
We've run Drupal upgrade engagements from D7 through D11 across dozens of client sites — healthcare, higher ed, government, and e-commerce. If you're trying to get a realistic scope and cost estimate for your Drupal upgrade, get in touch.
Originally published by Dries Buytaert. Read the full announcement here.
