Drupal's project founder Dries Buytaert published a post last week that deserves more attention than it's gotten in the typical agency conversation. It's not a release announcement or a roadmap update — it's a design philosophy argument, and one that lines up almost exactly with decisions we've been making (and debating) on client projects for the past year.
What the post argues
Dries frames every framework's API surface as sitting on a spectrum between strict and loose. Strict APIs use typed interfaces, explicit schemas, and service containers. Loose APIs rely on string keys, naming conventions, and untyped hooks. Neither is purely good or bad — loose systems are faster to get into and require less upfront ceremony, while strict systems demand more boilerplate and a steeper learning curve.
The argument is that AI changes this trade-off fundamentally. When an AI coding assistant — GitHub Copilot, Cursor, a custom agent, whatever you're using — tries to generate code against a loose API, it's working with ambiguity baked in. String keys can be misspelled silently. Untyped hooks provide no feedback loop. The AI can produce code that looks plausible, passes a quick visual scan, and fails at runtime in ways that are genuinely hard to trace.
Strict APIs flip the equation. A typed interface tells the AI exactly what arguments are expected and what types they must be. A service container with explicit bindings catches incorrect dependencies before they ever run. Schema validation rejects malformed input at the boundary, not three layers deep. The result: the AI's suggestions are either clearly right (they satisfy the type contract) or clearly wrong (they don't compile or fail validation immediately). The feedback loop tightens from "debug it at runtime" to "catch it in the editor."
Dries specifically points to Drupal's typed plugin system, its service container, and the ongoing work around structured configuration schemas as examples of where Drupal's architecture already pays dividends in an AI-assisted workflow. The post acknowledges that this strictness has historically been a barrier for new Drupal developers — more to learn, more boilerplate — but argues that AI tools lower the cost of working within strict systems precisely because they're good at generating boilerplate when the contracts are well-defined.
Our take
We've been living this trade-off on real projects, and the post resonates. Here's what we've observed:
AI-generated Drupal code is getting better faster than AI-generated WordPress code — and API strictness is a big reason why. When we ask an AI assistant to scaffold a Drupal service, it can lean on the service container definition, the typed interface, and the module's services.yml to produce something structurally correct on the first or second attempt. When we do the equivalent in a WordPress plugin — writing against action and filter hooks — the AI produces code that looks right but frequently has subtle issues: wrong priority, incorrect argument count on the callback, hook names that are close but not exact. The loose convention-based system doesn't give the tool anything to grip.
This has concrete implications for how we scope AI-assisted work. On Drupal projects, we've started treating AI generation as a legitimate first draft for plugin scaffolding, typed services, and entity API integrations. We still review and test everything, but the revision cycle is shorter than it was 18 months ago. On WordPress projects, AI-assisted code is useful for utility functions and template logic, but we're more cautious about anything that touches hook registration or plugin interdependencies — the surface for silent errors is larger.
The honest trade-off: strict systems still cost more upfront. Dries doesn't hide this, and neither will we. A well-typed Drupal module with proper service definitions and schema validation takes longer to scaffold from scratch than the equivalent WordPress plugin. For small sites or short-lived projects, that overhead genuinely matters. The calculus shifts on projects with longer lifespans, larger teams, or significant AI-assisted development velocity — the kind of projects where Drupal already tends to win the platform selection anyway.
Where this points for Drupal CMS and the AI initiative: The Drupal community has been investing heavily in its AI module suite, and the strict-API argument is effectively a design mandate for how those integrations should be built. If AI tools are going to generate Drupal code reliably, the AI module's own APIs need to be as typed and explicit as the rest of the framework. That's a standard worth holding to, and it's encouraging that the project founder is making the argument publicly.
One thing we'd push back on slightly: strict APIs don't automatically mean well-documented APIs. We've worked with typed systems where the contracts were explicit but the intent was opaque — correct by type but wrong in practice because no one explained the business rule the type was encoding. AI tools can satisfy a type contract while completely missing the semantic purpose of an interface. Documentation, naming clarity, and code-level comments still matter. Strict APIs raise the floor; they don't raise the ceiling on their own.
What to do with this
A few concrete takeaways for teams building on Drupal right now:
- Lean into typed services and plugin definitions when building custom modules intended for long-term maintenance. The upfront cost pays back faster than it used to, because AI-assisted developers can work within explicit contracts more effectively than loose conventions.
- Treat Drupal's configuration schema system as a first-class concern, not an optional extra. Properly defined config schemas give both human reviewers and AI tools a machine-readable contract for what valid configuration looks like.
- Audit your hook-heavy legacy modules — if you have older Drupal 7-era patterns that survived a migration but were never refactored into services, this is a good time to revisit them. Not because hooks are wrong, but because typed alternatives are often available and will age better.
- Apply the same thinking to APIs you build for others — if you're exposing a REST or JSON:API surface for a decoupled front end, typed schemas and explicit validation aren't just good practice; they're what makes the integration reliable when AI tools are on both ends of the wire.
Originally referenced: AI rewards strict APIs on Dries Buytaert.
If you're building Drupal projects where AI-assisted development is part of the workflow — or if you're trying to figure out where it should be part of the workflow — get in touch. We're happy to walk through how we're approaching it on current engagements.
Originally published by Dries Buytaert. Read the full announcement here.
