Vibing Drupal: Tale 3 - Using AI to contribute code by planting it in someone else’s module

The image above shows me holding a plant that represents a small piece of code or an idea I want to share with someone else. To me, sharing code feels like planting something in someone else's garden. The analogy of open-source code and projects as plants and gardens appeals to me because plants are organic and essential to sustaining life, and the gardens we plant require significant planning and care. Open-source contributions come in all shapes and sizes, like gardens and the plants they hold, and both need maintenance. Some gardens require more maintenance than others.

My past two posts/tales focused on building and maintaining a Drupal module using AI, and now I want to discuss contributing to a module using AI. To continue my garden analogy, the projects I maintain are like my personal gardens.

By building and maintaining a Drupal module, I have control over my personal garden, but it exists within a community of gardens. I can decide which code/plants stay or go. Ultimately, I am responsible for the health of the project/garden. My project/garden is part of the Drupal gardens community (pun/irony intended). I am hyper-aware of the Drupal community where my Drupal garden lives.

Early on, when I took over building and maintaining the Webform module, I realized I was responsible for more than code; I was responsible for the entire experience of building Webforms for site builders and for supporting the module's extensibility for developers. To assist site builders and developers, I continually created videos and code examples as I built out the module. My blog explored and shared all aspects of the Webform module, including how to manage the issue queue. Ironically, that post is still relevant with AI, but it requires tweaks with different nudges and tools.

In short, my personal Drupal garden is pretty chill, with the gate open and little signs in front of every plant. Everyone is encouraged to enjoy them, take some seedlings, and help water a few plants. I have a few valuable gardners/maintainers who help me pull weeds and grow the Webform garden.

At the same time, I have strong beliefs about how I organize and share my garden, but I need to respect that I am part of a community garden.

Gardens and an open-source community like Drupal share interesting parallels. The Drupal community recognizes that we need guidelines and coordination to maintain our garden ecosystem. Open source is based on transplanting or cross-pollinating ideas and code. People and AIs can poison the well and affect all our gardens.

A bad patch can be as invasive as a weed, and an AI-generated patch could resemble poison ivy. With AI, we need to be mindful of how it affects our neighbors' gardens. I am even willing to admit that, in a well-manicured garden, introducing AI can feel like using a backhoe to dig a hole for a single plant.

The Drupal community’s ecosystem of contributed modules feels like a neighborhood. When I contribute to someone else’s project, it feels like entering my neighbor’s garden. As this post took shape in my head, I realized it wasn't going to be about my AI contribution to someone else’s project, but about my experience and feelings about contributing to someone else’s project using AI. Digging and planting can feel more intrusive than the plant itself. With the rise of AI, many questions and debates have emerged, and the discourse can at times border on toxic.

I decided to talk about our community's discourse around using AI because, as I worked with AI to create fixes and merge requests, I realized I was sometimes terrified someone would lash out at my efforts. I feared I would be accused of trespassing, accidentally stepping on someone else's roses, or introducing an invasive plant.

As I hammered away at the Webform security issue queue and Drupal.org moved security issues to GitLab, Codex unintentionally created a branch in the wrong private security repository. Keep in mind that Codex and I were working on 20+ issues over three months, so mistakes will happen.

I immediately apologized and feared someone would use this misstep to vent vitriol about AI. The opposite happened, and the awesome Neil Drumm from the Drupal Association stepped in and guided me and Codex in the right direction.

It sucks that I had to feel terrified, but the Drupal security team was incredibly supportive. I've seen and been part of heated debates, and I've learned that some people are passionate about code, and their tone can reflect that. We are a community of people who speak different languages with good intent. Still, it's troubling that every few of my AI-related blog posts receive a negative, troll-like comment that can intimidate people who use AI from joining and contributing to our community.

Everyone should be entitled to their own garden and their own opinions. If people have concerns about AI, they should voice them and can ban AI from their garden. People will listen and engage in open dialogue among those who are AI-pilled, AI-curious, and AI-cautious.

I don’t see a future in which walled and hostel gardens can succeed.

My first experience with walled gardens in software came while I was learning and experimenting with voice-based applications, largely driven by Amazon and Google. Frankly, seeing each ecosystem implement similar features in completely different ways was off-putting. AI has superseded voice applications, with more collaboration around protocols, open-source tooling, and models. However, I wouldn't be surprised if Amazon and Google still maintain walled gardens that limit what developers and AIs can do with Alexa and Google Voice. Fortunately, the Drupal community has very few walled gardens in our code, processes, and infrastructure.

Our collaboration, quality, and transparency may have brought us to this point and empowered us to embrace AI as we move forward. Looking back, my garden analogy holds because when AI and humans work together to maintain and grow our garden of open-source projects, we align to help humanity.

I like the Moderation Sidebar's simplicity. It provides a button in Drupal's toolbar to view and change an entity's moderation state. With Drupal core's new Navigation module, Drupal's toolbar API changed, and it now displays an entity's moderation state. However, the Moderation Sidebar module still needs to alter the displayed moderation state to open the moderation sidebar. The solution that AI and I collaborated on is a simple alter hook that adds the missing link to the toolbar's current entity's moderation state.

I stopped the AI from refactoring the module to remove duplicate code because it's ultimately up to the maintainer to decide how the code should be structured. The Moderation Sidebar's project page states it is minimally maintained, so I ensured the MR and its generated patch are straightforward and include test coverage, making it easy for a human or AI to review and merge.

Creating this contribution with Codex took a few prompts and a few minutes, compared with about an hour for me with no AI. Keep in mind that my one-hour estimate is based on 10+ years of experience contributing specifically to Drupal-related projects. For people new to Drupal, registering on Drupal.org, finding the project, cloning it, creating a fork, testing, committing, pushing code, opening an MR, and posting a comprehensive explanation of their solution to a minor problem is daunting.