Vibe Coding Drupal: AI as a Reasoning Partner

This is the fifth installment in my series on "vibe coding" with Drupal. To set the stage:

• Part 1: My Initial Foray (Proving AI can write code)
• Part 2: The Scent of Progress (Keeping AI on track)
• Part 3: Code Directing an Accelerator for Drupal 12 (An evolving role for developers)
• Part 4: A Force Multiplier for Contrib (Using AI to accelerate Drupal contribution)
• Part 5 (This piece): AI as Thinking Partner (Proving AI can help reason through complex architecture)

Back in Part 2 of this series, I discussed some different interpretations of “vibe coding” as a term, and its applicability to my explorations of using AI with my Drupal development. More recently, someone asked about its applicability to this series from a different angle: expertise. Some use the term “vibe coding” to convey non-developers using AI to craft things they simply wouldn’t have had the ability for on their own. By that logic, given that I'm a long-time member of the Drupal community, and already know Drupal well enough to have written a number of modules on my own, is using AI to enhance my efforts truly "vibe coding"?

I'll show my developer roots by starting with the answer: "it depends." It's definitely true that for some of the work, I could have completed it on my own, it just would have taken me longer to get there. In those cases, "AI-assisted development" is arguably a more accurate moniker. Even then, however, it's often accurate to say I would have labored more over certain parts of it. For example, I have less experience writing automated tests.

There have been a few projects, however, that I simply wouldn't have undertaken without help from AI. A prime example is the DDEV add-on I put together, and continue to refine based on my own day-to-day use. It remains one of the most useful tools I've ever used for Drupal development, and it's also been helpful for AI agents to validate their own work, particularly when I ask them to clean up issues like phpstan errors. I only recently started working with DDEV add-ons, and since their functional code is written in bash, it's well outside my typical development expertise.

Similarly, my initial foray into using AI for Drupal development was when I had the idea that would eventually become Canvas Field Component. I had only used Drupal Canvas a little and never looked at its code, so writing a new module from scratch to add a new, dynamic component would have been a daunting proposition. But with assistance from AI it came together much faster than I could have expected. And the feedback I’ve heard from the community is that it has filled an important gap for many others to start their own adoption of Canvas.

AI as a reasoning partner

In that example, however, I actually started with more of a thought exploration. I asked about approaches available to achieve what I had in mind. After some back and forth clarifying the overall concept, Claude offered to implement a first draft.

While AI gave me the ambition to take on a challenge I probably wouldn't have otherwise, and helped me deliver on my vision faster and more complete than I had expected, it started with a conversation. Was my idea possible?

My experience isn't unique. In fact, studies into the impact of AI on productivity consistently find that the true value of generative AI lies not in handing over the keyboard, but in treating the technology as a rigorous planning partner. A landmark study by KPMG and UT Austin’s McCombs School of Business analyzing 1.4 million real-world interactions revealed that high-impact users don’t just use AI to write raw code; they treat it as a "reasoning partner." By using models to frame complex problems, stress-test logical boundaries, and explain step-by-step methodologies, developers can bypass the mental roadblocks of initial planning and architecture mapping. This shift frees up invaluable cognitive bandwidth, allowing engineers to dedicate their energy to the high-value, high-context work that requires authentic human intuition.

However, maximizing this productivity boost requires knowing exactly when to draw the line. In their landmark study on the "jagged technological frontier," researchers from Harvard, Wharton, and BCG found that while AI dramatically elevates performance on tasks within its capability, blindly delegating work outside its logical boundary actually degrades output quality. Developers must resist the temptation to put their workflows on autopilot. Instead of outsourcing entire critical tasks, the smartest approach is to leverage AI as a sounding board to accelerate planning, while keeping the human firmly in the driver's seat for final execution, architecture validation, and complex problem-solving.

I had a similar experience when I recently wanted to work on implementing tooltips to display event data in the Fullcalendar module. I had already done some thinking about the overall approach but by talking through my ideas with an agent, I was able to narrow down the best approach, as well as identify where we could also build in support for people with slightly different needs.

More recently, I decided to launch a high-fidelity prototype as an architectural field test. While the personal objective was a shared recipe and grocery app for my family, the professional goal was to validate AI-assisted architectural decision-making for complex data-modeling problems. I wanted to see if an AI partner could help reason through a site that combined Drupal’s structured data with Progressive Web App (PWA) capabilities, treating it as a laboratory for complex system design rather than just a hobbyist tool.

I wrote out a pretty extensive prompt, explaining my motivations and some ideas I had for the technical approach. I encouraged it to ask me questions. We went through multiple iterations as I pushed back on parts I didn't like, or asked questions about parts I wasn't sure about. Even as someone who spends a lot of time spelunking the deeper recesses of Drupal’s contrib ecosystem, I was surprised by some of the recommendations.

I’ve used Drupal Commerce before but I hadn't heard of the Physical Fields module. AI recommended using it to store the units for ingredients, which would allow for things like conversion between metric and imperial units, and also conversion between the most appropriate units, for example when three teaspoons becomes a tablespoon.

As part of the detailed implementation plan I asked it to create, it even included draft code for things like access hooks, the service worker to support the PWA, and more. I ultimately asked it to also include recommended step-by-step instructions, and then asked for the result in Markdown so I could easily feed some or all of it into an IDE-based agent when I was ready to move forward.

I was tempted to pass the full instructions to an agent and ask it to build the whole thing, and see how close it could get. I decided against it for a couple of reasons. First, I don't have one of those awesome “all you can eat” subscriptions, so there was a real risk it could burn through a pile of tokens doing things that I don't find particularly difficult, and then run out before it got to the parts where I genuinely want its help. Also, there were parts of the plan I knew could use some refinement along the way, so moving on with the remainder of the build would be like putting a kit home on a wobbly foundation. And, this is an application I wanted to actually use. This wasn’t just a technical proof-of-concept, but something I hope will make life easier for my family. But most importantly, I like site building. I enjoy the process of building out pieces, tweaking the user experience as I go, and so on.

Spinning up a new instance of Drupal CMS on the recently released Drupal core 11.4 was blazing fast, as promised. I did struggle a bit with the decision on which site template to use, but ultimately I decided that Starter was likely the best aligned with the project.

As I started to build out the Recipe content type and its associated Ingredient storage entities, I noticed something unusual about the Physical Fields module: it asks you to make a single choice when defining your field about the kinds of units that will be allowed: weight, volume, and so on. Recipes often contain a mixture of measurements: 1 teaspoon of vanilla extract, 2 eggs, 500 g of sugar, and so on. If I followed the intended path of the module, I would need to have multiple storage bundles for ingredients, and someone entering in a recipe would have to choose the right one. Or, I could have a single bundle with multiple fields, and figure out a way to make sure the user only ever sees (and can enter data) in one.

I wondered if there could be a way to implement a new field type that could allow for different kinds of units to be used with a single field. Physical Fields collects and stores two data points for many kinds of units: quantity, and the specific unit chosen. The kind of measurement is set at the field level. I explored the problem with an agent. In the solution we arrived at, each field row would collect three points of data: the quantity, the unit, and the kind of measurement. To meet the needs of my specific use cases, it allows for weight and volume measurements, as well as a simple count (no units), and basic sizes (like small, medium, and large). All of the unit options are presented in the form as a single select, with the units in option groups based on the type of measurement.

There's still a little refinement to the UX of the recipe form I'd like to polish up, but now I'm comfortable that the architecture for managing recipes is solid. I even released the module created for this project as a new contrib project, called Physical Multi Field. At a minimum it will be useful for anyone building a site with similar requirements, but I can see that with a little more work, it could be generalized to be useful to solve a wider set of problems.

More recently I leveraged AI to help me implement a feature that allows anyone viewing a recipe to scale the size/number of servings up or down: make a half batch, double batch, etc. Without a massive prompt, the agent grabbed the original implementation plan, and offered to implement both the scaling feature, as well as the connected add-to-shopping-list button. It even built the storage entity bundles for the shopping lists and shopping list items. 

Building out an in-depth plan, and making sure it would be available throughout the project, paid off handsomely.

Cultivating AI Literacy: The New Developer Skillset

The shift toward vibe coding isn't about delegating our intellect; it is about evolving our literacy. We are moving away from the era of the "keyboard jock", where value was tied to syntax and boilerplate, toward a high-value director-level skillset. To thrive in this new landscape, developers must master new competencies: 

• Architecture Oversight: Navigating high-level system design while AI handles the lines.
• AI Guardrail Governance: Setting the logical and ethical boundaries for agentic output.
• Domain Context Injection: Providing the essential human nuance that models lack.

This evolution demands strict human governance. "AI as a thinking partner" is never a "set it and forget it" solution; it is a way to scale the ability of experts. The Code Director remains the essential human layer for security, compliance, and maintainability. With an army of experts at our fingertips, experts who can still get it completely wrong, it is our job to ensure they stay on the right path, doing the right work, in the right way. We are not just prompting; we are governing the loop.

Be mindful of the ways you add value to the work you use AI to produce. If your only contribution is writing a clever prompt, your value is likely to fade, and quickly as models continue to scale geometrically in their own sophistication.

So delegate what you can, but use the time that frees up to think bigger, to drive more value, and make real progress on those big, hairy ambitious goals that we too often relegate to “maybe someday.”