Breaking Complexity to Democratize AI in Drupal

If something does not exist, almost anyone can now will it into existence using these tools in Drupal,

Kevin Quillen explains, capturing the essence of what drives his work in the platform's AI initiative.

After 16 years in the Drupal ecosystem, Kevin has witnessed the platform evolve from his early days escaping the limitations of licensed ColdFusion servers to today's cutting-edge integrations with artificial intelligence. His journey reflects a practical developer's perspective on what makes technology truly useful.

As Platform Lead at Velir and a triple-certified Drupal expert in both versions 9 and 10, Kevin has established himself as one of the community's most influential voices. His contributions span from co-authoring the "Drupal 10 Development Cookbook" with Matt Glaman to spearheading the AI initiative that has positioned Drupal as a leader among content management systems in artificial intelligence integration. Beyond his technical expertise, Kevin has been a vocal advocate for making Drupal more approachable, supporting improvements like the Gin admin theme becoming the default and pushing for updates to Drupal.org's design and marketing approach.

In this comprehensive interview with The DropTimes sub-editor Alka Elizabeth, Kevin shares insights into what makes effective Drupal collaboration work, reveals the strategic thinking behind the AI module framework, and discusses his vision for lowering barriers to entry for newcomers. He reflects on his transition from proprietary platforms to open source leadership, the real-world impact of his development work, and his predictions about features like ECA potentially becoming as essential as Views. This conversation offers a rare glimpse into the mindset of someone who has not only witnessed Drupal's transformation but actively shaped its future.

TDT [1]: You've been part of the Drupal community since version 5. What originally drew you in, and what has kept you committed for more than 16 years?

Kevin Quillen: Back in another lifetime, I was building websites on my own, first with some tricks with Flash and ActionScript, reading remote XML files for content for bands and businesses, and then for a company using Coldfusion. At some point in the mid-2000s, using a licensed language (Coldfusion) on managed Windows servers was not cost-effective and every single project we had felt very bespoke, making them difficult to maintain, requiring certain individuals holding tribal knowledge over this feature or that feature. It just was not sustainable. Keeping pace with development timelines over various projects in flight was also difficult.

At this point, I started evaluating open source content management systems. I tested at least a dozen, and not all were PHP-based. But I kept coming back to Drupal for 3 key reasons that many of the others didn't have (and some still don't): Views, Fields, Content Types. It was clear that there was strength in community and sharing solutions in the open, building for the greater good. The community was open and welcoming, ready to share ideas and techniques. The code worked great, was well tested, and easy to extend. There are a lot of bright, kind people in the community. I credit a lot of that to Dries's leadership style, philosophy, set of guiding principles for the project, himself and the mission. The leadership and community are what make Drupal successful, powerful, and fun. We're doing things other platforms and other communities are not doing, and I think we are in the best position we've ever been in.

As for what keeps me going, I will give you two examples.

After releasing the Drupal 10 Development Cookbook I collaborated on with Matt Glaman, a DrupalCon attendee came up to me and extended their gratitude and how it helped them get up to speed quickly on the changes from Drupal 7 to help them acclimate to Drupal 10. It helped him secure a better-paying job to support his family and encouraged him to keep moving forward. I found it deeply moving to have had that level of impact on an individual and their family. I still think about that interaction every so often.

You May Like

Interview

Meet Maya Schaeffer — Candidate for the 2025 Drupal Association Board Election

Interview

Meet Maya Schaeffer — Candidate for the 2025 Drupal Association Board Election

Lately, seeing the enthusiasm for AI solutions in Drupal leveraging the AI module framework, how rejuvenated the community seems from this (and other great initiatives), and vendor booth buzz at DrupalCon this year was also very encouraging. There are honestly so many avenues here for Drupal to excel in and lead the way, and it felt very good to be a part of the team to make that happen.

TDT [2]: Before Drupal, you built your own CMS and CRM. How did that hands-on experience shape your thoughts about Drupal's architecture and philosophy today?

Kevin Quillen: It makes me more appreciative of every single individual's effort. Maintaining and developing over a long timeline is not easy. Just look at how many open source projects out there are abandoned in less than 12 months. Yet, many people who were there when I got into Drupal are still around today, leading various systems and initiatives. This is a testament again to the leadership style Dries has, his delegation of areas of Drupal to key people who are themselves empowered to make decisions and delegate on their own accord, so on and so forth.

Retaining power is easy; relinquishing it is not. Time and again, we have seen this benefit Drupal in multitudes of ways where other projects that have 'my way or the highway' style of leadership have long stagnated or disappeared.

That said, on the architecture side of things, I think Drupal is in an excellent spot. The Drupal of today is obviously not the one from 15 years ago, and that's a good thing. Not all platforms can claim that. The breaking change of 7 to 8 was much needed–it helped lay a new foundation to help get us to where we are today. It happened at just the right time. Because of that, we have a more extensible system; Composer package management, incredible modules like ECA, AI, Experience Builder, Migrate framework, the works. We benefit from the upstream improvements in Symfony components, where the downstream impacts help code get better, slimmer, and more performant. The ability to pull in non-Drupal PHP packages is a great way to compose solutions further within modules. I can't imagine what Drupal will look like in another 10 years, only that with the continued leadership of many incredible people, it will be amazing.

TDT [3]: You're triple-certified in both Drupal 9 and 10. In your opinion, what matters more than certifications when evaluating someone's ability to work effectively with Drupal?

Kevin Quillen: Certifications are only one point of measurement for an individual. It is not weighed as heavy as some would think. Typically, our interview process is largely conversational. We don't filter out applicants if they are not certified (this goes for any platform, not just Drupal). Certifications can be attained whenever and we do have professional development time to help them get there after being hired. What I am looking for are core problem-solving skills, the ability to create solutions, and effective/proactive communication.

For example, in an interview, we provide simple scenarios ahead of time and ask to bring the solution to the interview. Sometimes it is incomplete, sometimes it is complete. Sometimes it is all done with AI. The real evaluation for me begins after that point–we have a conversation simply talking through the ask, what the approach was, and how they were trying to solve it. Maybe ask, conceptually, if requirements changed to support X, how would you adapt your code and why? If they didn't finish the initial code, that's fine, I am looking for intent, whether or not you were on the right path. Signs of problem-solving skills. You may know conceptually how to solve something, but may not know at the time how to express it in code.

Being able to construct a clear mental model of a problem and understand what it will take to solve it outweighs any number of certifications. At the end of the day, when you're reading feature tickets or bug descriptions, it's not the certifications that are going to magically complete them. Soft skills, problem-solving, and adapting to change go a long way.

TDT [4]: How do you see Recipes and Site Templates reshaping how newcomers (especially non‑developers) engage with the cookbook-style guidance in your book? Would you consider an update or companion guide that shows how recipes map to real‑world site templates, making Drupal's onboarding even smoother?

Kevin Quillen: Recipes themselves have been a long time coming. Site Templates is the next step up from that. It is really about composing your foundation instead of having to do it yourself, brick by brick, on every project. Extrapolating feature sets and exporting them out to new recipes leads to new combinations of recipes, leading to diverse Site Templates, which helps Drupal in one of its weaker areas–turnkey solutions for the small to mid-market areas.

TDT [5]: Velir has been a long-term part of your career. How has working at an agency shaped your understanding of Drupal's real-world strengths and weaknesses?

Kevin Quillen: I started at a great time, actually. I think we did one project in Drupal 7 when I began at Velir, but when Drupal 8 was released at the end of 2015, we started new project builds on that version. There were some learning curves, and we certainly had challenges, but the results were far better, and we were building features much faster. 

Integrations, migrations, and feature building can be done an order of magnitude faster than its competitors. We have incredible tools like DDEV, Drush and Composer now, and in my opinion, they have several strengths against some big-time, big-money enterprise competitors.

However, being exposed to other systems reveals some areas where it can improve. Other systems have features that allow you to create full or partial content archives to allow pushing authored content from staging to production, some have page building experiences, and some are better at multi-tenancy. If you need features like that, then there can be challenges in the solution with Drupal. Overall, I find that Drupal's strengths tend to outweigh its weaknesses more often than not. The good news is that features like Experience Builder (a new page-building experience) and content sync support are being worked on by fantastic individuals.

TDT [6]: The AI initiative you helped lead has become one of the most exciting developments in Drupal. What motivated you to get involved with AI in the first place?

Kevin Quillen: I understood a few things about AI that I felt many were overlooking about the technology in general at the time. One, new tech can scare people–make it user-friendly. Two, to sell complicated (or new) technology, you have to make it as simple as possible. Three, you have to make a user feel like they just walked a mile in one step, without needing to learn a bunch of jargon and new terminology or more importantly, "how" it works. Make the user feel smart and empowered. This is how you gain adoption of new ideas.

With that mindset, I set out to try and get AI momentum in Drupal by abstracting out the hard parts and making solutions of what is possible–the user simply enables one of the modules and uses familiar interfaces. The big hit came with WYSIWYG integration–the ability to compose text and use AI to generate new ideas, change the tone of text, translate into other languages, or provide feedback, which really tracked well with end users. This was the 'a-ha' breakthrough moment where many people started to realize AI is not "just" a chatbot and can facilitate a myriad of assistive scenarios.

Drupal was one of the first CMS to feature such deep integrations to AI, and a lot of those same features are now table stakes. Today, we continue to lead with deeper integrations, agents, page builder integrations, the ability to choose your AI provider and models, and even composing new behaviour with ECA with drag and drop interfaces that literally make feature-building limitless.

If something does not exist, almost anyone can now will it into existence using these tools in Drupal.

TDT [7]: What were the key architectural or philosophical decisions you pushed for early in the initiative to ensure it wasn't just another one-off integration, but a foundational tool that others could build on? And how has the community response shaped or validated those decisions since launch?

Kevin Quillen: Right away, I wanted to focus specifically on integration with OpenAI. At the time, it was mega popular due to ChatGPT. Some of the complex parts were already solved–I didn't have to explain to people what ChatGPT was, by then it was rapidly becoming part of daily conversation or news everywhere you looked, worldwide. I think if I had picked any other AI two years ago, part of the uphill battle would be having to explain who and what it is first. With ChatGPT, the interest was already there; it was already a 'known' thing. That just left showing what AI might look like or what AI could do in a CMS like Drupal, leveraging OpenAI's API. The idea was that really any AI could facilitate this–I just chose the biggest one with a great PHP API wrapper available in the wild so I could start building the features quickly.

Once it started gaining traction, I knew we needed to rally the wagons around a central place. A single foundational module that could combine the popular features from the OpenAI module, but built on top of a framework so that any provider could be used and not just OpenAI. That led me to Marcus and Jamie, and getting the ball rolling to build a lot of momentum with what they had been working on. 

This wound up being a handful of calculated winning moves as other platforms continually reference what Drupal is doing for their own ideas and features around AI, which was one of the goals. Two, Marcus Johansson and crew have created a phenomenal framework for easy extension and development of AI features. It is the acceleration everyone needs to get going without reinventing the wheel over and over in their own module(s). To me, this was important to getting greater traction with end users instead of having them try to decide from dozens of modules what they need. Many people are curious and want to try out AI on their site, so we've done the best job possible to provide that for end users, site builders and developers. With the new Drupal AI initiative and inclusion in Drupal CMS, and how much it's inspired users and the community, it felt like the right decision(s).

TDT [8]: What's your vision for how AI should show up in the Drupal CMS? Are there specific use cases or submodules you're championing for inclusion that you think could radically reduce the learning curve for new users?

Kevin Quillen: I think we are there, honestly. We want to show 'just enough' AI in DrupalCMS to be useful for site builders, but not 'too much' AI features to overwhelm them. I think this is really going to come together with Experience Builder down the road–site building aspects of Drupal, along with real-time component/content building, is a knockout. Of course, those who want to go further or do more with AI are more than able to do so, but I think we are striking a good balance so far. The community is seeing what works, what doesn't, and iterating on that, refining.

TDT [9]: You've collaborated with people from several companies on community-driven Drupal projects. What makes those collaborations work, and what's the hardest part?

Kevin Quillen: The collaborations work when the goals and expectations are aligned all around. The AI initiative is the best example of that. Some of the hardest parts are always aligning on time (people across different time zones), dedicating time to contribute or maintain consistent meetings, and committing to the long term.

TDT [10]: You've spoken about making Drupal more approachable. What do you think are the biggest blockers for new developers or site builders today?

Kevin Quillen: There were a few key areas I was thinking about when I made that statement, and since then, those areas have had pretty significant progress.

For one, it was recently announced that Gin will be the default admin theme going forward. Drupal has needed a slick, friendly, 'easy on the eyes' admin for a very long time. It is important for first-time users to have a sleek, modern administration theme. Believe it or not, many first-time opinions are hedged a lot on the admin experience, and the visual aspect is a big part of it. It was functional under Seven or Claro, but it wasn't exactly "sparking joy" for many end users. As developers, we know what it can do under the hood, but with dated UIs, it's hard to convey that to non-developers. Back in Drupal 6 and 7, I would use an admin theme called Rubik to add a level of softness and approachability to the look and feel of Drupal internals.

I think Gin is a very appropriate admin theme that makes less technical users feel very comfortable in the admin, even if they do not know exactly what each area of the admin is. It's hard to explain, but it's important in user experience design. Visual aesthetic user experience like this is why companies like Apple made a huge comeback in the 2000s and why virtually anyone can understand and navigate their systems even if they know little about them.

Second, DDEV has become the recommended developer stack for working on or with Drupal. This was a major boost in reducing friction and accelerating onboarding developers and themers into a consistent runtime environment without having to learn Docker or other tools to get a full stack running on their machine. Older tools used to favour one operating system over another, making it more difficult if you were on Windows vs Mac or vice versa. Now, anyone can onboard no matter what their operating system is and not fuss about installing PHP, MySQL/Maria, nginx and the rest of what you need to develop. This was a long time coming–before this point there was a lot of confusion around 'what's the best to use' or 'how to set up Vagrant' or 'where is XAMPP' and loads of other outdated tech or documentation that simply made it difficult for the uninitiated to find a hands-off starting point to get down to actually building something. This is big for teams and organizations that want to get right into development or theming without first having to learn how to run servers or several layers of technology stacks just to get started.

Lastly, I wanted to help get the look and feel of drupal.org updated to match modern websites and showcase Drupal's capabilities. This would help make Drupal appear fresh and appealing while demonstrating short elevator pitches of its best stuff (AI, ECA, Views, etc) to convince marketers, developers, and site builders that Drupal is extremely capable, current, and the tool to build the CMS or web application they desire. This, to me, was a similar issue with the Gin admin theme in core–by updating drupal.org, it will make users think differently about Drupal without actually having to change Drupal core itself to match that expectation. Think of it as we have everything most people need for site building, we just need to get them to come "in the door" and see for themselves. Part of that was also helping update the marketing to appeal to younger, newer developers to attract new people to the community. Based on the responses of non-Drupal developers or users to trying out Drupal CMS or seeing the new website design for drupal.org, it has been mostly positive, so I believe it is working.

Much of this happened after I expressed the need for change, and these were some of the pillars behind my desire to run for the Association Board last year. We're on a good track with these items complete or in progress.

TDT [11]: What gaps or frustrations in the default Drupal installation flow led you to create Velir Base, and how has it changed the way your team approaches the first few hours of a new project?

Kevin Quillen: A lot of that stemmed from my personal preference to not use distributions or install profiles and needing a halfway point between the Minimal and Standard install profiles. Minimal was not enough, and Standard was too much for me. The Recipe feature was a great fit for us here. Velir Base is based on that halfway point where I wanted the Drupal install to begin at (no Shortcuts, Comment, Help modules, default settings, etc) with extras added in that we always use (Gin, Memcache, Pathauto, Metatag, Robotstxt, Redirect, Key), so new client projects could start ASAP. Combined with a tailored DDEV configuration that we maintain, we can initiate and literally start POC or feature work on a project in under five minutes.

Before, if we had to install Standard and then go through and unwind and remove what we did not want, this would take a few hours of human effort; now we can just run a command and apply those changes along with the preferred configuration of contributed modules almost instantly. It's been a real accelerator all around, and in time, I expect to see a lot more contributions in that regard with recipes for Drupal (Drupal CMS is already proving this approach).

TDT [12]: You've said Drupal needs a better front door, referring to Drupal.org's dated design. Drupal.org recently underwent a much-needed redesign. In your view, what should the next phase of that evolution focus on beyond aesthetics to better serve newcomers, contributors, and decision-makers alike?

Kevin Quillen: I think this is already underway, but I have expressed that there are things that can be done. The homepage, for example, should use its real estate to pitch some of the biggest features of Drupal with Drupal CMS product-like screenshots. Calls to action showcasing heavy-hitting features like AI, ECA, Views, Experience Builder, Search, Field UI, etc, would be great homepage items. Between the homepage and deeper parts of the site, we could use extensive landing pages that provide more detail on those features and make the case for using Drupal. Think of a case-study / landing page format layout page for Drupal features vs the typical module project page we have now. I think showcasing features and incredible modules like AI and ECA, similar to Apple-like product pages, would really go a long way.

For me, I honestly believe this would be a help to both demonstrating what Drupal is capable of, what it has today, and convincing those on the fence to evaluate Drupal or give it a second chance if they haven't used it in several years/versions.

TDT [13]: After nearly two decades in the Drupal ecosystem, what keeps you excited about the platform's future, and where do you see the most potential for growth?

Kevin Quillen: I have lived through several versions of Drupal. I truly believe Drupal is in its best state yet and will continue to get even better. AI integration will get more refined, better. ECA will (I predict) eventually be a core feature like Views became, accelerating site builder functionality. Experience Builder will deliver the page-building experience users have clamoured for. The community will contribute more modules and functionality and Drupal will remain one of the best open source CMS platforms for a long time coming.

As Dries recently said in a Driesnote, "Drupal doesn't chase trends, we set them."