To say that there is not an agreement of using large language models (LLMs) for Drupal development would be an understatement. I've been using Claude Code for a while to assits with my Drupal development and I shared a month ago how I brought back the Drupal 7 module upgrader tool from the dead. That was a bit of an involved example, so I wanted to find a simpler one and this time rely even more on Claude.
A not so small issue: none of the language names are translatable
One of the fundamental tool modules I maintain is Translation Template Extractor (potx), which is used on localize.drupal.org to extract translatable strings from all drupal.org projects. This is critical infrastructure for Drupal's multilingual functionality. It must work well, but there are still occasional bugs.
@stefan.korn submitted a bug in January that "German" does not show up anymore as a translatable string for recent Drupal versions. @joachim namyslo posted analysis that indicated this affects all language names. He was getting close, as he pointed out the language manager class has the language list and there are no t() wrappers. However there were never such wrappers because we need the original source language names too and translate them dynamically later. But potx still can extract this with a custom solution. That is where the problem lied. Yesterday I posted the code of the parsing method for someone to figure out but then I realized this will be a great simple case study for fixing with a bare Claude setup.
Letting Claude find the cause and create a plan
While the current policy allows it, there is also not consensus that drupal.org (or core specifically) should allow LLM generated comments on issues or not. I'm personally in agreement with the current policy. As long as the person posting is accoutable for the text, I would not judge what they used to create it. While a month ago I used the top of class Claude Opus 4.6 LLM model, I decided to use the simpler and cheaper Sonnet 4.5 model this time, which is much more likely going to be used by a contributor.
I also did not have any agent guidance (AGENTS.md, CLAUDE.md or similar) whatsoever so this should demonstrate what would someone with Drupal knowledge but green-field LLM use encounter. I had a hunch the problem is with PHP array syntax parsing, but I asked an open ended question of the LLM to prove my point. I did not even tell it that it was about language names.
why would _potx_find_language_names not be able to parse LanguageManager.php in Drupal 11?
I posted Claude's answer on the issue verbatim to demonstrate my point. I think the answer was spot on (see hero image on the post).
Once again, I did not have a special tweaked setup, this is Claude Code with Sonnet 4.5 out of the box running on a codebase with Drupal 11 and potx installed.
First commit looked mostly good
I asked it to fix the issue as it proposed and add additional test coverage. I made it commit the first result it had, so we have a baseline to talk about:
I think the commit message also turned out to be a good summary, not just the original analysis of the problem.
Little lies in test coverage that lead to more robust test coverage
However, I noticed in the diff that it did not fully do what it promised. It added a test for a mixed array syntax that did not actually have mixed array syntax! Well, I pointed that out in my next prompt and I got the all too familiar "of course, you are right". While fixing that up to have real mixed array syntax it also generated edge case tests for me. The edge case considerations were not overcomplicating the test so I accepted them. After all originally the code broke because it was not ready for the method's internals changing, so why not prep for some edge cases too. I made it commit this fix with its own commit message. Only test changes.
But the new tests were failing
Now the phpunit tests were failing on drupal.org CI! How did Claude not know this before committing? It did not run phpunit. I've seen this, so I asked it to run it locally and fix the issue. But as I've seen before, Sonnet 4.5 just can't figure out how to run phpunit with ddev in my setup. It tried 4-5 different ways before I made it stop. This is the one thing about Drupal that I needed to explicitly tell the LLM about. So finally it ran the test and it figured out that the edge case test it added was failing! But the test was good! It found itself the bug in the implementation and fixed it. Now it could run phpunit again so verified it before pushing the commit to the issue branch.
LLM progress comment to keep readers informed
Now I had a modern Drupal implementation of this that passed on Drupal 10, 11 and 12. I asked Claude to summarize the changes made and I think this was a good summary that I can stand behind:
Backport was needed, where I made a mistake
All good? No. Sadly localize.drupal.org is still running on Drupal 7, so I needed a backport to Drupal 7. I asked Claude to create a new branch and apply the fix to the 7.x-1.x branch. It did it and I asked it to push it to a new branch for demonstration purposes. Upon reviewing what it did, I noticed that I made a mistake. It was adding testing utilitiy methods that should have already been on the Drupal 7 branch! This is where I realized I should have asked to base it on the 7.x-3.x branch, which is the current one. So I made it redo what it did. Much better! (In retrospect I suspect it may have figured out this was the latest Drupal 7 branch by itself but I was too specific, my bad).
Backporting a minor code refactor to make the test more robust
One final thing (that I should have pushed separately but forgot) is that to backport the test to Drupal 7, it replicated part of the PHP tokenization features in the test because the Drupal 7 potx code did not have a standalone PHP parsing function. I asked it to replicate the abstraction of PHP parsing from the modern Drupal branch instead. This introduced the same internal function in the Drupal 7 version that was already on the modern Drupal version and simplified the testing backport a lot.
LLM issue summary with AI disclosure to wrap it up
Now I have a fix I reviewed. It adds plenty additional tests. Passing on Drupal 7, 10, 11 and 12! I posted the analysis and summaries from Claude as comments but the issue summary was very outdated. So to put a cherry on this cake I asked Claude to summarize the problem in Drupal's issue summary format. Remember I don't have any special setup here so I manually gave it the header labels I needed. This is what I got:
While it has the occasional HTML formatting error, I wanted to paste it as-is to demonstrate my point. I think this looks good. I included an AI disclosure element manually as per current policy.
Did not write a single line of code, issue commentary or commit message myself for this
This only took a couple hours. Most of my time was spent manually writing this blog post about it. I did not write a single line of the resulting new/changed code. I was not even in an IDE. I did not write the issue comments or issue summary other than the AI attribution and I did not write any of the commit messages. I reviewed them though and I stand by them.
I hope this demonstrates well why I would personally encourage more of these types of contribution. It moves us faster without sacrificing on quality. Yes Claude made mistakes and I made mistakes. Ultimately I was responsible for owning them and fixing them. Whether by realizing I gave the wrong instruction or identifying Claude did something wrong. When it did not figure it out by itself.
This was still a very basic scenario
This is not magic and also not inherently bad. It is a tool in a toolbox. I think it is a good one. However it is by far not an advanced LLM setup anymore. Angie Byron recently started the AI Best Practices for Drupal project to collect skills for contributors. Lacking core agent guidance this would be the most natural item to add.
On the other end of the spectrum there are tools like Dalia with end to end LLM planning and generation for Drupal (built by Mateu Aguiló Bosch (e0ipso) and sponsored by Lullabot). I could have added drupal.org issue queue skills or gitlab CLI to do things directly. I intentionally avoided those as I wanted to demonstrate what a baseline situation looks like.
What I needed most was to own the result and stand by it. This would not change regardless of the setup.