Introduction
I use AI every day to accomplish a variety of tasks. I'd like to share three tales about building, maintaining, and contributing to different Drupal modules. My goal is to discuss how I use AI and what I use it for.
At the same time, I am not trying to teach you how to use AI because I've noticed a nuance: AI can teach you how to use AI. For example, you can point an AI at this post and ask it to read the post, follow the links, and explain how things are being done. For me, open source and Drupal have always been more about sharing ideas, experiences, and stories, as well as code, allowing humans and their AIs to learn from or be inspired by each other's experiences.
My three tales are meant to be told in a specific order: building a greenfield project, maintaining a brownfield project, and contributing to someone else's project. Because of how AI works and the increased use of spec-driven development, people are discussing projects in terms of greenfield vs. brownfield. Ironically, I don't think of Drupal as greenfield or brownfield, but as infrastructure that fields and projects sit on top of. The most fundamental greenfield project in Drupal is building a new site for an organization, and for contributions to Drupal, building a new module.
Building a module using AI
Building a Drupal module with AI isn't new. I've written several posts that range from learning to build a Drupal module using AI to having AI build a module. The most recent module I've "built" with AI and contributed back to Drupal has a unique nuance: the initial code and solution came from an existing client project we are modernizing, and I had AI contribute the custom code as a module back to Drupal.
I am guilty of a client saying, "Can you quickly do X, Y, and Z?" then coming up with a very simple solution via custom code. Meanwhile, knowing that we are solving a problem that plagues other people and that maybe we "should" contribute it back to Drupal. I don't use the word plague lightly, but the problem my client needed to solve and the use case were fairly simple and annoying to most site builders.
My client's site builders needed to add multiple nodes to a taxonomy term but didn't want to navigate to each node to add a new term. Instead, they wanted to go to the term and add multiple nodes to it. The animation below shows exactly what we built.
The decision to contribute the custom solution back to Drupal is tied to rebuilding and modernizing our website, and this feature needed to be ported to the new Drupal instance. Instead of porting the code, I asked the AI to research how the feature was built and determine how we could replicate the code and concept in a dedicated Term Reference module.
The original custom code supported only nodes because of our specific use case, but the AI immediately asked whether the new module should apply only to nodes or to any content entity. The AI automatically implemented the module using test-driven development. From past experience, I knew that AI could implement Ajax niceties faster than I ever could. It was almost a voila moment when the AI extracted a custom feature into a new contributed module. BTW, I did ask AI to look for a similar supported module first, and neither of us could find one. Feeling that I had something contributable back to Drupal, I prompted AI, specifically Codex, to open the in-app browser and contribute the module back to Drupal.
Contributing a module using AI
Using Matt Glaman's Drupal.org CLI and its agent skill, Codex walked me through every step of contributing my module back to Drupal.org. Yes, I already know the steps involved in contributing code to Drupal, but I wanted to see if AI could do it. For me, this experience made me realize I could use AI to help me contribute to other open-source projects.
Conceptually, this lowers the technical barrier to contributing, while we still need to account for the token cost of AI. I am using GPT 5.6 Luna, a very inexpensive model, for 90% of my code, which costs a few cents to contribute code back to Drupal. My hope is that the Drupal community will optimize the process for using AI and for contributing code back to Drupal, so the costs will be negligible.
This post isn't really about building a module with AI. It is more about using AI to contribute what was once custom code back to open source with little effort, while gaining the benefits of open source. If the open-source community plays it right with AI, an avalanche of new AI-generated code will likely be open source, which would be a net good for everyone. To bluntly address the counterargument that AI generates more and more useless slop, it feels more like the fault of human operators and open-source communities for not steering the AI to write quality code and for not reviewing it. It is up to us humans to steer AI in beneficial directions, including contributing to open-source code.
Building a module leads to maintaining a module
Building, especially contributing to, a module using AI inevitably leads to maintaining a module using AI. Maintaining the Term Reference module using AI has not been very challenging because it is a greenfield project; a daunting challenge for me is maintaining an existing module, aka a brownfield project, using AI.
My two big brownfield Drupal projects when it comes to using AI are the Webform module and the Schema.org Blueprints module. In my next post, I'll talk about using AI to help maintain the Schema.org Blueprints module. You can also learn how I used AI to tackle the Webform module's security issues.
Where are you on your AI journey?
Where are you in your AI journey when it comes to building a Drupal module? Have you tried it? Are you ready to try it? Would you contribute an AI-generated module back to Drupal?