How I vibe-configed this website in under 10 hours

A driving factor was the State of Drupal presentation in September 2026, the best Driesnote I have seen. Part of that could be that, for once, I had not seen most of the parts beforehand. But mostly I think it delivered on every front, and made it clear that Drupal is one of the best content management systems to build on, if not the best. Now we have to tell the world. That was one of the important messages too: reach people outside of our bubble, something Alex Moreno has also talked a lot about. So I'm rebranding workflows-of-ai.com into a mix of information, including a blog that spreads the message about AI in general and ties in Drupal where it makes sense.

It is quite interesting. I spend most of my days on the microlevel: how a skill is written, how the Tool API exposes a tool, how the AI module talks to a provider. But I had never used all of it to build a full website. So I tried.

The rule was simple - play to Drupal's strengths: configure first, code last. Every feature started as a search for a Drupal module that already does it. The agents did the configuring. I made the decisions.

I am not sure who came up with the term "vibe-config". It might be Jamie Abrahams or Kristof Van Tomme. What I do know is that configuring secure Drupal modules is a safer way to build for an agent than writing glue code between libraries that might or might not follow good security principles.

You could quite possibly have most of the same feature set up on Wix.com in similar time using AI. But then you would not own it, and it would not be extendable.

This is the number the whole post is about. Out of 1,647,655 lines of PHP, 2,380 were written for this site. I counted them with the code provenance skill from drupal-skills, which is there for exactly that: seeing how much of the code you wrote yourself. The rest is Drupal core and 51 contributed modules and submodules, most of them covered by the Drupal Security Team. What we wrote instead was configuration: 26,939 lines of it, exported and versioned like code.

So why any custom code?

Every post here is a Canvas page, not a node, and some contributed modules still assume nodes, like reading time and RSS feeds. Some things are specific to this site, such as the post layout with chapters and the other versions of a post. And a few things are glue no module offers yet: one MCP tool that sets up a post in a single call, structured data that links the author across pages, and a way to push content from my laptop to production.

I could have used Tool Belt and Google Tag to get the number down even further. But I wanted a realistic version of when to use code and when not to.

Those numbers only work because of the people who look after the rest. The Drupal Security Team and the core team do an incredible job on the basics, and it often goes unnoticed.

I have been in contact a lot lately with Greg Knaddison (greggles) and Drew Webber (mcdruid). They are some of the foundations of why Drupal is trusted by enterprises all over the world. Every time I configure a security-covered module instead of writing code, I build on their work.

It is both a completely new site and a move: the old videos from workflows-of-ai.com came over, and got chapters and transcripts on the way. Locally it runs with the One Line Installer. These were the steps, in order.

Herding the agents

I used herdr to quite literally let Claude Code with Opus 5.5 herd the subagents: Claude Code with Sonnet, and OpenCode with GLM 5.3 remotely and Qwen 3 Coder locally. Opus planned and wrote the specs. GLM 5.3 and Sonnet configured the website. The smaller models took the recurring tasks of the migration.

• The Magoo component library (magoocomponentui): a catalog of components that writes any vanilla component to an SDC or a Canvas Code Component, so I did not have to write the theme layer over and over again.
• ddev-drupal-agent-module-knowledge-mcp: makes the agents look for a module first, so we use modules as much as possible.
• seo-aeo-best-practices: an audit for search engines and AI answer engines, and the fixes that followed.
• web-quality-audit: Lighthouse runs, and the fixes for performance and accessibility.
• superpowers writing-plans: a spec and a plan before any code.
• agent-browser: the agents check every change in a real browser.
• dtk and rtk: fewer tokens for the same work.

The posts here start as an AI draft. In the Context Control Center, AI analysed everything I have written before and the transcripts of my videos, and turned that into two pieces of context: how I write and how I talk. Together with the avoid-ai-writing skill, an agent can write a first draft over MCP that sounds close to me. This post started that way.

It is not a completely honest version of me. In the same way an agent finds internal services I would not have used because I did not know about them, it uses words I understand but would not normally use. That makes it more professional and less personal. At the same time, it lets me write about things happening at a scale that was impossible before.

That is why every post here says how AI was used in it, with the AI Disclosure module. If you publish with AI, it is imperative that you disclose it. See the word imperative - I would probably have used super-important :) Readers should know what they are reading.

In the age of AI there are more ways to consume content, because building it in different forms is easy. So a post here can come with a spoken version for accessibility, a funny AI-generated podcast, a pure reader mode and a narrated PowerPoint. Agents get a Markdown version of every page.

Any post with a presentation can also be shown as one: add ?presentation=true to its address and it opens in fullscreen, narrated or not. That also means I am ready to present on any topic I write about here at any time.

Lighthouse is Google's open-source tool for checking the quality of a web page. It loads the page the way a visitor on a mid-range phone would, and scores it from 0 to 100 in a few categories: performance (how fast the page shows up and responds), accessibility (whether everyone can use it, also with a screen reader or only a keyboard), best practices (security and modern web standards) and SEO (whether search engines can understand it). The newest category, agentic browsing, checks how well AI agents can read and use the page.

This site is close to 100 on every one of them. It is also built for agents: every page has a Markdown version, structured data that links the author across pages, an llms.txt, a sitemap and a robots.txt that lets AI crawlers in. Posts are structured content, Canvas components with typed props, so agents can read them and publish new ones over MCP.

The biggest jump came from two swaps: a lighter consent manager (Klaro! instead of COOKiES, which also removed jQuery) and responsive images. Hover or tap the charts for the exact numbers, and click a legend entry to hide a series.

At the same time I let a vanilla Codex Luna build the same site in Express.js, something I have worked with a lot. The result is a focused website that might be easier for one person to handle. It also has more than 30,000 lines of code.

And it misses what Drupal has from the start: extensibility, permissions, translations, multitenancy and the power of a visual editor like Canvas.

The advantage of the Express.js version is that it did not need any skills to get the same results, and it was ready to deploy to Vercel straight away. Here it took 3 to 4 hours to get deployment working. Those are problems we have to bridge, and it is where Drupal has to end up.

• The "under 10 hours" is the site: 7 hours to have it working locally. Getting deployment working took another 3 to 4 hours.
• Some of the MCP and Tool modules are not stable yet and not covered by the Security Team: Agent Access, Canvas Tools, MCP Server, Tool API and AI Disclosure.
• The server is the one part I kept away from AI. The DigitalOcean setup runs on Ansible roles I wrote myself, with my own hands and my own brain. I do not trust AI with that yet. If I ran managed servers, I would trust something like Hostinger's MCP servers, but I prefer managing my own. And one of the strengths of a LAMP stack is that a site like this runs just as well on cheap hosting.

If you know Drupal

Get the message out there. Write about what you build, show it, and share it outside the Drupal channels. It is not the most advanced or feature-rich framework that wins, and it is not the one with the best UX either. It is the one people talk about most positively. Agents learn from what we write, and in the next training round that becomes what they know.

If you do not use Drupal yet

Get started with the One Line Installer: one command sets up a local Drupal site with the AI tooling. On Windows you need WSL2.

That's it. Thank you for reading.