The Problem Nobody Talks About With AI Coding Assistants

The Context Problem With AI-Assisted Development

Every AI coding session starts the same way. You open the tool. You explain your project's stack. You describe your config management rules. You remind it not to touch settings.php. You tell it about your Jira workflow, your branch naming conventions, your test framework.

Then you do it all again the next day.

The real friction with AI-assisted development is not capability — it is context. Claude, Copilot, and their peers can generate functional code, but they retain none of your organizational knowledge between sessions. Every session starts at zero. If you want to understand why that matters at an engineering level, the backstory of how one engineer's frustration turned our SDLC into a plugin is worth reading first.

On a Drupal project, this gap is dangerous. Drupal's config management system requires strict discipline: import, export, verify clean status. AI that hand-writes config YAML with hardcoded UUIDs creates downstream merge disasters. AI that writes to settings.php or *.install files without safeguards creates security exposure. AI that skips GrumPHP validation creates PRs that fail CI and waste reviewer time.

These are not edge cases. They are the default behavior of every generic AI coding assistant on every Drupal project, every session, every time.

The Hypothesis Behind a Spec-First AI Development Approach

What if, instead of teaching AI about our process every session, we encoded the entire process into a system AI could execute autonomously?

Not a prompt library. Not a README with instructions. A plugin architecture where each stage of the software development lifecycle exists as a discrete, composable, overridable AI skill — executable with a single natural language command.

The hypothesis was specific: a Claude Code plugin, built for Drupal on DDEV with Jira and GitHub, could transform AI from a code generator into a process executor. One natural language command. Twelve automated steps. Two mandatory human checkpoints. Zero config accidents.

This is the same principle behind our broader work on building an internal AI plugin marketplace — and it reflects a wider shift in how engineering teams should be thinking about AI tooling.

What We Built: An AI Software Development Lifecycle Plugin

The AI software development lifecycle plugin ships with 11 modular skills, 3 rules, pre/post tool hooks, and MCP configuration. Every skill, rule, and hook is tuned for Drupal on DDEV with Jira and GitHub.

Here is the full automated workflow triggered by a single command:

Two things AI never does without a human: start building (step 3) and ship code (step 12). Everything between those gates is automated but governed. This is what separates an AI engineering process automation tool from a generic code generator — structured accountability at every stage.

The 11 Skills That Power the Drupal AI Coding Workflow

Each skill is usable standalone or as part of the orchestrated SDLC loop. Project-level skills take precedence over plugin skills, so teams can customize without forking — enabling consistent AI engineering process automation across projects with different conventions.

For teams working on improving test coverage alongside this workflow, see how one AI session changed the test coverage standard across three codebases.

Config Discipline In Practice: Why AI Quality Gates Matter for Drupal

Drupal config management is where generic AI tools cause the most damage. The correct sequence is non-negotiable: config:import, then config:export, then config:status to confirm a clean state. AI that generates config YAML directly, without running the round-trip, produces files with hardcoded UUIDs that break on every other environment.

The plugin enforces this discipline through pre/post tool hooks. Before any file write, hooks check whether the target is a protected file (settings.php, *.install, config_split YAMLs). After every config change, the round-trip validation runs automatically. Claude will not raise a PR if the config status is not clean — this is a hard gate, not a suggestion in a README.

This approach is consistent with Axelerant's broader philosophy on CI/CD enablement — automated enforcement at every stage so human reviewers focus on judgment, not checklist compliance. It also connects to the governance lessons covered in what an autonomous agent taught us about governance.

How The Experiment Progressed

The plugin went through multiple internal iteration cycles before reaching a stable release. Version numbers accumulated up to 1.1.3 as the creator tested skills against real project work, identified failure modes, and tightened constraints. The stable release reset to v1.0.0 as a clean baseline.

Here is how adoption and feedback unfolded after the internal announcement:

At least 4 to 5 team members were actively using or testing the plugin within the first several days. The feedback loop was fast: issues surfaced within minutes, fixes shipped within hours, and constraints that required architectural decisions — token budget, sub-agent isolation, Bitbucket support — were identified and queued within the first week.

This rapid iteration mirrors the approach described in our post on how an open-source plugin made Drupal delivery more predictable.

What Worked And What Did Not

What worked:

One engineer's experience with Site Studio component generation was the clearest positive signal. The YAML output required one round of correction — meaningfully different from writing complex YAML by hand or debugging AI-generated config that violates Drupal conventions.

The onboarding skill auto-detects the project's drush prefix, quality command, GitHub owner/repo, and Jira cloud instance. Setup time ranged from 5 to 20 minutes depending on engineer familiarity — faster than most teams' manual environment documentation processes. For context on how AI is reshaping engineering workflows more broadly, see how AI is transforming engineering workflows at Axelerant.

Frequently Asked Questions

What is an AI software development lifecycle plugin?

An AI software development lifecycle (SDLC) plugin is a structured system that encodes an engineering team's full workflow — from ticket reading to PR creation — into composable AI skills. Rather than relying on ad-hoc prompting, the plugin executes each stage of the SDLC autonomously, with mandatory human checkpoints at spec approval and code merge.

Why do generic AI coding tools fail on Drupal projects?

Generic AI coding assistants like Claude or GitHub Copilot have no persistent knowledge of Drupal's config management requirements, protected file conventions, or project-specific toolchains. Without enforcement, they generate config YAML with hardcoded UUIDs, write to protected files like settings.php, and skip validation steps like GrumPHP — creating CI failures and merge conflicts on every project, every session.

What is spec-first AI development?

Spec-first AI development is an approach where the AI generates a structured implementation specification from a Jira ticket — including numbered acceptance criteria, test mapping, and risk notes — before writing a single line of code. A human engineer approves or revises the spec at a mandatory checkpoint, ensuring the AI builds the right thing rather than the first plausible thing.

How does the Claude Code SDLC plugin handle Drupal config management?

The plugin uses pre/post tool hooks to enforce Drupal's config round-trip sequence (config:import → config:export → config:status) after every config change. It also blocks writes to protected files including settings.php, *.install, and config_split YAMLs. Claude cannot raise a PR if config status is not clean — this is a hard gate, not a README suggestion.

Can the plugin be used with tools other than Jira and GitHub?

The plugin was built natively for Drupal on DDEV with Jira and GitHub. Within the first week of release, an engineer independently ported it to Mautic. Bitbucket support has been flagged as a gap, with project-level skill overrides available as a workaround while native support is in development.