A few months ago I asked AI to refactor some templates to Tailwind on a Drupal project. It did it fast, it looked good and nothing broke. I already wrote about it in six real-world AI cases in Drupal, but there's one part I keep coming back to.
When I sat down to review the diff, it was full of inline CSS and JS. There were duplicated templates. And a handful of bad patterns from the old code that the AI had copied as they were, because if they were there, there must have been a reason.
If I'd trusted that it worked, I would have shipped it like that.
And that's what really worries me about coding with AI. Not that it writes bad code, because you spot that right away. What worries me is that it writes code that almost always works.
The first 80% is free now
Anyone who's been doing this for a few years knows the 80/20 rule of projects. You knock out 80% of the task in no time, and then the last 20% drags on forever. There's that one detail missing on the form, the migration you need to run again, the deployment you still have to sort out with the client... I've been working with Drupal for over fifteen years and it's always been like this.
What's changed is that now that 80% takes ten minutes. And it looks great: tidy code, comments, tests and everything green.
It looks so good that it feels like 100%. And since it cost you so little, you're itching to call it done and move on to the next ticket.
Look, I've fallen for it too. When AI gives me something that's clearly wrong, no big deal. I read it, see it makes no sense and throw it away. The dangerous one is the other kind. The code that looks right but hides a tiny bug, the one you approve without thinking twice and that blows up three months later in a case nobody had considered.
Where are we heading?
From what I'm seeing, the industry is going pretty much the opposite way it should. People brag about how many tickets the agent closed this week, how many lines it wrote, how many deployments went out. How many of those changes had to be redone afterwards gets a lot less airtime.
And then there are the experiments. Before, if you wanted to try out an idea, you kept it simple, because making it more complex meant days of work and it might not even be useful. If it didn't work, out it went. Now you ask AI for the experiment and in one afternoon it builds you services, wrappers, configuration and even its own admin page. Since it was cheap, nobody removes it. And the project keeps putting on weight with things nobody uses.
In Drupal, you pay for this. Every custom module is one more to review with each security update and one more to migrate when it's time to move to Drupal 12. Cheap to write, sure. Cheap to maintain? Not even close.
Drupal has an extra problem
There's something that's very specific to us. AI gives you the most likely solution, the one it's seen the most. And what has it seen about Drupal? Fifteen years of Drupal Answers threads, Drupal 8 tutorials from 2016, Drupal 7 snippets half-adapted to newer versions...
So the most likely solution isn't what a senior developer would do in Drupal 10 or 11. The most likely solution is a \Drupal::service() stuck inside a class that should be using dependency injection. Or a two-hundred-line hook_form_alter in the .module file, when Drupal 11 already lets you declare hooks as attributes. Or a |raw in Twig because that's how the HTML looks right.
And almost all of that works, which is the worst part. A test knows nothing about cache bubbling. PHPStan warns you about deprecated APIs, but it won't tell you that the function the AI just wrote already exists three modules over.
Green tests don't tell me as much anymore
There's another trap. If the agent writes the code and also the tests, the tests check what the agent understood you wanted. If it got it wrong, you end up with incorrect code and tests saying it's perfect.
Don't get me wrong, tests are still necessary. But for me they're no longer enough to say something is done. You also need to look at complexity, duplicated code, security and Drupal best practices. And you need something deterministic measuring all that, not another AI giving its opinion on whether the code looks nice.
Generic analysis tools help, but they don't know anything about Drupal. They'll tell you a function is too complex. They won't tell you that your template breaks caching or that you have an admin view open to anonymous users.
This is where Audit comes in
A good chunk of these problems are the ones I'm trying to tackle with Drupal Site Audit, a module I maintain and have contributed to the community. It analyzes your Drupal site and gives you a 0 to 100 score for security, performance, caching, configuration and code quality, with concrete recommendations on what to fix.
On the code side, it looks at exactly what I was talking about. Functions that have become too complex, duplicated code (in Twig, JS and CSS too), bad Drupal practices in templates, security issues in custom code... All the stuff a test doesn't see.
And you can run it with Drush commands that return the results as JSON. It sounds like a technical detail, but it's what changes everything.
My skills and agents are trained to use those commands. When the agent finishes a task, it runs the audits on whatever it touched, reads the errors, fixes them and runs them again. A closed loop. The agent itself notices what it did wrong and fixes it before I even get to see it.
So when it's my turn to review, I'm no longer finding inline CSS or duplicated templates. I can focus on what actually matters.
I'm still the one giving the final sign-off
An agent passing every audit doesn't mean the work is good. It means it doesn't have the errors the module knows how to detect. Which is a lot, but it's not everything.
An AI can lower a function's complexity by splitting it into five methods that make no sense at all. The numbers improve and the code is just as bad. Or it can build you an architecture that passes every check and that nobody will be able to touch six months from now.
That's why, once the agent is done, I step in. I look at what it did, how it did it and whether the architecture underneath makes sense for the project. And also whether that feature was needed in the first place, which no analysis will tell you.
The last 20% is still mine. At least for now, because maybe a year from now models will write clean Drupal out of the box and all of this will be overkill. I hope so.
But that's not where we are today. And what I don't want is to run into duplicated templates in a diff again... and miss them.