Adopting AI can feel overwhelming, so I am sharing a few tales from my experience creating, maintaining, and assisting with contributed Drupal modules. AI can do a decent job building a "greenfield" Drupal module from scratch, so my first tale is about using AI to build and contribute a module. For my next tale, I want to talk about using AI to maintain an existing "brownfield" Drupal module.

Growing up in NYC, I found brownfields often intimidating, with some so toxic that it can take years for backhoes and dump trucks to remove the contaminated topsoil before construction can begin. With code, a brownfield can contain technical debt, orphaned code, missing tests, etc. Simply put, a brownfield contains unknowns, which means more things can go wrong while working on it. Sometimes a brownfield is so big you need heavy machinery to maintain it, and that is exactly how I felt about using AI on the Schema.org Blueprints module.

Gradually, I have been experimenting with AI to help maintain the Schema.org Blueprints. At first, I would just throw a one-shot prompt at the AI to address a single issue, and it would do a decent job diagnosing and resolving the problem. As I became more confident steering the AI, I started asking it to create issue forks, commits, pushes, and even MRs. As I previously stated in my AGENTS.md I always have "Require me to review all changes before committing and pushing code." and most models respect this rule.

My comfort level reached a point where I am creating {module}-issue-maintenance agent skills that extend my drupalorg-issue-maintenance skills. These maintenance skills have agents to track remote issues in local Markdown files. Honestly, I did not put much thought or effort into these skills; I just keep prompting the agent to improve them, and when I am unhappy with something the agent does, I ask it to tweak or improve the skill. Accepting that the agent is the new kid on the block at the start of every session, I use skills to say, "Hey, please remember when I ask for A, B, or C to do X, Y, and Z."

One thing I always hate is basic manual tasks that take hours to complete. For example, reworking every plugin constructor in the Webform module took weeks, and the work was repetitive and monotonous, making the working branch hard to maintain. Also, cut-and-pasting and tweaks over and over again inevitably lead to typos that can cost me a few hours.

Frankly, updating from one version of Drupal to another is a pain in the ass that has improved over the years, with Drupal Rector automating easy fixes. Even with Drupal Rector, it can only do so much with your code. It can rework code, but it can't refactor it to improve clarity.

For example, Drupal Rector can convert functional hook calls to OOP hooks, but it doesn't set up dependency injection or autowiring; it simply moves all hooks into a single OOP hooks class. This approach misses the main benefit of OOP hooks: moving hooks into dedicated hook services that can be specialized and encapsulated.

The Schema.org Blueprints module easily contains 100+ hook implementations that need to be converted to OOP hooks. On a related note, before OOP hooks existed, most of my functional hooks called a service that contained most of the hook's business and implementation logic. In the end, I am not looking for a lift-and-shift, but an architectural improvement that makes it easier to understand what the Schema.org Blueprints core and sub-modules are doing.

I dabbled in many approaches, with successes and failures, when trying to incrementally have an agent convert the functional hooks into OOP hooks with categorization and dependency injection. Frankly, the overall experience felt like a failure that will lead to success, so let’s talk about the failures first.

First off, my biggest mistake, which led to AI failing, was having the skill and plan track too many things at once, which overloaded the agent's context window and caused it to lose sight of the task at hand. This led to bizarre, convoluted inheritance and cross-referencing in the code. Yes, gradually, AI slop drifted into the code. At the same time, the AI never broke a test and followed my explicit rule not to change or turn off tests.

I finally settled on a simple OOP hook conversion skill that outlined a process with guidelines for the agents to handle multiple modules at a time. Still, at one point, the OOP hook conversation spiraled toward failure, with the code requiring too much review and fixing. The AI slop complaint and challenge are real, while the success of using AI for code review is apparent.

The downward spiral of the OOP hook conversion was corrected when I created an OOP hook review skill. The OOP hook review skill asks the agent to diff each converted module and look for inconsistencies and confusion. The real superpower moment was when I realized that AI could revert a submodule conversion and start over. I simply don’t know Git well enough to perform this type of reversion without tedious manual work. Meanwhile, the agent knows the goal of the revert is to be able to diff the submodule against main and see no changes, so it figures out how to do the reversion.

The overall success of the OOP hook review skill was being able to take a break from this massive task and knowing that AI could review the conversion and pick it up at any time. AI can assist with monstrous ongoing tasks.

I started this rework expecting it had to be done and merged because the OOP conversion branch would be too hard to maintain and rebase from main. I suck at rebasing, while AI can do it in its sleep. The opportunity and reality are that AI can move and refactor our code in ways that were not humanly possible with limited resources.

A year ago, even a few months ago, I would have said AI couldn't become a first-class contributor to my brownfield Schema.org Blueprints project. There was too much code and too many nuances.

Drupal's move to OOP hooks is part of Drupal's larger modernization that has been ongoing for a decade. Frankly, OOP hooks feel like the last part of the Drupal modernization initiative, and Nick deserves a shout-out for all his work.

Nic Laflin, as a host of Taking Drupal, has publicly stated his concerns about AI. It is hard not to respect his view because his OOP hook contribution demonstrates his love for and mastery of his craft. Nick could be equated to someone who loves black-and-white photography and produces amazing photos that are 99% better than those taken with modern digital photography. Frankly, I hope Nick keeps doing what he is doing for Drupal, and we are probably better off with him being AI-cautious.

Nick is in the 1% of developers who are masters of their craft and AI-cautious, and the remaining 99% of us need to look at what is AI-possible.

The challenge of performing a major upgrade, conversion, and refactoring of the Schema.org Blueprints module marked the beginning of my effort to make my brownfield code easier for humans and agents to understand and improve. It is hard not to predict that for an open-source CMS to stay relevant for humans and their agents, Drupal will have to let AI, alongside humans, do massive refactoring and overhauls of our codebases in the near future. And yep, if AI safely makes massive changes to Drupal core, then all the pending MRs will need to be reworked; AI will most likely do that work as well.

What I love about Drupal is that we, as a community, built something that has stood the test of time and will keep moving forward. A lot of competitors without solid APIs are going to struggle. Closed-source products will suffer because they won't have the humans required to keep up with agents.

AI is moving so fast, and it's starting to feel like I'm running with scissors. Which is a discussion, or maybe a presentation, for another day. For now, I'll keep exploring what is AI-possible while respecting those who are AI-cautious.