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.