![A user at a computer, using AI with a virtual calendar](/sites/default/files/styles/blog_hero_image_mobile/public/media/image/2026-06/AI-tools-calendar.jpg?itok=iqax9rAv) Image ![Martin Anderson-Clutz](/sites/default/files/styles/post_content_attribution_headshot/public/media/image/2024-04/Martin%20Anderson-Clutz-Teal.png?h=04d92ac6&itok=FR0HL2Zr) [Martin Anderson-Clutz](/people/acquians/martin-anderson-clutz) Senior Product Marketing Manager, Drupal Acquia ## Collection [Drupal](/blog/series/drupal) # Vibe Coding Drupal: A Force Multiplier for Contrib June 25, 2026 10 minute read [Share this blog post on LinkedIn ](https://www.linkedin.com/sharing/share-offsite/?url=https://www.acquia.com/blog/vibe-coding-drupal-force-multiplier-contrib) [Share this blog post on Twitter ]() [Share this blog post via Email ]() Maintainer burnout threatens Drupal's 50,000+ contrib modules. How vibe coding with AI is becoming a lifeline for open source. ![A user at a computer, using AI with a virtual calendar](/sites/default/files/styles/blog_hero_image_mobile/public/media/image/2026-06/AI-tools-calendar.jpg?itok=iqax9rAv) ## Collection : [Drupal](/blog/series/drupal) ## **The Journey from Core to Contrib** Right now, somewhere on drupal.org, a module that hundreds of sites depend on hasn't had a release in two years. The maintainer hasn't abandoned it out of indifference; they're burned out. They're weighing an upstream library's breaking changes against their available evenings, doing the math, and silently concluding it's not worth it. This is not a Drupal-specific problem. The [2024 Tidelift State of the Open Source Maintainer Report](https://www.tidelift.com/open-source-maintainer-survey-2024) found that 60% of open source maintainers work completely unpaid, and [44% of those who have quit or considered quitting cite burnout as the reason](https://byteiota.com/open-source-maintainer-crisis-60-unpaid-burnout-hits-44/). The average unpaid maintainer contributes nearly 9 hours a week to their project; for popular projects, that climbs to 20-30 hours. The gap between what the ecosystem extracts and what it gives back is enormous, and it has consequences. Drupal's more than 50,000 contributed modules are only as healthy as the people maintaining them. This series has been about how AI tools are changing my own development workflow: from an [initial foray](https://www.acquia.com/blog/vibe-coding-drupal-my-initial-foray) into the concept, to a [scent of progress](https://www.acquia.com/blog/vibe-coding-drupal-scent-progress), to using AI as a [code-directing accelerator for Drupal 12](https://www.acquia.com/blog/vibe-coding-drupal-code-directing-accelerator-drupal-12) readiness. For this fourth installment, I want to make a larger argument: that these tools aren't just a productivity boost for individual developers. They're a potential lifeline for the open-source model itself. Recently, at [Drupal Dev Days in Athens](https://devdays2026.drupal.org.gr/), I put vibe coding to the test on an established contrib module. What I found suggests that AI has the potential to dramatically lower the activation energy of contrib maintenance, making the most demoralizing parts of the job feel manageable again, and keeping maintainers at the table when they might otherwise walk away. ## **The Contrib Maintenance Challenge** Back in 2024, [Jürgen Haas](https://www.drupal.org/u/jurgenhaas) and I decided to [take on maintenance of the Fullcalendar module](https://www.mandclu.com/blog/mark-your-calendars), to give Drupal site owners a community-supported alternative to a popular module that had seemingly fallen into a "freemium" model. This is exactly the pattern maintainer burnout produces. A module with significant adoption becomes the responsibility of whoever has the time and energy to keep it alive, and usually, that's nobody. Jürgen and I stepped in because someone had to. But the scope of work involved in doing it *right* is a constant reminder of why so many maintainers eventually walk away. A few months ago I noticed that the [Fullcalendar JS library](https://fullcalendar.io/) had beta releases for a new major version. I talked to Jürgen about it and we agreed to wait until a release candidate before we'd start supporting it in our module. Keeping pace with an upstream JavaScript library is exactly the kind of grinding, unglamorous work that wears maintainers down: you can't ignore it, but it offers little of the creative satisfaction that drew most developers to open source in the first place. In the days leading up to Drupal Dev Days in Athens, I noticed there was indeed a release candidate available, so Jürgen and I decided we would work on supporting it during the contribution day wrapping up Dev Days. To get a sense of the scope of work ahead, I asked Gemini to [analyze our module](https://gemini.google.com/share/a3fc4205c92f) and estimate the work required, as well as the possibility of maintaining backward compatibility. ## **AI as a Co-Maintainer** When contribution day rolled around, I had AI do a first pass on implementing the changes needed to support the new major branch of the Fullcalendar library. It turned out to be less work than earlier analysis had indicated, because most renamed parameters didn't impact the Drupal module. In fact, with less than an hour's work I had a working version, with the upgraded calendar running inside Drupal. That sentence deserves a pause. Under an hour, for work that in an earlier era might have consumed most of a contribution day, work that, if it had felt too daunting, might have been exactly what convinced a maintainer not to bother at all. The new version of the Fullcalendar library also includes new [theme options](https://themes.fullcalendar.io/): Monarch, Forma, Breezy, and Pulse, each with four or five color variants requiring one extra CSS file. I decided to map those to Drupal libraries so that the existing theme setting could expose all the new options to site builders. Adding the libraries was slightly tedious, but not difficult. I had a nice surprise when I went to wire up the new libraries as options in the settings form: the [GitHub Copilot VS Code extension](https://marketplace.visualstudio.com/items?itemName=GitHub.copilot) spotted the pattern of what I was doing and began suggesting autocompletes that implemented the bulk of the work for me. Small, but meaningful. The drudgery of repetitive tasks is one of the things that quietly erodes a maintainer's will to continue over time, and anything that reduces it matters. I've since noticed Copilot kicking in periodically during repetitive work. One particularly handy case: populating method comments. If you've neglected to write them, [phpcbf](https://github.com/PHPCSStandards/PHP_CodeSniffer) can create the docblocks automatically, but blank. Start populating them one after another, and Copilot recognizes the pattern; as you finish one, it auto-suggests the next, which you accept with a tab. Small wins, but they accumulate. ## **Returning to Fullcalendar** A few days ago, Jürgen pinged me to let me know the Fullcalendar JavaScript library had a stable release. The incremental changes required since the Dev Days sprint were modest. A renamed variable was reverted. That also surfaced another that had been renamed since version 6, requiring an update hook to convert any existing configuration. Thanks to the work already done, and a better toolset, the originally anticipated scope of the upgrade was completed in under an hour. With a [final changelog](https://v7.fullcalendar.io/changelog) in hand, I asked AI to do a deeper analysis of v7 features the Drupal module didn't yet support. I turned the [prioritized report](https://claude.ai/code/artifact/fb198207-0508-4d8c-bf04-69818bd6ea3c) it generated into a [meta issue](https://www.drupal.org/project/fullcalendar/issues/3605109) and started working through the list. Within a couple of days, it was complete. In addition to the new themes, sites using the updated Fullcalendar module can now leverage dark mode, a new MultiMonth (year) display, sticky headers, and more. I moved through that work so quickly that I decided this was an ideal moment to tackle features we'd long talked about adding. First: test coverage, to prevent future regressions. Next: a reorganized settings UI, because even as a maintainer I sometimes struggled to locate specific settings. I got AI to suggest a new structure, refined it, and it was implemented quickly. It's not final (I want community feedback before going further), but it *exists*, which it wouldn't have without this toolset. [Drupal 12](https://www.drupal.org/project/drupal/issues/3449806) compatibility followed, and then I was ready for the two features I'd most wanted to add since becoming a maintainer: AJAX loading of event data, and tooltip display of event information. AJAX loading addresses a real performance challenge. Calendar displays can be slow for sites with lots of event data; pushing large datasets to the browser on initial page load is exactly what you want to avoid. With AJAX loading, the calendar renders first, then requests only the data needed for the visible range. As users navigate, it fetches more. For my testing, I generated 200 events, about 7k of JSON. Even a dense month came to just over 1k. The performance benefits scale quickly with event data volume. One interesting challenge: the Fullcalendar module allows a mix of date fields and tries to parse from potentially divergent types. When working on AJAX loading, the AI agent initially planned to ingest all date information matching the view's filters, then narrow by the calendar-supplied date range before passing it to the front end. That would have delivered front-end performance benefits, but would have unnecessarily processed large data volumes. I caught the direction it was heading, interrupted, and redirected it: use that approach as a fallback, but where fields are specified in the view configuration, use those to pull only what's actually needed. This kind of human-AI collaboration, where the developer understands the domain deeply enough to catch and correct the agent's approach, is a recurring theme in this work. The AI accelerates dramatically. The human still has to lead. The tooltip display proved the most ambitious feature yet. I wanted it implemented as a submodule (requiring third-party settings support), with content also loading via AJAX to avoid injecting data that might never be displayed, and site builder control over what's shown via [view modes](https://www.drupal.org/docs/user_guide/en/structure-view-modes.html), a robust, reusable way to manage what information appears and how it's formatted. The biggest challenge was the number of pieces that had to work together before tooltips were first visible: settings saved and accessed correctly, endpoint queried properly, positioning working within the display. Early on, I nudged the agent to start including debugging output so I could give direction, and it incorporated that into its process quickly. Image ![A Drupal 11 site using the Fullcalendar module, showing a calendar display](/sites/default/files/styles/wysiwyg_full_width_desktop/public/media/image/2026-06/Screenshot%202026-06-24%20at%201.24.45%E2%80%AFPM.png?h=a7da6aee&itok=bexkApOi) Just some of the new features available in the 4.0.x branch of the Fullcalendar module: new themes, dark mode, and tooltips.Ironically, the AI agent found an [existing discussion thread](https://www.drupal.org/project/fullcalendar/issues/3514977) in the Fullcalendar issue queue and automatically ingested it while developing its implementation plan. Since a number of community members had already weighed in, I'm waiting for feedback on the approach before merging, but the implementation is there, ready to be refined. Once tooltips are done, I'll tag a release candidate, then a stable release. The next step after that will be updating the Events Calendar recipe, which already uses Fullcalendar and remains the easiest path to adding a robust event calendar display to a Drupal CMS site. ## **What This Means for Open Source** When I first started working on Fullcalendar almost two years ago, it took several weeks to reach a point where we felt comfortable tagging a release candidate. Even then, the feature set was short of what we had wanted to deliver. In just days, with the toolset available today, we've integrated a new major version of Fullcalendar, significantly expanded feature coverage for the library, added test coverage, reorganized the settings UI, implemented AJAX loading, and built tooltip support. Work I would have estimated in weeks, the kind of scope that might have made a maintainer say "not this year, maybe not ever," is done. That's what I want this installment to leave people with. Not just that AI made my job easier. It did. But more importantly: **this changes what's possible for open-source maintainers.** The open-source model depends on volunteer labor. That labor has a cost. Maintainer burnout is real, widespread, and a genuine threat to platforms like Drupal. The most demoralizing work (chasing upstream dependency updates, ensuring API compatibility, grinding through repetitive scaffolding) has always been the work that tips maintainers from "I'll get to it" toward "I'm done." When that work feels less daunting, maintainers stay. Modules survive. The ecosystem remains healthy. Vibe coding with AI isn't just a productivity technique for individual developers. It's a potential force multiplier for open-source sustainability, one that lowers the activation energy required to keep thousands of Drupal modules alive and modern. The human still has to lead, stay vigilant, understand the domain, and make the calls that matter. But the barrier to doing that work has never been lower. That matters for every Drupal site running on contributed modules whose maintainers are one bad month away from walking away. ## **Try It, and Help Shape What Comes Next** If you're building with Drupal and need a calendar solution, [give Fullcalendar a try](https://www.drupal.org/project/fullcalendar). The module now supports Fullcalendar v7 with dark mode, a new MultiMonth (year) display, AJAX loading, sticky headers, multiple new themes, and more. With the [Events Calendar recipe](https://www.drupal.org/project/events_calendar), getting up and running takes minutes. If you find something missing, run into an issue, or have feedback on the new settings structure or tooltip approach, [open an issue in the queue](https://www.drupal.org/project/issues/fullcalendar). Community feedback, particularly on the UI reorganization and the tooltip submodule before it's merged, is exactly what the module needs right now. That kind of engagement is what makes the open-source model work, and what makes a maintainer's investment in building this out worthwhile. Image ![Martin Anderson-Clutz](/sites/default/files/styles/post_content_attribution_headshot/public/media/image/2024-04/Martin%20Anderson-Clutz-Teal.png?h=04d92ac6&itok=FR0HL2Zr) [Martin Anderson-Clutz](/people/acquians/martin-anderson-clutz) Senior Product Marketing Manager, Drupal Acquia [Share this blog post on LinkedIn ](https://www.linkedin.com/sharing/share-offsite/?url=https://www.acquia.com/blog/vibe-coding-drupal-force-multiplier-contrib) [Share this blog post on Twitter ]() [Share this blog post via Email ]() ## Keep Reading [View More Resources](/resources) [Image ![A person at a keyboard, using AI to channel their inspiration into Drupal](/sites/default/files/styles/card_tablet/public/media/image/2026-05/Gemini_Generated_Image_cj5ooocj5ooocj5o.png?h=d1908cb8&itok=veLLgaI5) Blog Article 9 min ###### Vibe Coding Drupal: My Initial Foray Insights on AI's potential for Drupal: How AI tools like Claude and Codex accelerated the creation of a new Drupal module, "Canvas Field Component." Drupal ](/blog/vibe-coding-drupal-my-initial-foray) [Image ![A futuristic Drupal contributor working in an AI-enhanced IDE](/sites/default/files/styles/card_tablet/public/media/image/2026-05/Gemini_Generated_Image_t433ugt433ugt433.png?h=d1908cb8&itok=vm3O3P8Y) Blog Article 11 min ###### Vibe Coding Drupal: the Scent of Progress AI wrote a Drupal module. Discover why "directed coding," using IDE tools, and human oversight are essential to avoid the "scent of progress" trap. Drupal ](/blog/vibe-coding-drupal-scent-progress) [Image ![The hands of a developer at a keyboard summoning AI to create tools](/sites/default/files/styles/card_tablet/public/media/image/2026-06/VibeCodeTools.jpg?h=1d4eb506&itok=xh4VOqXC) Blog Article 7 min ###### Vibe Coding Drupal: Code Directing an Accelerator for Drupal 12 Learn how "Code Directors" use AI to guide development, streamline Drupal contributions, and accelerate preparation for Drupal 12 Drupal ](/blog/vibe-coding-drupal-code-directing-accelerator-drupal-12)