Vibe Coding Drupal: The Pragmatic Middle Path
Collection :
At the Dev AI Summit at DrupalCon Rotterdam, I opened my session with a show of hands. Who has used AI to assist their Drupal development? Nearly every hand in the room went up. Who has used it for other parts of their job? Most hands stayed up. Then I asked who had fully delegated code creation to AI, and the room got a lot quieter.
That gap between "I use AI" and "I trust AI to do the work" is where most Drupal teams live today. It is also where the most important decisions about AI-assisted development get made, often without anyone making them on purpose.
In , I introduced the idea of the Code Director: a developer who provides direction to an AI agent, or even a swarm of agents, to make sure the right thing takes shape in the right way. In , I described the Code Director as the essential human layer for security, compliance, and maintainability, and argued that AI is most valuable as a reasoning partner. This post builds on both. It makes the case that Code Direction is not a compromise between embracing AI and rejecting it. It is the pragmatic middle path, and it comes with a practical discipline: knowing what, when, and how to delegate.
Three ways to respond to AI
Most of the debate about AI in software development is framed as a binary: you either embrace it or you resist it. In practice, I see more of a sprectrum of adoption among the developers I talk to. There are three specific adoption patterns I'd like to call out, however.
Code Direction as the pragmatic middle path
AI Rejection: "I will do it myself." Some developers keep AI out of their workflow entirely. Their concerns are often well founded: hallucinated APIs, insecure code, licensing questions, and a reasonable suspicion of hype. But rejection has a cost of its own. The developer who refuses to delegate anything will increasingly be outpaced by peers who delegate well, and will miss out on AI as a research and reasoning partner.
Vibe Coding: "I will offload it." At the other end, some developers hand over the whole task. They describe what they want, accept what comes back, and move on when it appears to work. For a weekend prototype, that can be fine. For a production Drupal site that handles customer data, it is a liability that grows with every commit.
Code Direction: "I will delegate it." In the middle sits the Code Director. The Code Director uses AI aggressively, but deliberately. They choose which tasks to hand off, define those tasks precisely, watch the work as it happens, and remain accountable for every line that ships.
The difference between offloading and delegating is the heart of this post. When you offload a task, you stop thinking about it. When you delegate a task, you stay responsible for the outcome, which means you need to understand it, verify it, and be able to fix it.
Why the extremes fail: the debts you cannot see
Every Drupal developer understands technical debt. Margaret-Anne Storey, a professor of computer science at the University of Victoria and co-author of the SPACE framework, argues that AI forces us to track two more. Her , published in , separates what lives in the code from what lives in our heads and in our specifications.
| Debt type | Where it lives | What it is | What AI does to it |
|---|---|---|---|
| Technical debt | The code | Poorly written code, weak modularity, and rigid dependencies | AI can reduce it by automating refactoring and writing tests |
| Cognitive debt | The team's minds | The erosion of shared understanding: a gap between what the code does and what people comprehend | AI accelerates it by writing code faster than humans can learn it |
| Intent debt | The specifications | The loss of the why: missing goals, constraints, and recorded decisions | AI makes it worse by confidently inventing intent when humans do not write it down |
This is why vibe coding is so seductive and so dangerous. It can make your technical debt look better while your cognitive and intent debt quietly pile up. The symptoms show up later: a "safe" change that breaks something unexpected, onboarding that takes far too long, or an agent that builds an elegant architecture for a goal nobody actually had.
The research on individual developers points in the same direction. In a , developers who learned a new Python library with AI assistance scored 50% on a follow-up comprehension quiz, compared to 67% for those who coded by hand. The biggest gap was in debugging. Researchers at Wharton have a name for the underlying behavior: . In their experiments, roughly 80% of participants accepted AI advice even when it was wrong.
In my talk, I described four skills that are most at risk when developers lean on AI without a plan:
Algorithmic decomposition: Breaking vague business requirements into clean, modular logic without first prompting an AI for a blueprint.
Mental code execution: Dry-running code in your head to spot race conditions, off-by-one errors, or memory leaks.
Syntax and API fluency: Knowing Drupal's APIs and PHP's idioms well enough to work without leaning on autocomplete.
First-principles debugging: Isolating root causes with a debugger, logs, and a methodical approach, instead of pasting raw errors into a chat window and hoping for a fix.
Rejection does not solve these problems either. A developer who avoids AI keeps their skills, but often has less time to apply them where they matter most. The answer is not to choose a side. It is to manage the trade-off on purpose.
What a Code Director actually does
In Part 3, I compared the Code Director to an Art Director, who guides designers toward a vision rather than producing every asset personally. That analogy still holds, but Rotterdam pushed me to be more specific about the job. A Code Director:
Makes sure the right context is available, and ensures that each task is well defined and tightly scoped.
Provides relevant examples wherever they exist, such as an existing service, a similar plugin, or a pattern from core.
Watches what the agent is doing, and is ready to stop and redirect it.
Tests the result thoroughly, and asks for tweaks or makes simple ones directly.
Understands the code, and asks for an explanation where necessary.
Validates that the code meets every standard: Drupal coding standards, static analysis, and automated tests.
Notice that none of these steps is "write a clever prompt." As I wrote in Part 5, if your only contribution is the prompt, your value will fade quickly as models improve. The Code Director's value lies in judgment: what to ask for, how to tell whether it is right, and when to step in.
Delegation is a management skill, with a twist
If the Code Director's job is to delegate, then decades of management advice about delegation should apply. Some of it does. Some of it is turned on its head. And some of it is entirely new.
What still holds
Define explicit outcomes and acceptance criteria. With human teams, vague goals lead to confusion. With AI, vague prompts lead to hallucinated solutions. Specify constraints, output formats, and edge cases up front: the PHP version, the Drupal core version you are targeting, and which APIs or libraries are off limits.
Match the task to capability. Good managers do not hand complex strategy to an intern. LLMs excel at scaffolding boilerplate, converting layouts, generating unit tests, and writing regular expressions. They struggle with novel architecture, complex state, and business logic that cuts across the system. Where you use AI matters too: a conversational app and an agent inside your IDE are suited to different work. And of course, choosing the right model and "effort" (medium, high, etc) will ensure you get reliable output without burning tokens unnecessarily.
Provide full context and material. A developer cannot build a feature without user stories and API documentation. For AI, that means managing the context window: relevant schemas, existing codebase patterns, rulesets and style guides, and active dependencies. Exposing context in a granular way reduces the risk of filling the buffer and triggering hallucinations. Also be intentional about what skills you want to be available. There are a number available that can dramatically improve your results, but too many eat up you context window, or even cause hallucinations, if you're using skills with contradictory instructions.
Establish strict review and verification loops. "Trust, but verify" applies directly. Pair every delegation with immediate verification: linters, test suites, type checks, and a manual review before you commit. Write those expectations into an AGENTS.md file so every agent session starts with them.
What is inverted
Autonomy. With people, you say what to do and leave the how to them, because it fosters ownership. With AI, too much implementation freedom produces architectural drift, dead code, and unvetted third-party dependencies. Effective AI delegation means micromanaging the how: "Use the existing service. Do not add a new HTTP library. Use Drupal's built-in HTTP client."
Ownership and accountability. With people, you hand over ownership of the outcome. AI has no accountability at all. You retain 100% ownership of every line you ship, and "the AI generated it" is not an acceptable explanation for a production bug or a security breach.
Trust and psychological safety. With people, trust is built over time so they feel safe taking risks. AI has no ego or fear of failure, and "trusting" a model leads straight to confirmation bias and rubber-stamping. Replace trust with automated test gates.
Delegating for growth. With people, you assign stretch tasks so juniors can grow. You do not delegate to train the AI. You delegate to save time. If you delegate work in domains you do not understand, you risk your own skills, accept code you cannot debug, and add to your cognitive debt.
What is new
The verifiability rule. Only delegate implementation tasks that can be verified quickly, through automated tests, static typing, or visual rendering. If a task takes longer to verify than to write from scratch, write it yourself.
Test-first delegation. Write a failing test or a typed interface first, then ask the AI to make it pass. The test becomes your acceptance criteria, in a form the agent cannot misread.
From workhorse to toolsmith. Instead of asking AI to perform a repetitive task again and again, ask it to build a script or CLI utility that does the job deterministically. This is the approach I described in Part 3 with the add-on: AI helped create the tool, and the tool now runs the same checks the same way every time.
Deciding what to delegate
The simplest test I know fits on one line:
Delegate when the time to complete a task manually is much greater than the time to verify the AI's version.
Time to verify is not just a quick glance. It includes testing the result, reviewing it line by line, and remediating whatever is wrong. When verification is cheap, delegation is a clear win. When it is expensive, the speed of generation is an illusion.
Good candidates for delegation
Boilerplate and scaffolding: Module skeletons, routing and controller stubs, build scripts, and configuration files.
Test stubs and synthetic data: Verbose test assertions, edge-case arrays, and realistic mock payloads.
Syntax translation: Converting familiar logic between languages, or transforming legacy data formats, for example during a migration.
Documentation and summaries: Docblocks, API documentation, and a quick high-level summary of a large, unfamiliar repository.
Keep these in your own hands
Core business logic: Writing the fundamental domain rules yourself keeps your understanding of how the software works deep and intuitive.
System architecture and trade-offs: Content models, entity relationships, caching strategy, and non-functional requirements like security and performance require human judgment.
Root-cause debugging: Stepping through stack traces, setting breakpoints, and profiling problems yourself. Offloading debugging entirely degrades your mental model of how the system behaves at runtime.
Learning new paradigms: When you pick up a new language, framework, or pattern, write it by hand for the first few weeks to build real understanding before you delegate the syntax.
The four filters
For everything in between, I use four filters. A task that clears all four is a strong candidate for delegation. A task that fails any one of them deserves a closer look before you hand it off.
| Filter | The question to ask | Delegate when | Write it yourself when |
|---|---|---|---|
| Verifiability | Can the correctness of the result be confirmed quickly and objectively? | Pass or fail outcomes governed by types, unit tests, linters, or schema validators | Correctness is open-ended: subtle concurrency, algorithm design, or API ergonomics |
| Stakes | How large is the blast radius if a subtle defect slips through? | Non-critical tooling, prototype spikes, isolated build scripts, and test mocks | Authentication flows, security perimeters, data privacy controls, and financial transactions |
| Complexity | Is the problem self-contained, or does it cross system boundaries? | Modular, isolated transformations with bounded context and explicit inputs and outputs | Broad system interactions, global state changes, or distributed consistency |
| Familiarity | Do you already have a deep mental model of this problem space? | Familiar frameworks and established patterns, where you can spot anti-patterns instantly | Unfamiliar paradigms or domain rules, where you lack the judgment to supervise |
The familiarity filter is the one most often skipped, and it is the one that protects you from cognitive debt. If you could not review the output with confidence, you are not delegating. You are abdicating, and in danger of becoming a .
What this looks like in practice
Here is the approach I use for most non-trivial Drupal work, including the projects I described in Part 5:
Research (optional). For a new problem space, I start with a deep research report on existing solutions and possible approaches. In the Drupal world, the answer could easily be one or more contributed modules that already exist.
Discuss the problem. I keep this stage conversational, typically in Claude Cowork or Google Gemini. I ask the AI to poke holes in my ideas and to anticipate problems before any code exists.
Write a detailed plan. I capture a step-by-step implementation plan in a document such as
PROJECT-PLAN.md, broken into phases if the work is substantial. This is where intent debt gets paid down before it accrues.Implement, and watch. I start the implementation and keep an eye on the approach. If the agent heads in the wrong direction, I interrupt, give feedback, and iterate.
Capture what was learned. I generate an AGENTS.md file so that the standards, conventions, and decisions from this project carry forward into every future session.
Work methodically. Particarly when the work is substantial enough to have phases, I work on them one at a time. Before I move on, I test the work, review the code, ask for changes (or explanations, when needed), and run tests and static analysis myself. When I'm comfortable the changes are up to standard, I put them into a commit, even if I only keep it locally. Then I make sure the phase has been marked as done in the plan (the agent often confidently does this itself), and start the next phase of work in a new conversation.
For team leaders
If you lead a Drupal team or agency, the same principles scale up:
Make intent explicit. Plans, decision records, and AGENTS.md files are not paperwork. They are how you keep AI from inventing intent on your team's behalf.
Gate on automation, not trust. Coding standards checks, static analysis, and automated tests in CI turn "trust, but verify" into a process that does not depend on anyone's attention span.
Protect skill development. Give junior developers room to learn new areas by hand before they delegate them. The time saved today is not worth a team that cannot debug its own code tomorrow.
Keep ownership human. Make it clear that whoever opens the merge request owns the code, regardless of who, or what, typed it.
Step into the role
The pragmatic middle is not a fence to sit on. It asks more of you than either extreme. To work as a Code Director:
Be mindful of what and when you delegate. Keep your critical skills fresh, train up on new domains by hand, and use AI only where it saves real time and effort.
Monitor and redirect. Watch the work as it happens, and keep a critical eye on everything that is generated.
Own what you ship. Maintain responsibility for, and understanding of, every line of code you deliver. Do not become a "meat proxy" who simply passes AI output from the chat window to the repository.
Treat AI as a thinking partner. Its greatest value is helping you reason through a problem, not replacing the reasoning.
