How we use AI to build, secure and grow websites
AI is part of how we work every day now. It writes first drafts of plugin code, reads server logs faster than any of us can, and turns a spreadsheet of broken URLs into a redirect plan in minutes. It also makes things up, misses context, and would happily run a command on a live site if you let it.
So when clients ask whether we use AI, the honest answer is yes, a lot, with a person in charge of every step. This post is the long version: what we use it for, what that looks like day to day, and the rules we don’t bend.
The short version
- AI drafts, people decide. Nothing it produces reaches a live site until a person has read it, tested it and signed it off.
- Your secrets stay out of it. Passwords, API keys and your customers’ data never go into a prompt.
- It takes the tedious work. That leaves more of our time for the problems that need experience and judgment.
An extra pair of hands for code
Most of our building now happens with an AI coding agent in the terminal. We use Claude Code. It can read a whole theme or plugin, propose a plan and make changes across several files at once, which suits WordPress, where one feature is usually spread across templates, blocks, styles and functions.php.
What comes back depends almost entirely on the brief, so we write them carefully. A typical one:
Task: Add a "Team" block to the theme.
Context: Block theme in wp-content/themes/client. Blocks live in /blocks
and are registered in functions.php.
Match: The card style used by blocks/services.
Fields: Name, role, photo, short bio.
Done when: It appears in the inserter, renders on the front end
and passes phpcs.
Don't: Add dependencies or change any other block.The agent reads the relevant files, says what it plans to do, does it, and then stops. We review the change line by line, run the coding-standards checks, try it on a staging copy of the site, and only then commit it to Git and deploy.
This website was built the same way. An AI agent wrote it from our design notes, and we checked every page in a browser on a desktop and a phone, in light and dark mode. That check caught two bugs the agent had introduced: an invisible chat panel that blocked clicks in the corner of every page, and illustrations cut off at half their height on the case-study pages. Neither would have been obvious from reading the code alone. That, in one example, is why review isn’t optional.
Reading code nobody documented
A lot of our work starts with a site someone else built: a theme with a functions.php thousands of lines long, dozens of plugins, and no notes. Getting oriented used to take days of reading.
Now the agent does the first pass. We ask it to map where each hook is registered, which plugins touch checkout or the login page, what runs on every page load, and which code looks unused. It’s a fast, thorough first read, but it’s still a first read. A confident summary of a codebase isn’t the same as an accurate one, so we confirm anything we act on by reading the code ourselves and testing on staging.
Root causes, faster
Debugging is where AI saves the most time and needs the most supervision. It’s very good at the tedious part: reading a two-thousand-line error log, spotting the one pattern that keeps repeating, and turning a stack trace into a shortlist of likely causes.
Take a typical case: a WooCommerce admin that takes several seconds to load every screen. We give the agent the slow-query log, with anything personal stripped out. It notices the same wp_options query at the top of every request, pulling in megabytes of autoloaded settings left behind by plugins that were removed years ago. That’s a hypothesis, not a fix. We measure it, clean up the orphaned options on staging, measure again, and only then make the change on the live site.
What AI can’t do is know your site. It doesn’t know that the “unused” plugin is the one your accountant logs into once a quarter. That’s why a person makes every call.
Security work
When we clean up a hacked site, we often find code built not to be read: layers of base64 and compression wrapped around a few lines that do something nasty. AI is excellent at unpicking these and explaining in plain English what the payload does. That tells us what else to look for, such as a hidden admin user, a modified core file, or a scheduled task that reinstalls the malware after it’s removed.
It helps with the checks around that too, like turning the output of WordPress’s own integrity checks into a list of files to inspect, or drafting firewall and server rules that we then test.
wp core verify-checksums
wp plugin verify-checksums --allThis is also where our rules are strictest. AI tools never get production credentials or access to a live server. Logs are redacted before they’re shared. And during an incident, the decisions (what to take offline, what to restore, what to tell your customers) are made by a person.
The checklist we follow: hardening WordPress in an afternoonTechnical SEO at scale
SEO involves a lot of data that’s too big to read line by line and too messy for a simple spreadsheet formula. After a migration, Search Console might report hundreds of URLs returning 404. AI is good at grouping them into patterns (old AMP pages, an archived category, a shop that moved) and drafting a redirect rule for each one.
We don’t trust the draft. Every rule is tested against the real URLs with a crawler before it ships, so that each old address lands on the right page in a single hop.
We use it the same way in our technical SEO audits: for structured data, where it drafts the JSON-LD and we check it with Google’s Rich Results Test, and for titles and meta descriptions across hundreds of pages, where it suggests and an editor approves or rewrites each one. It also helps us work through exports from Search Console and Ahrefs faster, though the conclusions are ours.
What a technical SEO audit actually checksWords, in a person’s voice
We write a lot besides code: monthly care reports, handover notes, help pages for editors, and write-ups of what went wrong and what we did about it. AI gives us a quick first draft and helps turn technical detail into plain English. It’s also useful for alt-text suggestions and tidying imported content. Then we rewrite it in our own words, because a report you can’t trust isn’t worth sending.
On client sites, we never publish AI-written content without a person editing it, and we follow each publisher’s own policy on AI. If AI helped draft something you’re going to publish, we tell you.
The rules we don’t bend
- A person reviews every line. We treat AI output like a pull request from a new colleague: often good, never merged unread.
- Staging first. Nothing an AI suggested runs on a live site until it has run on a copy.
- No secrets in prompts. Passwords, API keys, database dumps and customer data stay out, and logs are redacted before they’re shared.
- No production access. AI tools work on local copies and staging sites. Deployments go through Git and a person.
- Check the facts. AI invents function names, hooks and settings with complete confidence. We check the documentation and run the code.
- Say so. If AI helped with something you’ll publish, you’ll know.
Where we don’t use it
- Deciding what to do during a security incident
- Anything that needs a password, a key or access to a live server
- Publishing content or messaging your customers without a person in between
- Replacing testing. AI can write tests, but it can’t be the test.
What it changes for you
Routine work gets done faster: a new block, a redirect plan, a first read of an inherited codebase. That frees more of our time for the work that needs experience, like finding out why a site is slow, what an attacker changed, or which fix will actually move your rankings. Tests are cheaper to write, so we write more of them.
What doesn’t change is who’s responsible. If something we ship breaks, that’s on us, whoever or whatever typed it first.