fidzu : cms

Today we are talking about Drush, Core Contributions, and Drupal's Past with guest Moshe Weitzman. We'll also cover Cache Metrics as our module of the week.

For show notes visit: https://www.talkingDrupal.com/556

Topics

• Moshe Updates and Clients
• Maintaining Drush Long Term
• Locale Performance Overhaul
• CLI in Core Initiative
• Which Commands Make the Cut
• Roadmap Contrib Commands
• Moving Commands Technical Hurdles
• How to Help From AI Initiative
• DDEV Add-ons for Local CI
• MySQL Toolkit Database Images
• Testing With Real Databases
• Devel Module Status
• Organic Groups Origins
• Where Ideas Come From
• Finding Drupal Early Days
• Release Cadence And Backward Compatibility
• Avoiding Maintainer Burnout
• Maintaining With AI And Xdebug

Resources

• Drush's Final Act
• Drupal cli issue
• DDEV addons
  • https://github.com/ddev/ddev-drupal-contrib
  • https://github.com/weitzman/ddev-mtk
  • https://www.drupal.org/project/dtt

Guests

Moshe Weitzman - weitzman.github.io moshe-weitzman

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Scott Falconer - managing-ai.com scott-falconer

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted insights into how cache is working on your Drupal site? There's a module for that.
• Module name/project name:
  • Cache Metrics
• Brief history
  • How old: created in Oct 2019 by Moshe Weitzman (moshe weitzman), today's guest, a consistent core contributor, a member of the security team, and one of the rare few with a two-digit user id on drupal.org
  • Versions available: 2.0.3, 2.1.0, and 2.2.0, the last of which works with Drupal 8.7.7, 9, 10, and 11
• Maintainership
  • Actively maintained
  • Security and test coverage
  • Documentation - in depth README
  • Number of open issues: 2 open issues, 1 of which is a bug, but is marked fixed
• Usage stats:
  • 37 sites
• Module features and usage
  • With this module enabled, your Drupal site will log all cache tag invalidations
  • Additionally, cache tag invalidations will be sent to New Relic as custom events, where you can use the rich reporting tools available to mine for further insights. Many Drupal hosting options include New Relic out-of-the-box, and there's a free tier you can use if you're self-hosting, so this a reporting tool lots of Drupal sites can use
  • Cache hits and misses are also sent to New Relic, so you can investigate things like cache misses as a percentage by cache bin
  • Finally, the aforementioned README also includes information about how to use a different analytics provider, in case New Relic doesn't meet your specific needs
  • Drupal sites probably don't need this kind of visibility on a regular basis, but if you're troubleshooting any kind of cache-related issue, this could be really useful

08 Jun 2026 6:00pm GMT

LocalGov Drupal Camp 2026 will bring together public-sector practitioners, developers and digital service teams at Sheffield Hallam University on 11-12 June 2026. Speaker previews released ahead of the event show a programme centred on practical implementation experiences, artificial intelligence governance and product-led approaches to digital services, with knowledge sharing and peer learning emerging as common themes across multiple sessions.

08 Jun 2026 2:28pm GMT

AI coding agents like Claude Code and OpenAI Codex tend to choose the path that is cheapest to complete. They work within a budget of tokens, context, time, tools, and permissions. Every step spends from that budget: reading documentation, installing software, running it, configuring it, changing it, and fixing errors.

For Open Source, this is a rare opportunity. AI agents could become its biggest adoption engine yet. While that should energize Open Source communities, it should also make proprietary vendors deeply uncomfortable.

Many proprietary software vendors have spent years optimizing for a human buyer journey: capture a lead, qualify the buyer, force a signup, offer a demo or trial experience, ask for a credit card, schedule a sales call.

Humans may grumble but keep going. To an AI coding agent, these are blockers, not buying steps.

Open Source starts from a different place. AI agents can read the source code, run it locally, and change it without asking anyone for permission. That does not guarantee adoption, but it removes the proprietary gates that slow agents down.

But being Open Source is not enough. Open Source removes the "permission barriers", but it can still have "execution barriers". If an Open Source project is hard to install, configure, extend, debug, or verify, an agent may choose an easier Open Source project instead.

In that sense, AI agents amplify an old truth about software adoption: the best software does not always win. The software with the easiest path to a working result often does.

But AI agents amplify that truth through "silent rejection". A human evaluator might complain, ask for help, file an issue, or write an angry Reddit post. An AI agent just tries another path. You may never know your software was considered and rejected.

Easy is more than low friction

If you want your project to be adopted, you have to make the best path the easiest one to complete.

And "easy" means more than low friction. For an AI agent, there are at least three costs: friction, abstraction, and verification.

Friction is the cost of getting to a system the agent can run and change. Some friction comes from the environment: runtimes, containers, databases, package managers, local services, and setup choices that must be installed or configured before useful work can begin. Some comes from access and authorization: private repositories, account creation, credentials, and API keys.

Abstraction is the cost of figuring out what to do next. Once the software is running, the agent still has to know which modules to use, how to structure the data, which settings to apply, which conventions to follow, and how the pieces should fit together. A good site template, recipe, or scaffold packages that expertise so the agent can take several correct steps at once instead of reconstructing the path from scratch.

Verification is the cost of knowing whether the work succeeded. Tests, clear errors, inspectable state, and fast debugging cycles help the agent compare what happened with what should have happened. As I wrote in AI rewards strict APIs, agents do not struggle with complexity; they struggle with ambiguity.

Each cost burns tokens, meaning the AI agent has to spend more of its limited context and reasoning budget reading documentation, comparing different options, or recovering from failed attempts.

What helps agents helps people

This is not just an AI problem. People have always preferred software that is easy to get running, gives them a clear path forward, and tells them when something worked. AI agents make the same preference more obvious because they have even less room for trial and error.

Developer Experience (DX) makes software easier for developers to evaluate, build with, and maintain. Agent Experience (AX) makes software easier for agents to install, modify, and verify.

In practice, the overlap is large. Better scaffolding, clearer errors, faster setup, opinionated best practices, and reliable tests help agents, but they also help developers, evaluators, and contributors.

Open Source still has to compete

The cheap-to-run advantage will not belong to Open Source forever. Proprietary vendors and SaaS companies are adding free tiers, programmatic access, and Model Context Protocol servers that give agents tools and context with less friction.

Open Source's structural advantage is about to expand, but it will concentrate in the projects that are easiest for agents to understand, run, and improve.

Every software project will have to earn its place in the agent flow. Being open will get you considered, but being easy to discover, install, inspect, modify, and verify will get you chosen.

08 Jun 2026 7:13am GMT