Ten Minutes, Not an Hour: What Efficient AI-Assisted Development Actually Looks Like

The Drupal LMS module lets site builders define quiz-style "activities": question types a learner answers as part of a course. For a while, LMS shipped two separate plugins for selection-based questions: one for single-choice answers, one for multiple-choice. They did almost the same thing internally. The only real difference was the configuration toggle that didn't need to live in two separate classes once Activity - Answer plugins became configurable.

Issue #3546362 merges the two plugins into a single configurable one, writes an update hook so existing sites migrate their configuration automatically without breaking, and updates the QA fixtures and functional tests that reference the old plugin pair. None of this is conceptually hard. Every long-lived module accumulates this kind of work, where touching four or five files consistently is non-negotiable and a missed reference breaks an update path for every site running the module.

That combination, low conceptual difficulty, high mechanical thoroughness, turns out to be exactly where an AI coding tool earns its keep.

The Workflow: Solve It. Then Let the Prompt Become the Issue.

As the module's maintainer, I didn't start by filing an issue and waiting for someone to pick it up. I solved it myself, with Claude Code doing the implementation.

1. I wrote a detailed prompt describing the merge: which two plugin classes to combine, what the resulting configuration should look like, what the update hook needed to handle for existing activity type entities, and which test fixtures and functional tests needed updating.
2. Claude Code implemented the merge, the update hook, and the test updates in one pass.
3. I reviewed the diff and made two or three rounds of corrections (nothing structural, mostly coding-standards and best-practice nits).
4. Once the change was solid, I opened the merge request and filed the drupal.org issue, using the same prompt, lightly trimmed, as the issue's Problem/Motivation and Proposed resolution text.

That last step is worth sitting with. The prompt wasn't a throwaway instruction I deleted once the code worked. It was specific and complete enough that it doubled as the project documentation other contributors would read. Writing a good prompt and writing a good issue summary turned out to be the same task, done once.

The Math: Ten Minutes vs. an Hour

The ten-minute number assumes one more thing, though: a codebase that's giving the agent good examples to work from. Start to finish, including my review and correction passes, this took about ten minutes. Finding every reference to the two old plugin classes, writing the update hook, regenerating the QA fixtures, and adjusting the functional tests by hand would have taken me roughly an hour.

Claude Code isn't faster here because it's "smarter." Repeatable, multi-file, consistency-dependent work is exactly what thoroughness-by-checklist is good at. Checking every reference to a renamed class across five files is something an agent handles in seconds without losing its place, while a human doing the same task fights boredom and the risk of missing the one reference buried in a test fixture. The hour I'd have spent wasn't an hour of hard thinking. It was an hour of careful, repetitive checking, which is the part of the job that's safe to delegate, provided someone still reviews the result.

The Codebase Is Part of the Prompt

It's easy to focus on the prompt and forget the other half of the equation. Claude Code is pattern-matching against whatever code already surrounds the change. A detailed prompt tells it what to build; the existing codebase tells it how things are built here. If that codebase is inconsistent, or full of workarounds and dead patterns, the agent will happily extend the inconsistency, with no way to know that the surrounding code is something to avoid imitating.

The Drupal LMS module's plugin architecture is consistent and modern, including typed properties, constructor-based dependency injection, and configuration schemas that follow Drupal's own conventions throughout. That's exactly the kind of codebase an agent can extend correctly on the first attempt, because the pattern it's matching against is the pattern you actually want repeated. The corrections in this case were minor precisely because there wasn't a backlog of inconsistent legacy code for Claude Code to mistakenly treat as precedent. On a messier, older codebase, the same prompt would likely have needed more correction rounds, not because the agent got worse, but because it had worse examples to learn from in the surrounding files.

This cuts both ways for anyone evaluating how well AI tools will work on their own project. The return on a good prompt is capped by the quality of the code already there. Cleaning up codebase inconsistencies isn't just good practice anymore; it's also an investment in how well an AI agent will be able to work in that code afterward.

What Went Wrong (Briefly) and How to Fix It

Nothing in the first pass was structurally wrong. The corrections across those two or three iterations were about coding standards and Drupal-specific best practice, the kind of thing a thorough code reviewer would flag.

The interesting part isn't that there were corrections; it's what happens to them afterward. Rather than re-explain the same coding-standard preference every time it comes up, I keep a running set of project conventions in CLAUDE.md, the instructions file Claude Code reads at the start of a session. Something like:

## Coding Conventions
 
- Use typed properties and constructor property promotion where the
  module's minimum PHP version allows it.
- Plugin classes depending on services must use dependency injection
  via `create()`, never `\Drupal::service()` calls inside plugin logic.
- Update hooks must be idempotent — check the current state before
  mutating config, since update hooks can be re-run in some workflows.
- New configurable plugins need a corresponding entry in
  `tests/data/activity_types.yml` before functional tests are updated.

Every correction I make more than once is a candidate for this file. It's a small bit of overhead the first time, and it means the next plugin merge, or the next contributor using Claude Code on this codebase, doesn't relitigate the same coding-standards conversation. The conventions compound; the corrections don't repeat.

Why I Don't Hand Off to Multiple Sessions

It's tempting to treat this kind of repeatable work as something you can queue up and walk away from. Kick off a few sessions, come back when they're done. I don't do that, and I don't think it's the right tradeoff for code quality.

Every session I'm not actively reviewing is a session where Claude Code is making judgment calls without my insight in the loop. Spread across multiple unsupervised sessions, two things happen. The result gets less reliable, because small wrong assumptions compound instead of getting caught at step two; the cost goes up, because more back-and-forth is needed to recover from those assumptions than would have been needed to just confirm them with me directly. A single session where I review every proposed change as it's made costs more of my attention up front, but it costs less overall, and it's the only version of this where I can say with confidence that the result is correct. Not "probably correct, I'll find out in code review."

That's the actual efficiency claim here, and it's worth being precise about it: the time saved comes from delegating mechanical thoroughness, not judgment. The ten minutes still include me reviewing every change.

What Generalizes

This was a small fix to a Drupal module, but the pattern holds for AI-assisted work generally:

• A detailed prompt is documentation, not scaffolding. If you write it with enough care to drive a correct implementation, it's usually already good enough to be the issue, the PR description, or the changelog entry. Writing it twice is wasted effort.
• Mechanical thoroughness is the right thing to delegate; judgment isn't. The hour this would have taken by hand was mostly careful checking, not hard decisions. That's the profile of a task where an agent saves real time without costing you quality.
• Live review beats batched review. Catching a coding-standards issue at the moment it's introduced is cheaper in time, tokens, and correctness than discovering it after several unsupervised sessions have built on top of it.
• Recurring corrections belong in a conventions file, not in your head. A CLAUDE.md (or equivalent instructions file) that accumulates project-specific standards turns "I have to say this again" into "the agent already knows this."
• The codebase is part of the prompt. An agent extends whatever patterns already surround it. A clean, consistent codebase gets clean, consistent output on the first try; a messy one teaches the agent to be messy too. None of this requires exotic tooling. It requires treating the prompt as a real artifact and treating review as something that happens during the work, not after it.

If you're trying to figure out where AI genuinely speeds up your development workflow, and where it doesn't — we'd love to hear about your project.

• AI
• Drupal
• Drupal LMS
• Open Source CMS