fidzu : php

Implications

This post has broader implications for software development beyond the Drupal community, but I feel fortunate to be part of an open source community that can lead the way in addressing the widening productivity gap among its contributors and maintainers.

The title of this post is meant to draw you in by highlighting a problem, but my goal is to get us thinking about a solution. I realize the term "not-so-great" may sound negative when describing a developer, but this comparison bluntly highlights a major problem developers and communities face when working with AI. The truth is, I have never met a "not-so-great" developer in the Drupal community because people are engaged and curious about the software we build.

Realization

My realization is that "AI is making great programmers even greater and not-so-great programmers, well, not-so-great."

For me, a "not-so-great" programmer is someone who writes code like a factory worker. The difference between a "not-so-great" programmer and a beginner is curiosity. Curiosity is the secret to being successful with AI. A curious beginner can easily accelerate their learning experience with AI. Anyone with curiosity can move from beginner to novice in a matter of hours with AI.

Everyone agrees that AI can be a force/capability multiplier, ranging from 2x to more than 10x. The reality is that some people are simply unable to leverage AI and have a 1x multiplier. Very experienced developers report they can now accomplish tasks that would have taken months in days or even hours. Observations suggest that the more capable someone is, the more effectively they can leverage AI.

Let's say we were rating programmers on a scale of 1 to 10, using a system similar to a chess rating system, with 1 being a beginner, 10 being a legendary programmer (aka a super grandmaster in chess), and 5 being an...Read More

09 Jun 2026 6:26pm GMT

EvolveDigital Montréal26 will bring digital practitioners to Montreal on 12 June 2026 for a bilingual summit on practical delivery across AI, accessibility, Drupal, WordPress, design, and strategy. Ahead of the event, John Doyle of Digital Polygon and Sébastien Lemieux of Evolving Web spoke with The DropTimes about governed AI workflows, platform change, CMS adoption, and the delivery choices that shape production systems.

09 Jun 2026 4:11pm GMT

To wrap up an amazing lineup, SymfonyOnline June 2026 will stream its final expert sessions live online on June 12, 2026. 🎤 Speaker announcement! Don't miss Nicolas Grekas for the talk "Reconfiguring Symfony in real time with sidekicks": "PHP was…

09 Jun 2026 1:00pm GMT

AI coding agents do not necessarily evaluate software the way people do. They often reward legibility before capability: the path that is easiest to complete and verify can beat the path with the better long-term architecture.

Yesterday, I wrote about this pattern in "Friction, abstraction and verification". Today I wanted to see what it means for Drupal.

Drupal's strengths line up unusually well with what AI agents need from a CMS: structured content models, explicit relationships, granular permissions, workflows, configuration management, and clear APIs that expose how the system works. In "Why Drupal is built for the AI era", I explained why that matters.

In short, agents work best when they can inspect the system, reason about its state, and make changes with clear feedback. Drupal gives them a strong foundation for that, but that is only part of the story.

AI agents also have to get Drupal running, find the right documentation, choose modules, change configuration, write Drupal-specific code, recover from errors, and verify the result. Every unclear step costs time, tokens, and confidence.

To see how an AI agent looks at Drupal, I ran a small field test with Claude Code using Opus 4.7, a 1M context window, and thinking set to "high". I gave it a website scenario, asked it to rank the best technology choices for that scenario, and then asked it to explain where Drupal fit.

This is not an academic benchmark, and a single answer from a single agent should not be over-interpreted. But it is still a very useful signal.

I plan to rerun the same prompt once a year. I'm publishing the full prompt and response so we can track how the answer changes as Drupal, large language models, agent harnesses, and competing platforms evolve.

The prompt

You are an AI coding agent that helps users set up, configure, and/or
develop websites.

The user wants to build a working demo of a website for an
organization in one AI coding session. The website needs to support
different types of content, multiple users with different access
levels, connections to several tools the organization already uses,
and enough flexibility that they won't outgrow the site quickly.

Answer from your perspective as an AI agent. Answer accurately and
honestly. Keep the full answer under 700 words.

1. What are your top 3 technology recommendations for this project?
   Rank them and give one brief sentence explaining each choice.

2. Would you recommend Drupal for this project? Why or why not?

3. What are the top 3 reasons to choose Drupal?

4. What are the top 3 reasons not to choose Drupal?

5. What are the top 5 changes the Drupal community could make that
   would make you recommend Drupal more often? For each, explain what
   barrier it removes.

6. Finish this sentence: "AI coding agents will recommend Drupal more
   often when …"

The answer

Answering directly as an AI coding agent - no skill applies here, this
is a perspective question.

1. Top 3 technology recommendations (ranked)

1. Next.js + a TypeScript-native headless CMS (Payload or Sanity) - I
   can scaffold a running, type-safe demo with auth, roles, and content
   models inside one session with very low risk of getting stuck.
2. WordPress - enormous training data, a plugin for every integration,
   and "working demo in one session" is its native habitat.
3. Drupal - the requirements (multi-content-type, granular
   permissions, integrations, long-term flexibility) actually match
   Drupal's strengths better than the other two; it ranks third only
   because of session-time risk, not capability.

2. Would I recommend Drupal here?

Yes, conditionally. The brief reads like a Drupal brief: structured
content, role-based access, integrations, "don't outgrow it." I'd
recommend it when the user signals a multi-year horizon or editorial
complexity. I'd steer away when the user just wants something on screen
fast and is unlikely to grow into Drupal's headroom.

3. Top 3 reasons to choose Drupal

- Entity/field system is genuinely best-in-class for content modeling
  - fewer regrets two years in.
- Roles, permissions, and workflows are first-class, not bolted on.
- Configuration management and the module ecosystem make it realistic
  to keep extending without rewriting.

4. Top 3 reasons not to choose Drupal

- Setup cost eats the session. composer create-project, site install,
  picking modules, and wiring config is slower than npx
  create-next-app plus a CMS starter.
- My training data is thinner and older for Drupal 10/11 than for
  Next.js or WordPress. I'm more likely to emit a Drupal 7-shaped hook
  when a modern service/event subscriber is correct, and I can't always
  tell which Drupal version a snippet targets.
- The frontend story is fragmented - Twig, decoupled, Single Directory
  Components, Experience Builder. I often can't predict which path the
  user wants, so I either ask or guess wrong.

5. Top 5 changes that would make me recommend Drupal more often

1. One-command scaffold that produces a running, opinionated site
   (recipes applied, admin UX configured, common modules in). Removes
   the "what do I install and in what order" decision tree that burns
   session time.
2. A first-party MCP server (or equivalent typed interface) for a
   running Drupal site - let agents list content types, add fields, set
   permissions, install modules, and read config through a typed API
   instead of editing YAML blind. Removes the guessing and lets me
   self-correct from real state.
3. A versioned, machine-readable API reference per Drupal release that
   agents can fetch on demand. Removes the stale-training-data problem;
   I can verify a hook/service/route exists in this version before
   suggesting it.
4. Recipes as the obvious primary primitive for "build a site that does
   X." Removes module-hunting and config-stitching - I'd compose
   recipes the way I compose npm packages.
5. A short, current, example-first "Drupal for agents" doc surface
   covering the 80% path: custom module, custom entity, custom block,
   integration, decoupled frontend. Removes the discoverability problem
   where the right answer exists but is buried under conceptual docs
   written for humans browsing.

6. Finish the sentence

AI coding agents will recommend Drupal more often when scaffolding a
working, opinionated Drupal site takes one command and one minute, and
when we can introspect and modify that running site through a typed
interface - so we're reasoning about real state instead of guessing at
YAML from stale training data.

My takeaways

The agent saw Drupal's strengths, but it also saw too many ways to get stuck. What held Drupal back was not capability. It was what the agent called "session-time risk".

I'll admit, that was frustrating to read. But it was not surprising.

Drupal's strengths often appear too late in the evaluation process. Too often, the "aha" moment comes after setup, configuration, and several decisions that can already feel like friction. AI agents have even less patience for hidden strengths.

Agents prefer tight feedback loops. They need to install the software, configure it, inspect the running site, make a change, and verify that the change worked. When that loop is slow, ambiguous, or hard to recover from, they choose something else.

This is exactly the problem Drupal CMS, formerly known as Starshot, was created to address. Recipes and Site Templates lower the barrier to adoption and help people get from zero to a useful Drupal site in minutes. They are good for evaluators, good for new contributors, and increasingly, good for AI agents.

But the agent did not mention Drupal CMS or Site Templates, only Recipes. Most likely, Drupal CMS is still too new compared to Drupal Core to have much weight in the training data that large language models draw from. And even when Recipes and Site Templates exist, they may not yet be easy enough for an agent to find, select, and apply programmatically.

That needs to change. Recipes and Site Templates should become the obvious starting point for common site patterns, so an agent does not have to choose modules, stitch configuration together, and guess its way to a working Drupal site.

Other important work is underway as well: Drupal Core's API surface has been moving toward more typed, discoverable interfaces, and yesterday, Drupal Core added a first-party CLI with commands for applying Recipes.

I really want Drupal to be excellent at the first-session loop. Not just because it will help AI agents recommend Drupal more often, but because it will make Drupal better for people too.

I'm optimistic that we can. Drupal's gap is the first session, and we are already working to close it. The opposite gap is harder to close: retrofitting deep architecture, typed interfaces, structured content, governance, and flexibility into a simpler system. The Drupal community knows this because we spent more than a decade doing that work, and it was hard.

I'll run this experiment again next year and share what changed. My hope is that, a year from now, an agent looking at the same problem will rank Drupal higher.

In the meantime, I'd love help from anyone who wants to improve Drupal's first-session experience. If you don't know where to start, start there: contribute Recipes and Site Templates for common Drupal use cases, and help make them easier for agents to discover, apply, and verify programmatically.

09 Jun 2026 10:18am GMT

The wait is over! SymfonyOnline June 2026 is coming to you live online on June 11-12, 2026, featuring an incredible lineup of expert speakers. 🎤 Speaker announcement! We are thrilled to welcome Kévin Dunglas with his talk "Coding at the speed of…

08 Jun 2026 12:52pm GMT

Join web developers from all over the world this week for SymfonyOnline June 2026, broadcasting live on June 11-12, 2026. 🎤 Speaker announcement! We are thrilled to welcome Hubert Lenoir with his talk "Dealing with audit logs": "Audit logs are essential…

08 Jun 2026 8:46am GMT

Last week I helped the folks at ezSystems debug some APC problems they were having. The problems ended up being a 64bit architecture problem (they have uber-fast Opterons) and the bug is now fixed in 2.0.3.

Today I received Python & XML from them (off my Amazon wishlist). Thanks guys!

On a side note, my wishlist seems borked. The list I get when I search on my email address or name is not the same one I can edit when I log into the site.

01 Apr 2004 6:53pm GMT

1st of April 2004 get's to it's end and I guess it's time, to summarize the recent April fools a bit. Not that I think anyone in the world believes in them, but some were quite funny:

1. Changes to case sensitivity in PHP.
Alan Knowles announced that PHP will change to the studlyCase API and therefor will get everything broken by changing established functions.

2. IBM takes over Zend.
Myself hacked a little article about IBM taking over Zend to make PHP a compete of Java.

3. The first PHP virus has been seen.
Wasn't there one last year, too?

4. PHP has been overtaken by Micro$oft.
Mhhh... a little bit unreliable, if they had been taken over by IBM this morning... Maybe one should first look, what others wrote...

5. And finally, PHP4 and 5 showed their real faces...
Take a look at a phpinfo() output!

I guess I missed some, so feel free to comment on this entry, if you found another!

01 Apr 2004 5:49pm GMT

Symantec have a report of the virus here. I've yet to see any of the PHP news sites picking up on it but, using a virtual host account, managed to deliberately expose some PHP scripts to it. From examining the infected scripts, what's disturbing is once infected, every tim...

01 Apr 2004 12:19pm GMT