cms

28 Apr 2026

Drupal.org aggregator

Dries Buytaert: AI rewards strict APIs

Every framework's API surface sits on a spectrum, from strict (typed interfaces, schemas, service containers) to loose (string keys, naming conventions, untyped hooks). Strict APIs cost more upfront: more boilerplate, more to learn before writing code. Loose APIs shift that cost later: more ambiguity, more reliance on naming conventions, and more bugs that are harder to detect and fix.

AI changes who pays. Boilerplate and learning curves don't slow agents down. What slows them down is missing feedback: code that runs but does the wrong thing, errors that don't point to the cause, conventions that have to be guessed. Magic-name binding, untyped hooks, unvalidated configuration, and conventions the code doesn't enforce produce exactly those failure modes.

Magic strings break the loop

For example, both Drupal and WordPress have long used magic-string hooks. In Drupal, you write a function like mymodule_user_login. WordPress uses a related pattern: a string action name passed to add_action(). In both cases, the binding is a string the language can't validate.

Get the name wrong and the system silently skips your code: no error, no warning, nothing in the logs. The function just sits there, unloved.

The signature is a convention, not a contract: the documentation says the user_login hook receives a $user object, but nothing enforces it. To your IDE or a static analyzer like PHPStan, it's just a function. They don't know it's wired into the platform's login flow, so they can't warn you when it's wrong.

A typed alternative makes the binding explicit. With a PHP attribute like #[Hook('user_login')] on a registered service, the class must exist, the method signature is type-checked, and the container wires the dependencies. IDEs, static analyzers, and AI coding agents can follow the chain from the attribute to the implementation.

For AI agents, this keeps the feedback loop tight instead of turning it into trial and error. That means they can move faster, spend less time debugging, and use fewer tokens.

At DrupalCon Chicago this March, AI coding tools migrated a Lovable-generated site into Drupal in hours. The strict APIs kept the agent on track.

A bet made before AI existed

This didn't start with AI. Drupal 8, which we shipped in 2015, introduced Symfony's routing, services, and event dispatcher, replacing large parts of the procedural hook system. Since then, we've kept reducing magic hooks. The attribute-based approach (#[Hook('user_login')]) landed in Drupal 11.1 and helps remove more of the remaining procedural-only paths.

Hooks aren't the only place Drupal has been getting stricter. Drupal stores a lot of configuration in YAML, which was one of the loosest parts of the system. A multi-year validation effort has been tightening that.

When an agent generates a content type definition or editor configuration, validation catches missing keys, invalid values, and broken references before anything is saved. The agent gets a precise error pointing to the exact field, instead of a runtime failure. That tight feedback loop is what makes Drupal a strong CMS for AI-assisted development.

Drupal made this bet early, and it was painful. The Drupal 7 to Drupal 8 transition broke backward compatibility and took years to recover from. But it left the platform much stricter. More than ten years in, we're still making Drupal stricter.

Meanwhile, WordPress made a different bet, prioritizing backward compatibility over stricter APIs. That kept the platform stable for a long time. It also kept the looseness.

Those trade-offs now determine how efficiently AI agents can work with each platform.

What was style is now speed

What used to be a stylistic choice is now a speed and cost problem. Loose APIs mean more debugging and guesswork. Strict APIs mean faster, more precise feedback. This was always true for humans. It's now also true for AI agents. But today that cost shows up in tokens.

28 Apr 2026 1:00pm GMT

Drupal AI Initiative: Webinar: How Southwark Council is Using AI to Transform PDF Publishing in Drupal

Southwark Council Webinar

Join us to hear directly from the team behind an award-winning AI solution built for local government. What does genuinely useful AI in public services look like? Not a concept, not a pilot, but a working solution that saves hours of manual work, improves accessibility, and puts better content in front of citizens faster.

Southwark Council's AI-powered PDF importer for Drupal is exactly that, and it won the prestigious Digital Leaders AI Impact Award 2026.

We are delighted to invite you to a webinar where you can hear the story first-hand.

About the webinar

Date: Tuesday 16th June | 16:00 BST
Guest: Angie Forson, Web and Digital Programme Lead, Southwark Council
Host: James Hall, Product Lead, Websites at Everyone TV

This is a rare opportunity to hear directly from a senior stakeholder about how Drupal and AI are delivering real, measurable value in an area that truly matters: public services for the citizens of Southwark.

Angie will walk through the journey, the challenges, the outcomes, and what it means for the wider local government sector.

The problem it solves

Manual PDF conversion has long been one of the most time-consuming tasks facing council web teams. Converting a single document can take hours. Multiply that across thousands of PDFs and the burden becomes significant, both in staff time and in the delay it creates before citizens can access accurate, accessible information.

The Southwark team, working with their partners at Chicken, built an AI-powered importer for the LocalGov Drupal Publication Module that reduces that process to minutes, often under one minute.

How it works

Each PDF passes through a three-step pipeline:

Extract - a PDF parser pulls the raw content from the document
Transform - AI converts it to properly structured, accessible HTML with logical pagination
Save - clean HTML pages are ready to review and publish directly in Drupal

The result is an HTML representation of the PDF content, saved into a Drupal Publication and ready for review before going live. Every import is logged, so errors can be identified and resolved efficiently.

The module uses a plugin architecture, meaning each step in the pipeline can be swapped out. Councils can use different extractors, AI models, or output to different Drupal content types, making the solution adaptable to a wide range of content and operational requirements.

Built the right way

The team delivered this project with an agile, user-centred approach, continuously refining requirements to ensure the tool meets real user needs rather than simply ticking a technical specification.

"This project is a great example of AI working alongside and empowering content creators, and Drupal as a platform supports this really well." - Farez Rahman, Drupal Developer

"I'm excited about the impact this product will have, not just for our users, but also in transforming how we design, build, and create content internally. We're shaping a future where services start with HTML-first thinking." - Evelyn Francourt, User Experience Lead

Why this matters beyond Southwark

Local government teams across the country face the same challenge. This solution, built on open source Drupal and the LocalGov Drupal ecosystem, is designed to be shared, not kept in one place.

If your organisation publishes PDFs, manages large volumes of content, or is exploring where AI can deliver practical value without unnecessary complexity, this webinar is for you. Tuesday 16th June | 16:00 BST | Online.