Vibe Coding Drupal: My Initial Foray

It would be an understatement to say that the use of AI in the Drupal community was a hot topic at recent events like DrupalCamp Florida, DrupalCon Chicago, and Drupal Dev Days in Athens. There have been many passionate conversations on the topic, but thankfully many of them were thoughtful and considered, too.

Artificial intelligence has its boosters and its skeptics, but particularly in light of the significantly more capable models released in recent months, many who have been waiting on the sidelines are interested in exploring how AI tools might make their lives easier.

To help everyone share their explorations, we now have an AI Learners Club, where people convene on a Zoom call and share what they've been working on, what they've found useful, and what questions they have.

Leading the charge has been former Acquia and longtime Drupalist Angie Byron, with notable contributions from Scott Falconer, Amber Matz, and many others. I’ve also been inspired by recent writings by Jacob Rockowitz, recounting his own explorations of the potential AI tools hold for Drupal development.

The inspiration

Another notable part of my own DrupalCon Chicago experience was helping to deliver Drupal in a Day to dozens of young people eager to take in all that's exciting about Drupal. I covered the Drupal Canvas section, which gave me a chance to play around with all that was new and exciting in Canvas 1.3, including the ability to create templates for your structured content.

Over the course of my years working with Drupal, I have built these kinds of templates with PHPTemplate, Twig, Layout Builder, Acquia Site Studio, and even React on a headless site or two. I was interested to see that in Drupal Canvas you can map the value of structures data fields to component properties. That provides a lot of flexibility, but it does mean that if the field type you're using doesn't have an existing mapping, you might have to write custom code.

I thought about how Acquia Site Studio and Layout Builder allow site builders to directly place field output, and how useful I had found this over the years. For some super simple sites I have built, I only used layout builder to give a couple of content types a little more structure in their output, and otherwise stuck with a minimally modified existing theme.

I was solidly among the people who had been wanting an excuse to experiment with all the shiny and intelligent coding tools. This seemed like the perfect place to dive in.

Where the rubber meets the road

I had been using Claude quite a bit of late, so I decided to start there. I gave it a descriptive prompt and made sure it had read access to the Drupal Canvas code in a local project. Within minutes I had an initial version of a module I could install. The component showed up in the Canvas component library and I could drag it into my templates. But that was pretty much it.

I kept asking for more improvements, and continued to make incremental progress. First we got the input working to select the field to use, and then with a little more work, once a field was selected to provide a list of formatters appropriate for the selected field. But when you selected a formatter, the entire form would reset. Claude would confidently state that it had found the solution. When I tested it (after manually clearing the cache) I would find that the problem had persisted. That back-and-forth continued for a while, until… I got a notification that I had exhausted my token limit, and I would have to wait until a five-hour window had ended.

In hindsight it’s clear that I should have reset the context by starting a new task, but I stubbornly carried on. I ran out of tokens, and then shifted to other work. I came back later, and quickly ran out of tokens again. [Note: Anthropic has apparently eased the limits since this experience]

I came back the next morning, and was greeted with a notification that Opus 4.7 was available. I decided to give it a try, since I had been using Sonnet until then. Claude ran out of tokens before it completed its first task. (More recent experimentations with Opus 4.7 have been better)

I then pivoted to running Codex inside VS Code. It needed lots of permissions granted but could eventually run commands in DDEV, directly test Drupal’s output as it made code changes, and so on. I quickly made some substantial progress, eventually solving all the biggest functional challenges. Since these were all APIs I hadn't encountered before it would have taken me weeks to get this far on my own.

Having reached my original MVP vision in just a couple of days, I decided I should see if I could also get this new module to support third-party settings. Selfishly I knew that this would mean that the ecosystem of Date Formatters could all be used, but I'm sure there are many more use cases that having this support will allow site builders to take advantage of. That added a fair bit more work, particularly because the Date Augmenter API has its own AJAX features and makes use of Drupal’s States API. Ultimately Codex was able to identify a pattern that Layout Builder used to rewrite states pattern to make them work within the settings tray, and implemented a similar approach for Canvas Field Component.

It wasn't all sunshine and rainbows. I did get charged a few times to refresh my OpenAI tokens, in addition to my monthly subscription. But spending a little money to get the module release-ready while I was still immersed in it was well worth it. If I expected to do this kind of work on a regular basis, I would definitely upgrade to a bigger account. And of course, if I was more patient I could have waited for my tokens to refresh. I’ll follow up with a more detailed breakdown of what worked and what didn’t, as well as how the tools I used compared, in a follow-up post.

In the end, I pushed myself and the AI tools to build out as robust an initial release as we could collectively manage: not just working code, but full CI/CD pipelines and automated tests, to make the project more maintainable over time. Here’s a quick demo video I made of the features in the 1.0.0 release of Canvas Field Component:

What the experience tells me about the future

In the end I was blown away by the ability to quickly realize a working version of my vision. I've previously spoken about my thoughts on building out a Drupal module based on whatever inspiration strikes you. I firmly believe that a proof of concept is an important early step. That helps you maintain your own excitement, but it also helps you collect important feedback on your idea: has someone already done this? How useful is the approach I'm proposing? Are there ways this could be even better? Could what I have in mind help solve problems I hadn't even considered?

Using AI to build a higher fidelity proof of concept more quickly means we can innovate much more quickly. To be clear, not all these explorations will be successful. Not because the code produced wasn't bulletproof (and it likely won't be, at least in the initial version), but more because some ideas will inadvertently duplicate existing solutions, or prove impractical, or maybe not even useful. 

Edison used to say that genius is 99% perspiration and 1% inspiration. Better tools can help the Drupal community benefit from the inspired ideas we collectively bring together, faster and with less effort.

That’s not to say we should abandon caution and the reputation Drupal has built as an enterprise-ready, trustworthy solution. Code quality and reliability should not be diminished by the community’s adoption of AI — if anything they should remove some of the common objections around having the time or expertise to make sure best practices are followed.

What's next for me

I do have an idea for another module that could make Drupal Canvas more flexible, by allowing any token to be mapped to a component property. I think it could be powerful because with tokens you can easily apply modifiers, for example to set a view mode or image style.

Before I dive in again, however, I want to be more disciplined. I'd like to see if I can get better results, faster, and with fewer tokens consumed. I think Skills could be an important part of that, but I want to explore some different approaches. 

Of course, Canvas Field Component is nowhere near the only module I maintain. There's a growing number, and with Drupal 12 due later this year, I can use all the help I can get in creating updated versions that are ready. No doubt the community will have even better tools available, and a recent experiment by Dries on AI-generated Rector rules sounds extremely promising.

For my own work, I would love to make the process of updating my roster of modules as automated a process as possible. For example, using AI to help increase code coverage before the depreciations are finalized should make it a lighter lift to evaluate the readiness of my upgraded modules. And of course, there are deterministic approaches that can help as well. Jürgen Haas’ approach for using CI to regularly test for upstream changes is something I would love to have in place for projects like Event Platform with many dependencies.

It’s an exciting time for Drupal. There are certainly risks associated with the growing adoption of AI tools, even in the hands of people with good intentions. But the promise is compelling, and the capabilities available continue to expand. And they can act as a force multiplier to help us make our inspiration a reality.