I've just begun exploring how to incorporate AI into my development workflow to tackle ongoing challenges for my client. Drupal's AI initiative is progressing rapidly with continuous updates and improvements. At DrupalCon Chicago, there will be numerous discussions about the future of AI in Drupal.

At the same time, through various channels like the Talking Drupal podcast and Planet Drupal feeds, we are hearing about people achieving significant success with AI-driven development using coding agents such as Claude Code. There is understandable hesitation within the Drupal community about adopting AI. Additionally, there is a lot of buzz and hype around AI replacing traditional software development.

Personally, I cut through the hype to find the clear truths about AI. I am specifically listening to what senior engineers like Steve Yegge, Kent Beck, and Martin Fowler say about the future of AI, software, and software development. I recently found "The Pragmatic Engineer" podcast, which, for me, is the best place to get genuine, honest, and tangible insights into the future of AI-driven development.

My personal conclusion is that, for better or worse, AI-driven development is something individuals, teams, companies, and communities need to adapt to and adopt. For me, the starting point is setting up a local Drupal development environment where I can experiment with, use, and develop AI-specific tools for site builders, content authors, and developers. Everyone involved in building and maintaining a Drupal application should have the opportunity to work with AI to enhance their experience and collaboration with other team members.

In my previous post about Claudeing in Symfony within Drupal, I started calling my AI development environments "playgrounds." Playgrounds are public community spaces where people can run around and collaborate with the goal of having fun. I plan to set up a Drupal AI playground using Claude Code and share the experience, code, and documentation with you.

I am guilty of being one of those parents who read the playground rules before entering, looking for the standard ones like "No dogs allowed," while also paying attention to the more obscure rules, such as "Metal pieces may be hot if exposed to the sun." The obscure rules, like the "metal gets hot" rule, depend on context; ironically, a decade ago in New York, they built metal play domes that ended up burning children. AI and LLMs definitely need context, which can also be rules, so there's a clear connection to this analogy.

My goals for this exercise and subsequent blog posts are to do my best to gather and document the current state of using Claude Code with Drupal while building a local development stack that can adapt and improve as tools and recommendations evolve. This will be my personal playground. People are invited to explore and borrow from it. My hope is it will inspire more people to share their tools, tips, and tricks for agentic coding with Drupal. From my previous experiments with Claude Code, I see significant value in creating documentation for both humans and AIs.

To set up my Drupal playground, I will need a few things…

• A local development environment: DDEV.
• The software, which is, of course, Drupal.
• An AI/LLM, which will be Anthropic's Claude Code.
• Finally, to manage the playground, I will use PHPStorm, a traditional IDE, with its AI agent, Junie.

The documentation, which will be Markdown files in a /docs folder, will follow a standard structure: a dedicated setup document, then extensions (also called modules, plugins, etc.), and finally some general tips and tricks.

DDEV is the go-to tool for local Drupal development. Its documentation is so thorough that there's little an AI can add to setting up a DDEV environment. When I set up a DDEV environment for Drupal, I often create an install command that runs a bash script with Drush commands like site:install, pm:enable, theme:install, and config:set, among others, to ensure a repeatable process for reinstalling the application from scratch. In the past, I was guilty of writing complex bash scripts with a demo module along with the Configuration Rewrite module and installation hooks to achieve this task. This entire outdated approach has been replaced by Drupal Recipes, which offers a tool for defining and modifying configuration when installing a module to provide a feature or enhancement to Drupal.

Recipes serve as the building blocks of the Drupal CMS, offering a starting point for newcomers. I pay attention to what is happening in Drupal CMS. I see Drupal CMS as a vast cookbook from a specific restaurant. Meanwhile, I am working on creating my own cookbook for my restaurant with similar recipes.

A simple example is: I want to experiment with the AI module and set up a demo with a single step. Because my API keys already exist in a private /keys directory, my AI recipe can automatically configure them, whereas Drupal CMS cannot assume that. In short, my recipes will incorporate components from other recipes, specifically from Drupal CMS, and will be tailored to my specific needs.

Claude Code updated my local development Drupal install process with a single prompt by converting my Drush installation command into several Drupal recipes. I told Claude to look at similar recipes in Drupal CMS for inspiration.

Claude generated my base, translation, development, and AI recipes without any issues, but when it came to creating the admin recipe that configures the Gin admin theme, Claude and I encountered this long-standing problem: Stop copying block configuration from active theme when enabling a new theme [#3105597].

Reflecting on my experience working with Claude to resolve the duplicate extraneous blocks being installed via the admin recipe is difficult. There are numerous issues and patches related to this problem, enough that I was confident a single patch would fix it. I asked Claude to review the issues and find a patch, which it did, then added the patch to composer.json, but for some reason, it wouldn't apply. I spent an hour trying to manually apply the patch, running various composer commands to delete and reinstall, but nothing worked. Claude was not very helpful.

This experience was so frustrating that I can't remember everything I tried to do with Claude and manually. Finally, I realized I was using the latest and greatest 2.x version of Composer Patches, which has new, improved commands that generate a dedicated patches.lock.json file. It's very likely that our unfamiliarity with the new workflow led us to stumble.

Ultimately, I reversed all changes, cleared Claude's history, and restarted the process of creating an admin recipe. I applied the patch from persist is_syncing across container rebuilds and used explicit prompts to run composer patches-relock and composer patches-repatch. Voila, I achieved the results I was seeking, and I can't blame Claude, honestly; frustration is part of the process.

Thirty years ago, when I first started teaching myself programming on a Leading Edge computer that was almost immediately infected with a virus from a pirated version of Photoshop 3.x, which caused my mouse to act erratically, I nearly gave up learning to program because of the frustration. My dad, who has been an engineer his whole life, said to me, "Working with computers is an exercise in frustration." I can recall so many silly bugs that caused me huge frustration.

An AI can't prevent frustration, but it is a tool for solving problems and explaining solutions that can reduce friction when developing software. AI and LLMs can cause frustration due to AI hallucinations, which can be as simple as a off-by-one error that leads to significant frustration. It is almost comical that some AIs can't do simple math safely. The key to limiting frustration with AI is "context" and maybe for math problems, "guidance."

Claude couldn't assist with the composer patches issue because it's very likely that the documentation didn't exist when the LLM was trained. Fortunately, there are several ways to help an AI better understand the context of the request, and we provide guidance on how to do so. Claude offers multiple methods to add context and guidance to our interactions and requests. I need to explore adding a CLAUDE.md file, skills, plugins, and MCP servers to improve how Claude understands Drupal. This is a lot of exploration, so this post is the first of many as I build my Drupal Playground.

I thought I could describe in a single blog post how to set up a fully functional Drupal Playground with Claude completely managing the process. However, I was slowed down by the process of digging into and building the simple foundation of installing Drupal. Still, by using Claude, I was able to completely modernize my approach to installing Drupal, making it 100% recipe-based. This is not something I expected to achieve.

I feel like Claude-ifying my development environment and workflow follows a crawl-walk-run process, and I’m okay with that. Everyone is allowed to crawl, walk, and run in the playground, as long as no one gets hurt. I guess my next blog post should start by defining the playground rules and guidelines, also known as AGENTS.md.

The best way to see what I am exploring is to check out my Drupal (AI) Playground on https://github.com/jrockowitz/drupal_playground.