We are starting to talk about what documentation we need to make AI better at Drupal. That includes public content that helps train future models and structured context that can be retrieved or passed to AI agents. If we can make progress on that by the end of 2026, alongside better standardisation of how AI integrates with Drupal modules and workflows, it would be a big step forward….before a single line of code is written or released, there are many steps and decisions already taken, and you inherit the decisions made in the past. So if you genuinely care about the impact you make, you also have to think about much more, such as how we share context, how we make decisions.
Ronald te Brake: We try to embed decision records into the development process in a way that keeps things lean and does not slow the team down.
TDT [2]: You’ve described AI as a “new team member” rather than just a tool. What shifted your mindset from skepticism to seriously exploring AI in your dev process?Ronald te Brake: I think first and foremost it’s important that we’re improving the documentation on drupal.org, this will help train the models out there with up to date information on everything Drupal. But that doesn’t help people still working in an earlier Drupal version.
TDT [8]: You’ve mentioned the Claude Code module, Context7, and custom Cursor rules as current efforts. Do you see your proposal integrating with them or replacing them?
Second, we store the record in the place the team already works, for example right in the Git repository in a docs folder or in our case in the team’s knowledge base. That removes friction.Ronald te Brake: The goal is to give your AI tool of choice a sense of Drupal and make sure that diverse setups shape the context needed to guide AI to write for, and work with Drupal. That likely means most of Claude Code, and Context7 related functionality are accounted for. But teams can have their own rules, commands, tools and workflows. With Open Social for example we work in a monorepo with different frameworks, so we will still have the need for other rules and tools to apply there.
So my role changed. I care about building a space where good work can happen. I push for clarity. We write down decisions and trade-offs so future engineers don’t wander lost. I shape workflows that remove friction. I also hope my peers see me as a mentor, hands-on and easy to reach. I want there to be no barrier for engineers to find me. If someone wants to talk, ask something, or challenge an idea, they should feel free to come to me anytime. I review their designs, ask questions to help them think deeper, and don’t just hand them all the answers; I help them grow their judgment.They discuss the future of Drupal in this shifting landscape, the importance of encoding standards for AI tools, and how developers can stay effective as the ecosystem evolves. Ronald shares practical insights from his work and a vision that keeps developers at the center, even as automation and intelligent systems take on a bigger role.
All of that should make it truly effective for all kind of developer workflows.
Secondly, we have a lot of amazing information on api.drupal.org, however this is not available easily for searching and tooling. One thing we could do here is to get this information available, per version, in a vector database. That allows us to utilize this as version specific information and make sure it’s the most relevant for your Drupal version. With an MCP tool we can make sure we follow the right version here. For example, how to best deal with plugins or autowiring, that might have additional information based on which Drupal version you’re working with. If we were to add that to our agents.md file, we will end up with eating up valuable context again that might not be useful for every interaction with AI.Third, we make it part of the workflow. For example our definition of done might include: “If this change involves a new module then create or link the decision record”. That way it does not feel like an extra task but rather a natural step.So when I noticed that AI-generated code improved quality but still did not match our conventions, it reminded me of working with a new developer. So the big shift came when we were able to give AI our explicit guidelines and rules and saw it actually impacted its quality even more.My world was all about code, and I loved how my code could make something real, and seeing it work was thrilling. As our product grew, though, the kind of problems we faced also changed. You could write the prettiest code, but if it doesn’t solve an end user’s problems, how helpful is it? We also need to understand that, Ronald te Brake: For me it starts with understanding both the tool and the team. Every team already has habits, shortcuts, and ways of working that they built over time, so introducing AI should never feel like enforcing change. It is about facilitating it. I focus on creating space for people to explore the tool, share what works, and learn from each other. We set clear expectations for what the tool should and should not do, but we let the team find its rhythm. Switching tools is hard, so I prefer to guide adoption rather than push it. I keep an eye on how it is being used, make sure the benefits are real, and help the team build confidence.
As the models evolved, I watched how their quality improved. It started to feel like you’d have a live chat with Stack Overflow, and I’d treat the answers with the same skepticism. Vibe coding was fun, creative, and experimental, but I hope I don’t need to explain to anybody that it’s not necessarily safe to blindly follow what’s been generated. The fact that the code “works” did not mean it was the right code for the job.
That framework includes hard requirements: the tool must support our monorepo setup so it understands shared modules and dependencies. It must respect security and privacy, no training on any proprietary data, and it must integrate with our existing processes for example. As models and tools matured, they allowed more structured guidance. So we also needed the ability to influence AI’s behavior.TDT [7]: Laravel Boost provides AI with deep, curated context through semantic search and internal tools. What would a Drupal equivalent need to make it truly effective?We can always add more later, like version-specific information, detailed tools, and more advanced integration patterns. But first we need that common starting point that helps AI and developers align with Drupal’s best practices. Once that is in place, it becomes much easier for the community to extend and refine it together.TDT [11]: Between Drupal CMS, the Experience Builder, and AI, the ground is shifting fast. What do you think most Drupal developers or agencies are underestimating about what’s coming?Finally, we share our decisions in our developers channel and newsletter. That way we share knowledge and promote people to follow the standards set.
But the idea of those challenges aren’t new, when we onboard a new colleague within Open Social they do not only need to understand Drupal, you need to understand Drupal within the context of Open Social. Stack Overflow would also not work for that. You have to build up the confidence and knowledge for that, provide the right context, give it time and attention people need to get there. For those challenges, we already have guardrails, processes, and conventions in place.
Just think about onboarding somebody, how on earth are they able to understand these decisions or hidden standards otherwise? They weren’t there when the decisions were made, or know the circumstances under which you’ve made that decision. Knowing this months from now, removes any guess work and helps you iterate and improve. Trust me, your future self will also thank you.First, we have a template for these records. Whenever we make a significant decision like choosing a module or library, we fill out that template: what is the context or problem, what did we decide, what were the alternatives, and what are the trade-offs or consequences. We keep the scope focused. We only create records for decisions that matter months from now, not for every tiny change.For a first release of the Drupal AI Coder Starter Kit, I think the most important thing is to set a clear foundation. For me, the non-negotiables are pretty simple. It needs to include the basic coding standards and the developer guidelines. That is the structure that gives everyone the same language to work with.
DrupalJam 2013 |
Dutch Drupal Association / Dutch Drupal Association
Ronald te Brake: When we started experimenting with AI at Open Social, we had no rulebook. We let people try tools here and there. But soon we realized that to scale safely with multiple editors and teams, we needed a framework. So we built an AI policy and framework on how we can integrate these tools in our engineering teams, and how to do that responsibly.
So I moved from writing parts of the product to shaping how we build the product and grow while we do so–from writing code to building a culture of clarity, trust, feedback, learning and always being available to the team.
People often started providing context by doing some form of prompt engineering, phrasing their instructions so the model gives you as close to an answer you’d expect. But prompt engineering is just the first step. For a while now you have additional ways to provide AI with context and instructions for your project, one way of doing that is using a tool equivalent to an agents.md file. Which could be Claude.md for Claude or Cursor’s rules etc. It’s basically a readme for agents, giving it context and instructions to help AI.
We can encode our standards, patterns, and provide our best practice examples, regardless of the data it’s trained on. That ability to influence its output was key. It stopped being a black box and started feeling like something we could shape into something helpful.
The amount of opportunities that gives us is just mind blowing to me.
What I think some might still underestimate is not the technology itself, but the scale of integration that is happening. Drupal is no longer just the foundation. It is becoming the framework for orchestrating the whole digital experience, inside and outside its own walls.Ronald te Brake: My career started as a junior developer at GoalGorilla, the agency from which Open Social was founded. I’ve been fortunate to grow with the company, now for almost 14 years. Growing from junior to lead engineer, team lead and now engineering manager.
With site templates and recipes, you can already spin up a fully functional website that fits a specific use case such as education, community, or commerce, and be up and running with all the right building blocks in place. It is a bit like getting a prefab home, school, office or shop that is already wired, furnished, and ready to live in, but you can still redesign every room to your own taste. When you add ECA and its orchestration layer, it becomes like adding smart automation where everything starts talking to each other, responding to triggers, and adapting as needed.
TDT [6]: Let’s dig into the Drupal AI Coder Starter Kit. What are the non-negotiables for a first release, and who exactly do you see owning or maintaining it long term?Additionally what I found interesting, is the ability to explain the tool of choice what parts of your system to ignore, and what to index. Similarly to how Git ignore works for untracked files that Git should ignore. It allows us to have Drupal Core and Contrib indexed so Cursor is able to better deal with code from there. But also, we now have the ability to explain what parts of our system are potentially covered in technical debt. We ignore for example parts of our Behat tests, which are written without our new standards and allow it to index the new ones. This increased the quality of the tests written greatly.TDT [1]: From your early days with Drupal to leading engineering at Open Social, how has your role evolved in shaping not just code, but the culture and workflows around it?Ownership should ideally sit with Drupal Core. This kind of foundation should live as close to the code as possible in my opinion, although I have no problem at all to see this move faster in the Contrib ecosystem. But ultimately, moving this under the Core umbrella allows us to ensure consistency and long-term maintenance, and it also signals to the community that this is something serious and supported. Imagine we have updated coding standards, new API’s and more. It would be great if this can automatically evolve alongside of it.
Ronald te Brake and his colleague Bram ten Hove presenting at DrupalCon Seattle 2019
TDT [5]: You stress AI governance and structured onboarding. What’s your checklist or framework for introducing an AI tool into a professional team without it becoming chaos or a crutch?
But, you have to keep in mind that context is a finite resource. You can only feed so many tokens into the model at once and for the quality of the response, more context does not always mean a better result. So a relatively new term is emerging now: context engineering. It’s not as much about the right words, more about the right context to get the desired response. This is something I’m still trying to find the right balance between, but I can recommend everybody to read up on this term.
TDT [10]: How do you convince teams, especially fast-moving ones, that investing in documentation and governance now pays off later, especially with AI in the mix?
Even now, I lead from the front. When there is a hard problem, I roll up my sleeves and commit to getting it done. Being hands-on means I stay close to the reality the team faces, maintain credibility, and stay sharp.Ronald te Brake: Good question. I hope people have watched the Driesnote from DrupalCon Vienna, so I am not sure if anyone is truly underestimating it. But I am honestly in awe of everything coming together right now. Between Drupal CMS, Single Directory Components, site templates, recipes, and ECA, we are seeing Drupal evolve into something far more connected and dynamic than before.TDT [4]: Tools like Copilot, Cline, and Cursor each have their strengths and constraints. How do you decide which ones to adopt, given Open Social’s multi-editor, multi-team setup?Obviously I am a bit biased, but I keep advocating for the developer persona in all this. For me, a good year would be one where developers can truly use AI to enhance how they work with Drupal. That means not just having cool features, but practical tools that help us write, understand, and maintain code better, automate repetitive work, and provide smarter context inside our workflows.Ronald te Brake: Context is key. Without it, even the best intentions can turn into confusion later. I usually tell teams that documentation and governance are not about slowing down, they are about setting the playfield so we can keep moving fast with confidence. We all know that under pressure, with deadlines, we make certain choices. We take shortcuts. We create technical debt. And that is fine, it is part of building software. But when someone new joins, or when AI starts indexing your code base, that same debt becomes an invisible risk. It gets reused and repeated without anyone noticing.TDT [3]: In your blog, you compare AI to a junior developer that lacks context. What are the most effective ways you’ve found to “train” AI to understand your team’s standards and architecture?Ronald te Brake: I never expected AI to solve everything in one step. I just started using it with a healthy dose of curiosity and skepticism. It felt a lot like when I first learned to code: you try something and you see a result fast. Sometimes it works, often not. And that was okay. I did not expect perfection.
Ronald te Brake: I have been lucky to work closely with the team, and I completely trust the direction they are taking. They were already exploring AI agents before most of us even realised what that meant. They are deeply connected to what is happening in the AI space, and I am confident that if we follow their roadmap, 2026 will be an exciting year for Drupal and AI.
Now combine that with AI and the addition of tools like Activepieces, which makes it simple to connect Drupal to automation outside its ecosystem, and you can start imagining entire experiences that build, optimize, and even personalise themselves. From start to finish, this is no longer just about building websites. It is about crafting intelligent, living systems that learn, adapt, and evolve.I believe deeply that failure is part of growth. I want the team to know it is okay to try something new and fail. When it does fail, it is an opportunity. By doing that, failure becomes learning for all of us. I do not want mistakes hidden out of fear.
TDT [9]: You’ve written powerfully about being your own worst enemy due to undocumented decisions. How do you embed decision records into your dev process without slowing velocity?
It might feel like you’re hurting the velocity, but it actually supports velocity, not hinders it. Because once the right docs and rules are in place you spend less time later on firefighting, debugging weird behaviours or re-discovering what we did last year. The “build fast now then fix world” model looks cheap now but costs a lot later.In this interview with The DropTimes, sub-editor Alka Elizabeth speaks with Ronald about how AI is changing the way we build software. He doesn’t see AI as a magic solution but as a teammate that needs guidance, context, and clear boundaries. His work at Open Social shows how thoughtful governance, strong documentation, and open communication can help teams adopt AI without chaos.On top of that we can have ddev or docker specific tooling, so we can query the database, run drush commands etc.Ronald te Brake: First, context is everything. AI is built on large training data out in the world, which often does not know your internal trade-offs, legacy decisions, or architectural directions, let alone understand every intricacy of Drupal.Ronald te Brake:
Finally, the world of AI tools is volatile. Pricing plans shift, features change. The tool that fits best today may not tomorrow. That’s why our framework keeps us agile. We continuously evaluate whether a tool still meets our requirements. If not, we’re ready to switch.
TDT [12]: What would a good year look like for AI in Drupal by the end of 2026? What should the community realistically aim to ship, adopt, or standardize?To make it useful, you have to feed in your context and expectations.Documentation gives that missing context. It tells you why something was done, not just what was done. Governance adds structure to that story. It helps make sure decisions are made in a consistent, traceable way. Together they provide the framework for better informed decisions, both for humans and for AI. Because if you think about it, AI tries to generate the best possible next word, while every developer tries to find the best possible next solution. Both rely on the quality of the context they have. The clearer that context is, the better the outcomes.
