How to Avoid AI Coding Mistakes on Your Website

The biggest misconception isn't that AI writes broken code. It's almost the opposite. AI is good at writing code that does exactly what you asked. The trouble shows up later, when that code has to live alongside the rest of your site.

It'll solve what you asked it to do very quickly and accurately. But often, what you asked isn't broad enough to cover the whole problem.

Nik runs into the same problem on a mind-numbingly common basis. You make a change, it looks great on your monitor, so you move on, happy with the result and time saved. A week later, you open the same page on your phone to show your business partner why you no longer need a developer, and half of the page is hanging off the edge of the screen because nobody thought to check it on mobile. The code did its job. The job was just defined too narrowly.

Wild expectations make this worse. The news talks about what AI might do in five or ten years, so people assume it can already do more than it can. In our experience, the strong uses today are narrower than the hype suggests. It's good for quick prototyping, testing an idea, getting something to a rough working version so you can see if it's worth pursuing at all. Where it struggles is exactly where experience matters. Thinking ahead. Knowing about everything already running on the site. Being able to custom code a solution that fits your site perfectly, like knowing your site is mostly used on mobile and how to code it in response.

You may have heard the phrase "AI slop", or "code slop". It refers to code that runs, looks fine on the surface, but hides a mess underneath. The core problem is simple. The AI doesn't know the wider system it's writing for, and it will only give you what you ask of it. Limited coding knowledge? Limited output.

Picture an online store. You need a small custom function, like something that pulls data off an order and applies it to a customer's account. You ask the AI, you get a tidy little function, you paste it in, and it works. What you can't see is that your site might already do most of that job somewhere else. The AI had no idea, so it wrote its own version anyway.

Now two pieces of code do the same thing. Everything still works, so nobody notices.

The cost shows up later. A year on, you need another change. Maybe you use AI again, maybe you hire a developer. Whoever opens the code finds two functions that look more or less identical and can't tell which one is really being used. A simple job now takes two, three, four times as long. And the more you add this way, the worse it gets, because each duplicate makes the next change harder. When a real bug turns up (and one will), it's twice as hard to find, because you can't tell which copy it's coming from.

Code slop becomes code soup. The duplicates don't always sit there harmlessly, either. Sometimes they clash, and the duplicate stops working properly. The worst version of this is when it breaks, and nobody catches it at all.

One of the most common mistakes is treating AI like a vending machine. You feed it prompt after prompt, take whatever drops out, paste it onto the site without really knowing what it does. It turns up a lot on sites we inherit from other agencies. Dozens of small AI changes, each one added without anyone knowing what it touched.

Why is that risky, beyond the obvious? Because if you use AI this way, you don't understand the code, and you've got no choice but to trust it. AI is good enough that the output is rarely broken straight out of the box, and it reads cleanly even to a developer. But if you can't read code, you won't spot the problems underneath. The inefficient way it did something. The security check it skipped. The function it copied for no reason.

This happens even to experienced developers. You ask the AI to adjust one function, and the new version also changes something else that was already right. A developer catches it because they read every line. Someone trusting the output blindly never would.

How much any of this matters depends on what you're touching. Change the way a button looks, and the risk is low. Change the way your payment gateway processes a credit card and, well, that's a different conversation entirely.

This excitement is dangerous. If you've never been able to change your own website, getting AI to move a button is a real buzz. That little hit of confidence can build into a habit, where you keep making changes faster than you can really understand them.

We were victims of this even in the WTS office. Given some safe practice sites, people built calculators and tools they'd wanted for years, in maybe ten minutes of prompting. Things that never made financial sense to build from scratch for smaller clients. It was great, and hard not to get swept up in. It was also a reminder of how quickly excitement can outrun caution, which is why a developer checked every one of those experiments before it went anywhere near a live site.

If one word runs through all of this, it's context. So what does the right context look like when you're adding to an existing site?

Give the AI the code that will or might interact with the thing you're building. A clear description of what you want. And, just as important, what you don't want it to touch.

One key to giving good context is understanding the code you're adding to. But the people leaning on AI are usually the ones who don't understand it. That's the whole reason they're using AI. For a developer, AI is a real time saver. For someone using it to avoid the cost of a developer, getting the context right is really hard.

So the natural move is: "if I don't know what to give it, I'll give it everything." And that's its own trap. There's research suggesting that cramming every document and rule into a prompt makes the output worse, not better. Too much context and it doesn't know where to focus. Worse, what it hands back can end up spread across half a dozen files. A developer building a single feature would keep that code in one place, making it easy to find and change later. Flood the AI with context, and you also raise the odds it changes things you never asked it to.

And this doesn't only happen on day one. Without a clear approach, it builds up over time. You keep improving something, keep feeding it more, until it's carrying so much general context that a simple request lands in completely the wrong spot.

The first place AI tends to introduce security holes is authentication. Say you use AI to build a page where a customer checks their order status with a link that holds the order ID. The AI might cover the obvious bases, validating the input and protecting the database from malicious activity. What it tends to miss is the person who edits the link, subtracts one from their order number, and hits enter. Now they're looking at someone else's order. Nothing stops them, because nobody told the AI to stop them.

Most good accessibility isn't hard. You just have to think to do it. So if you're generating everything with AI and you don't ask for it, you usually won't get it.

One example is tabindex, the order in which keyboard users move through a page when they press Tab. Drop an AI-built form into the middle of a page without enough context, and you can end up with a tab order that runs through the header, jumps straight past the form to the footer, and only then loops back. Someone using a screen reader might reach the footer and never even realise the form was there.

Something that looks like it's in the right place, but wasn't built into the page correctly, can also confuse how Google reads it. And increasingly, how tools like ChatGPT and Gemini read it is becoming its own way for people to find you. Building within a mature platform does help, but it depends on which part you're working in. The parts of WordPress or Shopify designed for non-technical users come with a lot of built-in protection: features that prevent you from accidentally breaking your layout or misconfiguring an element. But the moment you go deeper, into the code, into the areas where you might be pasting in AI output, that protection largely disappears. Those parts of the platform just assume you know what you're doing.

Nik admits that AI has got better at this, but it's still working without visibility into what your site already loads, and that's where the trouble starts. Say you ask it to turn a section into a slider. It reaches for a JavaScript slider library and adds a line to load it. What you don't know is that your site may already load that exact library, or a different one doing the same job. Now the page pulls down two libraries to do one thing. Or the same one twice. One instance is relatively harmless. Repeat the pattern across a site, and you've got a page loading far more than it needs, plus the odd clash between the rival libraries.

None of this is new. WordPress users have bolted on plugins for things the builder already did for years. What's new is the speed. AI lets people add weight so gradually that nobody notices the site sliding from fast to sluggish. And on a busy site, small speed losses add up. Slightly less time on the page. Slightly fewer enquiries. Slightly fewer sales. It starts with one slider. Then a font loader, an animation library, a chat widget. Nobody added a slow site. They just each added one small thing.

Then there's scale, which is a slightly different worry. An AI-built product grid might run fine with 20 products and fall over at 300, if it wasn't built to scale. It might load each product one at a time, then fire separate database queries for each product's price and its details, instead of fetching everything in a single trip or using scalable features like pagination. Built that way, it works on launch day but gets slower over time until the page crawls or the server times out and throws an error. AI won't always build for the future. And most people using it won't know to ask it to.

Can AI coding mistakes hurt your SEO? The honest answer is that it touches almost everything, which makes it hard to pin down. But a common example is the page that looks perfect to a person and is a mess to a search engine. On your screen, the important content sits at the top. In the code, the AI may have dropped that content near the bottom, so a crawler reads the page out of order and can't work out what it's even about.

Even asking for "SEO best practices" isn't enough, oddly. You have to give it the page's subject, the product it's about, and the search terms you really want to rank for. There's a duplication trap waiting too. Paste in a nicely optimised product description, complete with its own meta description, onto a site that already builds meta descriptions automatically, and now you've got two. Slightly different, each one working against the other. For someone who doesn't know what a meta description is, that's a very hard thing to diagnose when the page just won't rank.

There's a trend of getting AI to check the changes it just made. Does it work? Somewhat. Not enough for Nik to tell a non-developer to run a self-review and call it done, though. Where it does help is as a sort of brainstorming partner. Ask it, "What might be wrong with this?" and let it point your attention to something useful. It's a way to focus your own judgement faster. It's not a replacement for experience.

So when is it actually safe to use AI on your website? Nik's answer is short: the safe list is pretty short too.

A developer would test every workflow that the new code could affect by going through the site as a customer. But if you don't understand the code, you don't know what it could affect. So to be truly safe, you'd have to test everything, which isn't realistic for most people.

The practical answer is to test what matters most to your business. For a store, after a change that could touch products or checkout, that means doing it for real. Add to cart, remove from cart, change a quantity, reach checkout, place a real order, and check that emails and receipts come through. The list is nearly endless, so just focus on the workflows your business depends on.

People who know how a feature is meant to work test it differently from people who've never seen it, and not always in a good way. If you built it, or you're familiar with the workflow, you'll tend to do it right without thinking, skipping past the moments where a real user might get confused or stuck. So if you can, get someone unfamiliar with it to run through it too. They'll find things you won't.

If your website is critical to your business, having an agency look over a few changes is a sensible bit of insurance. It usually won't cost a fortune. Unless what they find is a disaster, but let's not assume that. The key is the brief.

The TL;DR version of all the information provided above comes down to a single idea. AI can't replace your critical thinking.

It can be completely confident and completely wrong at the same time, and that mix is the dangerous part if you don't know enough to push back. There's a video doing the rounds where someone asks an AI which month has the letter X in it. December, it says. Asked to spell December, it does. No X. Oh, October then. Spells October. Still no X. Round and round it goes, every wrong answer delivered with total confidence. If you couldn't spell December or October, you'd just believe it.