fidzu : Drupal

We've spent the last year building an AI-assisted development pipeline for daily use on client projects. Here's what that looks like in practice, and where humans stay firmly in control.

Whether you're a technical lead at another Drupal agency or a government team new to AI, here's what accountable adoption looks like in practice.

The pipeline: ticket to pull request

Planning

We ask Claude to review the ticket-Jira or the relevant Drupal.org issue queue-and ask clarifying questions before proposing a plan. We iterate until the developer and AI share the same understanding of what's required.

Implementation

We draw on approximately 30 reusable skills during implementation. Among them is a profiling skill for Drupal performance bottlenecks.

We also connect 2-3 MCP servers depending on the task-typically PHPStorm, Chrome DevTools, and Xdebug for runtime debugging instead of dump statements. A simple grep is often faster than routing a search through an IDE's MCP server, so we default to whichever tool is cheapest and still gets the job done.

Review and test coverage

Before anything nears a pull request, Claude reviews its own code and tests for scope creep and duplication. It also tests whether a slower browser test could be a faster kernel test.

Quality checks

We run PHPCS, PHPStan, and relevant PHPUnit tests. Claude Code's built-in security-review skill flags vulnerabilities before code goes anywhere near a pull request.

Final review and PR creation

One more pass for optimisations. A human creates and pushes the commits and creates the pull request.

Human review, always

Lastly, a team member gets assigned for manual review. Every pull request receives a human sign-off before merge, regardless of how it was produced.

Bootstrapping our own tooling

Beyond the skills above, we're building custom Symfony commands to bootstrap repetitive parts of our own code, currently living in github.com/previousnext/commands. We plan to move them into a Drupal contrib project, and are weighing whether a version belongs in core.

We're also watching the new dr command that landed in Drupal 11.4.0. It's an experimental native CLI in core, built on Symfony Console, that lets modules register their own commands directly. It's also a natural home for this kind of tooling as it matures.

Guardrails

For government readers, "how do you control this" usually matters more than "how much faster is it."

• Claude Code runs in an auto-mode configuration that restricts its access.
• We're trialling Docker sandboxes to isolate it further.
• Senior developers direct every stage.

Where we're going next

We're trialling AWS Kiro alongside Claude Code, comparing its spec-driven approach on the same kind of tickets. We're also evaluating other models, looking for anything that matches our output more efficiently than our current default.

On the guardrails side, we're extending the Docker sandbox trial into a locked-down local development environment for the whole team, not just the agent. And we're building out more front-end-driven tooling to match the depth we already have on the PHP side.

One result is already paying off after using AI to reverse-engineer our Mixtape design system from Storybook into Figma. New designs now start from accurate Figma components and export directly to Mixtape code. This has closed a loop that previously required manual translation between design and code.

We're also aligning with the Drupal AI Initiative's Outside AI workstream. This focuses on how external agents connect to, inspect, and safely act on a Drupal site.

Drupal's structured content, permissions, and governance model are what make agent-driven changes safe in the first place. Our pipeline is a working example of that.

What this means in practice

We've shared our approach to demonstrate that AI can be integrated responsibly and to encourage others to adopt best-practice approaches.

For other Drupal agencies, the biggest gains aren't "AI writes code faster". The efficiencies lie in the steps teams skip when moving fast, like clarifying tickets before planning and keeping test coverage lean.

For government teams, this doesn't require removing human accountability. In fact, we view human oversight as non-negotiable.

AI changes what a senior developer spends time on, such as planning, architecture design, refinement and review. It doesn't change who's responsible for the outcome.

What it means for clients

For our clients, nothing changes regarding who's accountable for what ships. Every change still goes through the same human review it always did. A senior developer signs off on every pull request, regardless of how it was produced.

What does change is where the time goes. Less of it sits in boilerplate, repetitive setup, and chasing down under-specified tickets. Instead, more of it goes into the actual problem you're asking us to solve.

Turnaround on well-scoped work is faster, without lowering the bar on what gets reviewed before it ships.

Let's compare notes

We don't have a rigorous study to back this up, but our estimate is a 20-30% efficiency gain across the board.

The gains vary by task type: boilerplate work like scaffolding new content types is up to 80% faster. Debugging, both backend and frontend, has improved dramatically.

While we've always been thorough in our reviews, we've still seen review time increase. This is because we're being extra cautious (rather than having previously waved through reviews).

AI in Drupal development moves fast. What we're using today will likely look different in six months.

New techniques will emerge, model costs will shift, and the community will settle on what actually works. We expect to keep adapting, and we'll keep sharing what we learn as we go.

We're genuinely curious about how other Drupal agencies are using AI in development and the efficiency gains you're seeing. Let's talk.

When AI design tools started reading codebases to learn a design system, we wanted to know what Mixtape looked like through that lens.

It turned out "well documented for humans" and "legible to an agent" are two different things. Closing the gap surfaced bugs that had been shipping silently for months.

Three years ago we modernised Mixtape's CSS for the browser: cascade layers, container queries, modern selectors. Since then, we've also converted to Web Components, full Typescript and integrated some more modern CSS. The system got easier for developers to read and extend. What we didn't anticipate was that the next reader wouldn't be a developer at all.

In April 2026, Anthropic launched Claude Design. This tool reads a codebase during onboarding to build a model of its design system, then uses that model for every prototype it generates afterward. The same would apply to v0, Bolt, and anything else that learns a design system by reading it rather than receiving human guidance. We wanted Mixtape to onboard well.

Documented for humans isn't the same as legible to an agent

We did a full pass over the codebase in March. We worked on the assumption that AI tools generally would need something more literal than what we had before Claude Design existed as a specific thing to test against. What came out of that work was a central /docs folder covering everything from Component Architecture, Memory Management and Security to Code Quality and Troubleshooting.

Then in April, Claude Design launched so we naturally pointed it at Mixtape. The assumption held up, but not completely. A developer who hits an ambiguous instruction asks a question in Slack. An AI tool infers an answer and bakes it into every design it generates from that point on. Our docs folder was solid for a human reading it top to bottom. It wasn't quite literal enough for a tool that takes every sentence at face value.

So in May we went back and wrote a structured reference file, plus richer per-component READMEs.

What we built

The main outcome is a structured DESIGN.md reference file, read as instruction rather than advice. It resolves every design token to its actual value rather than pointing at the source and assuming the tool will resolve it: colour.primary.colour maps to --colour-primary, which is hsl(223 100% 50%), not just a path in tokens.js.

It also says explicitly what to read and what to ignore. Read src/, docs/, and mockups/. Skip notes/, lockfiles, and build config. Specifying irrelevant files matters for resource usage as well as the quality of the output.

The full-page mockups turned out to be essential too. We point the tool at a real page composition, like a search results page built from real classes, before it generates anything from scratch. Components in isolation don't show how they're meant to sit together.

Component and class inventories with explicit "Nothing else exists - don't invent stuff" instructions, composition guidance, anti-patterns and documentation for the public token API (for example font-size: var(--button-font-size, var(--font-size)) where --button-font-size has no defined value and exists only as a public token, which Claude Design can use-once it knows about it-all feature in this file.

The result is a Mixtape that Claude Design can accurately work with. Developers aren't the only ones prototyping there now. A designer can test a layout idea, or sketch a full page composition, before it ever touches Figma, using real components and tokens instead of an approximation of them. That's the use case we're aiming for. A faster way to explore an idea, not a replacement for the judgement that goes into an actual design.

The bugs it found

Writing that reference meant checking, component by component, whether the documented class actually matched the shipped code. It mostly did. Where it didn't, the gap had been sitting there for a while.

Breadcrumb was one. React was rendering a class that didn't exist anywhere in the stylesheet:

- className={classNames("mx-nav", "mx-nav--breadcrumb", "mx-nav--inline", className)}
+ className={classNames("mx-nav", "mx-nav--breadcrumbs", "mx-nav--inline", className)}

Singular in React, plural in CSS and Twig. The React breadcrumb had been shipping un-styled, and nothing caught it because our snapshot tests only check that output hasn't changed, not that it's connected to anything. Also luckily no projects are actually using the Breadcrumb component in React yet.

Sticky had a similar issue, just inverted. The web component was querying for an older un-prefixed class that used to exist but no longer did:

- let trigger: HTMLDivElement | null = this.querySelector(".sticky__trigger")
+ let trigger: HTMLDivElement | null = this.querySelector(".mx-sticky__trigger")

The web component never found the trigger element it needed to observe, so the "is sticky" check silently never activated. Nobody had flagged it, because the stickyness still worked. The is-sticky state change is just a small, optional progressive enhancement (until scroll-state container queries have better support).

Neither bug was hard to fix. Both had been invisible for the same reason: three output formats (React, Twig, Web Components) from one source, and nothing checking that a class emitted in one place was actually targeted anywhere else. It took writing documentation an AI would take literally to notice.

Where this is heading

We're not leaving this as a one-off audit. The next step is a lint rule that cross-references every mx-* class against the CSS that's meant to style it, so this kind of drift gets caught at merge time instead of during the next big documentation sweep. More on that and some other tooling additions soon, in a follow up post.