Is AI-written code safe? What we put around it before it ships

If you own a Drupal site, you have probably reached the point where the agency invoice feels heavy and the idea of moving feels heavier. The site works. The team knows it well, and there is real comfort in that. Switching seems like the kind of decision that goes wrong in ways you only discover months later, so staying put feels like the safer choice.

Then you hear about teams that deliver the same Drupal work faster because they use AI, often for materially less, and a different feeling shows up. Not relief. A small alarm, somewhere in the back of your mind.

It is a reasonable alarm, and it usually arrives as one fair question. Is that safe for my site?

You have seen the demos where a tool writes a whole feature in seconds, and your first thought was not "amazing", it was "who checked that?" Maybe you have inherited a codebase someone rushed out once before, and you remember exactly how that ended. So when a new supplier tells you they are quicker now because of AI, you hear the speed and you immediately wonder what got skipped to get there.

That instinct is correct, and we are not going to talk you out of it. AI-written code can be risky. That is true.

But the useful question is narrower than "should anyone use AI". That ship has sailed for serious teams, the same way version control and automated testing eventually stopped being optional. If you are weighing a move, the question that actually protects your site is this: what does a supplier put around AI-generated code before any of it reaches your live environment?

That is the difference between a switch that pays off and one you regret, and it is the part we want to walk you through.

What actually goes wrong with AI code

When AI delivery goes badly, it is tempting to blame the AI. In our experience that is almost never the real story.

The teams getting burned are not the ones who used AI. They are the ones who quietly removed their own safety checks to make the AI look faster. The code review that used to catch the bad patch gets skipped because "the AI is usually right". The test suite that used to fail loudly gets ignored because someone is in a hurry. The careful deployment process gets shortcut because the demo looked clean.

In other words, the failure mode is not new. It is the oldest one in software: going fast by taking the guardrails off. AI just makes it easier to do at scale, because it produces plausible-looking code so quickly that it is genuinely tempting to wave it through.

So the honest version of "is AI code safe" is this. AI code is exactly as safe as the process you run it through. Pointed at a disciplined process, it is fine. Pointed at a process where the checks have been removed to chase speed, it is a liability, and it would have been a liability with a careless human writing the same code by hand.

That reframing matters, because it tells you what to actually ask the team you are considering. Not "do you use AI", but what did you keep when you started using it.

What we wrap around it before it ships

When we rebuilt our delivery process to use AI, we did not loosen anything. We added.

Here is what that looks like in practice. Every change, whether a person or an AI produced the first draft, goes through human review before it is allowed anywhere near your site. A senior set of eyes reads it, understands it, and is accountable for it. AI does not get a pass that a junior developer would never get. If anything we read AI-drafted code more carefully, because we know it can be confidently wrong.

Every change is also covered by automated tests, and those tests run on every build. Then there is a continuous integration gate, a pipeline that has to go green before anything can be released. Tests pass, standards pass, the build is sound, or it does not ship. There is no manual override where a person decides the rules do not apply today.

The tooling that runs all of this is our own. We built the harnesses and guardrails that wrap our AI-assisted work, and they are open source, so this is not a claim you have to take on trust. Vortex, our open-source Drupal project template with continuous integration built in, has been maintained in the open since 2018. Our own website is open source. We maintain an ecosystem of open-source packages in public. You can read the actual scaffolding our process runs on before you hire us, which is not something most suppliers can offer about their internal quality controls.

The shape of the point is simple. AI changed how quickly the first draft of the code gets written. It did not change a single one of the checks that draft has to survive. That is also why the saving is real rather than a corner cut: fewer hours on the development work, not fewer checks on the result.

What happens to your code and your data

There is a second worry underneath the first one, and it is just as fair, especially when the site in question is already live and earning. If a supplier is using AI tools, where is your code going while they work?

This is where a lot of the genuine risk actually lives, and it deserves a straight answer rather than reassuring noise.

The question we hear most often is the sharpest one: is your code used to train AI models? No. Your code is never used to train AI models. We use these tools with that switched off, and we keep it that way on every project.

Our rules here are written down and public. Your code is never sent to a public AI service without your permission. All AI output is reviewed by us before it is used. We do not take access to your repositories without your approval. None of that is improvised per project or left to an individual's judgement in the moment. It is policy, and you can read it in full in our Responsible AI policy before you decide anything.

We would rather you read that page and ask hard questions about it than take our word for it. A team that can tell you exactly how your data is handled when AI is in the loop is one that has thought it through, and that is worth looking for, whether it is your current team or one you are considering.

Why we proved it on ourselves first

It would have been easy to read the room, announce that we do AI-assisted delivery now, and start applying it to client work on day one. A lot of suppliers did roughly that.

We did not, for a simple reason. We were not going to learn what could go wrong using your project as the experiment.

So we put the process through our own products first, in public, where the only code at risk was ours and the only deadline we could blow was our own. We built the tooling and the safeguards ourselves and proved them on our own work since 2018. We watched where AI helped, where it produced something that looked right and was not, and where our existing checks caught the difference. We tuned the guardrails until the process was boring in the best way, predictable and repeatable. Only then did we bring it to real client work.

That instinct comes from where we have worked. We were engaged as the architect and lead developer of CivicTheme, the design system used widely across Australian government, and we have delivered Drupal and GovCMS platforms under the scrutiny government work brings, where the bar for security and accountability is set by other people and is not negotiable. That background is why, with anything new, we prove it in a controlled setting before it touches work that matters to someone else. AI did not change that habit. It is exactly the kind of thing the habit exists for.

It is also the reassurance we would want if we were the ones handing over a working site. You are not betting your platform on a tool we are still figuring out. You are inheriting a process we already wore in on our own products first.

The one line worth remembering

If you take a single idea from this, let it be this one. AI speeds up the writing. It never speeds up the checking.

Every change still gets reviewed. Every build still gets tested. Nothing ships until continuous integration says it can. The work that proves your site is safe to release happens at exactly the same care and rigour it always did. What moved is how fast the first draft appears, and on the kinds of work that suit it, that can mean fewer hours on the build for you. The verification did not move at all.

So your original instinct was right, and you should keep it. AI-written code can be risky. The thing that makes it safe is not the AI getting cleverer. It is the process you put around it, and the willingness to add guardrails rather than remove them.