I lost sleep last night, dreaming about Claude Code. The night before, I was working too late and too hard on a coding problem, and I ended up dreaming about it and circling the solution. I was ruminating on how Claude Code fits into my development workflow. In my dream, I kept circling back to the question of how to code Drupal using AI.

I want to emphasize that I had a dream, not a nightmare. The dream was triggered by spending an entire day clauding at Symfony, more generally using Claude Code to improve my understanding of Symfony and how it is used in Drupal.

First and foremost, I see AI as a powerful tool, not a replacement for developers. AI is a disruptor affecting both junior and senior developers, requiring them to learn to use AI to develop and maintain software applications. An AI tidal wave is underway, and we need to get ahead of it rather than ignore it.

My long-term goal is to bring AI into my Drupal development workflow, yet I like circling around big challenges and seeking a learning task that is somewhat Drupal-adjacent. There are two Symfony-related issues/tasks on Drupal.org that I want to understand and maybe help resolve.

The first one is really simple. The latest version of Drupal CMS and, in turn, the AI Agents module can't generate content types. i.e., "create an Event content type" because the AI agent throws a passing generic $value parameter triggers an error. This is a minor bug, but I honestly don't understand Drupal's integration with Symfony's validation component well enough to contribute a patch.

A much larger second discussion I have been following for several years is the addition of integration for Symfony Forms. I have a significant investment in Drupal's Form API because I built the Webform module for the current version of Drupal, and changes to Form API would affect the module.

Both of these tickets made me want to set up a local Symfony environment, which I am calling a playground, to install, learn, and experiment with Symfony components that are included or could potentially be included in Drupal.

It is very likely that all my coding experiments across different languages and frameworks will be called "playgrounds," simply because that is what I want to experience when learning new things with AI. Playing with things implies that they will break at some point, surprise you at other moments, and still be fun. Instead of being intimidated by AI, I want to play with and enjoy the experience. When planning my Symfony Playground, I did not intend to use Claude Code because I was scared of it, partly because it uses a CLI interface that can consume a lot of tokens (aka money).

I have experimented with VSCode and Copilot. I use PHPStorm with Junie daily. My usage of Junie has been so successful that I ran out of tokens for the month while underutilizing my Anthropic subscription, the makers of Claude. So I bit the bullet, opened Claude UI and Claude Code, and started making a plan.

Searching for tips and tricks for using Claude and any AI product feels like the most important first task before an AI agent starts writing code. Initially, I started planning a project in the Claude UI, generating several Markdown documents that documented my research and plan. My prompts were all about discovering the best ways to learn and explore Symfony, helping me create a list of Symfony components that Drupal uses. Claude also directed me to the Symfony Book.

I am a big fan of books because they tend to have more depth and review than blog posts and online documentation. At the same time, books become outdated, and AI books become outdated quickly. Still, there is no wiser author of a book about Symfony than the creator, Fabien Potencier.

The "Symfony: The Fast Track" book was helpful and frustrating at the same time because it covered many Symfony concepts in sequence, but when I couldn't get sending email working, it gummed up my ability to move forward with the example application.

Personally, when learning something new, I like to break it down into smaller, loosely coupled examples that I can easily refer back to as I build an application. For example, I prefer to have dedicated examples of forms and email sending, knowing I could mix them to create a contact form. My experience with the Symfony Book made me want to create a Symfony Playground with smaller playsets, rather than a monolithic obstacle course.

I found it challenging to record and document all the prompts I used to build out my Symfony Playground. Some prompts failed, and others had poor grammar; therefore, there is little to be gained from showing you my prompts. I did learn the value of documentation when it comes to AIs and humans building software.

The most valuable document for AI agents is AGENTS.md, and specifically for Claude Code, CLAUDE.md, which provides initial context to the AI before it begins thinking. The reality is that AGENTS.md and CLAUDE.md should be identical. The CLAUDE.md in my Symfony Playground root reflects the majority of my experience with Claude Code: I started by prompting Claude to create a default CLAUDE.md file, then iteratively asked it to create and update this file (CLAUDE.md and AGENTS.md). These files became my record of intent.

For example, I generally dislike using abbreviations because I would rather my code be as clear as possible. Claude started using abbreviations, including 'desc' for 'description', and this immediately proved my point/concern because 'desc' is more commonly used to mean 'descending' order, specifically in SQL and sorting in general. This decision by Claude made me smirk because it is a reminder of the analogy that an AI is a junior developer with a PhD-level understanding. I prompted Claude to fix this and noted this rule in the CLAUDE.md file. Because CLAUDE.md consumes tokens, it is recommended to keep it short and maintain supplementary documentation in dedicated Markdown files.

AIs and humans can understand Markdown files, and they are easy to edit. A bonus of Markdown is that it is the cheapest document format to share with an AI because it contains the fewest characters, which in turn consumes the fewest tokens. I'm concluding that all my development documentation and planning will be in Markdown, or at least I will use Google Docs, which now supports cutting and pasting Markdown into and out of the editor. Anyone using Google Docs should enable the new Markdown feature.

My dedicated Markdown files live in a /docs folder, and each Symfony concept I am exploring has a dedicated SYMFONY-{CONCEPT}.md file, AI-generated and serving as my cheat sheet. I continually prompt Claude to update it as I explore new concepts. For example, I have subscribed to events in Drupal but have never written an event handler, and I have had difficulty in the past visualizing the event handler-to-subscriber flow. In my SYMFONY-EVENTS.md documentation, I prompted Claude to use Mermaid.js instead of plain text to create a clear diagram.

It's a give-and-take when asking AI to generate documentation, especially learning resources. AI's hallucinations include non-existent URLs, methods, commands, and resources. I found the simple answer is that when something an AI tells you feels wrong, look it up, or have the AI or another AI double-check the work and documentation.

I have dyslexia and am a slow typist, so I can't produce documentation quickly. Still, for the record, this blog "ain't" written by AI; it's reviewed and augmented with Grammarly and Gemini.

It is a little ironic that in this post, I am talking more about the generated documentation than about the generated code.

My perspective on Claude's code is that it needs review and can't be blindly trusted. When I see Claude using an established code pattern like a controller, I will glance over that part and focus on the specific code I need to understand. I found the rule that the code generated is only as good as the instruction absolutely true. I also kept having to remind myself that AIs will get better and better at generating code, and I wasn't initially using any custom "skills" (e.g., specific, pre-trained routines for common tasks) and specialized "MCP servers" (e.g., custom back-ends that integrate APIs and Tool) with Claude Code. To reduce token usage and improve my work, I prompted Claude to create an /add-concept custom skill and connect it to the context7 MCP server. Implementing more custom skills and connecting to a specialized MCP server feels inevitable. Adding Claude Code to my workflow feels inevitable.

I don't like concluding with this statement, but it feels true. When I read between the lines of the AI hype and started experimenting with it, I realized that AI has changed things and will continue to change them at an accelerated pace.

I hate to admit that I keep reflecting on and sharing Matt Shumer's blog post "Something Big Is Happening," which could be the most-viewed AI-related article on the internet. Some are very reasonably calling the article AI hype; meanwhile, when I was clauding at Symfony, I felt an AI experience. My experience with Claude Code boils down to seeing it as a tool that will increase my productivity and accelerate my learning in software development.

With my Symfony Playground, I am sure there is plenty of room for improvement. Someone with more Symfony development experience might find glaring mistakes. For example, the Twig template could be vulnerable to XSS and could use some hardening, yet this playground is not a production application.

Still, I always welcome feedback on my code, and who knows, in the near future, a senior developer might say, "Here is an example of your vulnerability, and I recommend using this prompt, skill, or MCP server to fix it."

What also feels very far off is an AI coding agent completely pushing a knowledgeable human out of the loop to build collaborative, scalable, and robust software like Drupal. Lastly, it seems inevitable that I will unleash Claude Code on my Drupal projects and modules and discuss what happens.

Generally, I like to include my references as I work on a blog post. Fortunately, my approach to working with Claude Code was to have Claude continuously update my /docs, which are listed in my https://github.com/jrockowitz/symfony_playground README.md file.