If your organisation has an AI policy for software development, you already know the tension. AI coding tools have become genuinely useful. At the same time, there are real concerns about data privacy, intellectual property, and compliance that make blanket adoption hard to justify. In government and enterprise especially, where the stakes are higher and the approval processes slower, "let's just use it" was never going to be the answer.
Most of the conversation about that tension is about what gets lost. The productivity left on the table. The efficiency teams can't quite reach. The gap between what the tools could do and what the rules currently allow.
But there's something else happening, and it gets almost no airtime. These restrictions are producing an unexpected side effect, and it's one that quietly benefits the entire software community.
They're growing open source.
What happens when you can't use AI on client code
To see why, it helps to watch what a developer actually does when they hit an AI restriction mid-project.
The scenario looks like this. You're working on a government or enterprise codebase. The policy says no AI-generated code. Or the approval process for AI tools hasn't been set up yet. Or the rules are vague enough that nobody wants to be the first to test where the line sits. The specifics vary; the effect is identical. You can't point an AI assistant at the client's code.
But you still have problems to solve. And here's the thing: a lot of those problems have nothing to do with this client at all. They're generic. The kind of logic that could live in any project, with no connection to client data or sensitive business rules.
So what do you do with the generic part? You pull it out.
You build it as a standalone, open source module. No client data, no sensitive IP, nothing that falls under the restriction. Then you write a thin integration layer inside the client project: configuration, data mapping, the parts that are genuinely specific to their setup. That layer is small enough to write by hand, no AI assistance required.
We've done exactly this across multiple government projects. The pattern itself isn't new. We've been extracting generic modules for years, long before AI was part of the conversation. Projects like Drupal Helpers(Opens in a new tab/window), Integration Report(Opens in a new tab/window), and Generated Content(Opens in a new tab/window) all came out of this approach. What's changed is the frequency. When an AI restriction is in force, extraction stops being the thing you'll get to eventually. It becomes the path of least resistance.
A different dynamic from what we wrote about before
We wrote recently about how AI is affecting contributions to existing open source projects, and that picture isn't a happy one. Developers hit a bug, ask AI for a workaround, and move on without ever reporting it. Maintainers see fewer quality contributions and more AI-generated pull requests that pile up as review burden. The commons gets consumed faster than it gets maintained.
That concern still stands. What we're describing here runs alongside it, and it points the other way.
This isn't about more people contributing to projects that already exist. It's about more people creating new ones. The extraction pattern, pulling generic logic out of private codebases and releasing it as something reusable, is accelerating wherever AI restrictions apply. Not because developers suddenly discovered a love of open source philosophy. Because the restriction made extraction the most practical way to keep working.
The irony is worth sitting with. A policy designed to limit AI's influence on a codebase is producing more open source code than years of "you should really contribute that back" ever managed.
Once the code is in the open, AI helps it get better faster
There's a second-order effect that makes this more interesting still.
Once you've moved a module into the open source space, where there's no client data, no sensitive IP, and no policy restriction, you can use AI tools on it freely. Refactoring a function to be more configurable. Generating test coverage for the edge cases. Writing the documentation that explains what it does and why. These are exactly the tasks AI is good at, precisely because you already understand what the code should do and can check the output against that understanding.
This matters more than it first appears, because the extraction step is historically where most reusable code went to die.
Teams would agree that something ought to be open sourced. Then the effort of refactoring it, documenting it, and adding tests would keep it on the backlog forever. AI collapses that cost. "We don't have time to open source this" stops being true when the tedious part of the job takes an afternoon instead of a week.
There's a condition attached, though, and it isn't optional. This only works if you have quality checks in place: automated testing, coding standards enforcement, CI that runs on every commit. AI-assisted development without those guardrails is just faster bad code. The speed only becomes an advantage when there's something there to catch the mistakes that speed inevitably introduces.
Are we even asking the right policy questions?
This is where it gets more nuanced, and where we think the conversation needs to shift.
Most AI policies in government and enterprise fixate on which tool generated the code. Was it an approved AI system or an unapproved one? Did the developer use a personal subscription or a corporate-sanctioned tool? On the surface these feel like sensible questions. We're not sure they're the useful ones.
Consider what the actual quality gate has always been: the person who reviews the code and accepts it. That was true when developers wrote everything by hand. It was true when they were copying patterns off Stack Overflow. It's still true now. A developer who took shortcuts and didn't really understand what they pasted in 2019 will take the same shortcuts with AI-generated code in 2026. A disciplined engineer who wrote clean, well-tested, architecturally sound code before any of this existed will hold that standard whatever tools they reach for.
The question "did AI generate this code?" assumes the generation method is the variable that matters. But if the code passes review, has test coverage, follows the project's conventions, and works correctly, does it matter how it was produced? And if it fails those checks, the generation method still isn't the problem. The review process is.
There's an uncomfortable truth underneath all of this that most people in the policy conversation aren't saying out loud. There is no reliable way to detect well-written AI-generated code. These policies are trust-based agreements between organisations and their development teams, not technical controls with enforcement behind them. Which means they rest on the same foundation software quality has always rested on: trusting that your engineers are doing careful, considered work, and having the automated checks in place to catch it when they aren't.
The source code question is a different question
One concern often gets folded into "who wrote the code" when it really deserves its own analysis: the risk of exposing client source code to AI tools.
That's a legitimate concern. It's also a different one, and bundling it into the same policy muddies both.
For a platform like Drupal, where the overwhelming majority of the codebase is open source anyway, core, contributed modules, the theme layer, the risk profile of "exposing the codebase to AI" is not what people often assume. What's actually sensitive in most projects isn't the code. It's the configuration: API keys, environment variables, service credentials. And none of that should be sitting in the codebase in the first place, AI or no AI. That's a configuration management discipline, not an AI policy question.
We take this seriously enough to have published a responsible AI policy covering how we use AI in our work, what gets exposed to external services and what doesn't. Not because a client asked us to, but because operating in the open is how you build the kind of trust that makes these conversations productive instead of adversarial.
Questions worth asking out loud
We're not going to pretend we have this solved. The intersection of AI policy and software development is genuinely new ground, and the organisations working through it are dealing with real constraints: legal, regulatory, cultural.
But some questions deserve to be asked more directly than they currently are. When will AI approval processes be standard enough that today's blanket restrictions can evolve into something more precise? What's the actual risk difference between a developer using a personal AI tool and a corporate-sanctioned one, if both produce code that goes through the same review? Is there a workable middle ground between "no AI anywhere" and "AI everywhere with no guardrails" that an organisation can adopt without years of committee deliberation?
We don't have the answers. But we're convinced the conversation needs to move away from "which tool generated this line of code" and toward "what checks are in place to ensure quality, regardless of how the code was produced." Automated tests. Coding standards. Peer review by engineers who understand the architecture. CI on every commit. Those have always been the things that actually protect a codebase. They still are.
What this means for the ecosystem
While organisations work through the policy questions, something is quietly shifting in the open source landscape.
More generic code is being extracted into reusable modules. More logic is moving out of private repositories and into the public commons. The pattern of thin customisation, where the client-specific work shrinks down to configuration, integration, and the genuinely unique parts, is becoming the default approach rather than an architectural aspiration that never quite happens.
That's good for everyone who builds on open source platforms. Organisations adopting these modules get more capability for free. Maintainers of generic tools see broader adoption, and sometimes contributions back. New projects enter the ecosystem that might never have been extracted at all without the pressure of a restriction forcing the split between what's generic and what's sensitive.
We wrote in the previous piece that AI makes a lot of things faster, but it hasn't made caring easier. That's still true. And yet something interesting is happening next to it. Restrictions designed to slow AI down are pushing code into the open. Not because anyone planned it. Not as part of some grand open source strategy. Because when you tell developers they can't use their most productive tools on private code, they find ways to make more of their code not private.
And the ecosystem is better for it.
We maintain around 40 open-source repositories, including Vortex(Opens in a new tab/window), a Drupal project template built to production standards. If you want to talk about open source, AI policy, or how we approach responsible AI in our work, we're always open to that conversation.