I have designed and built websites for more than 25 years. Over the past weeks I have been moving the client sites I look after onto a new way of working: AI coding agents do the legwork, I make the decisions, and you approve each change before it goes live. This post explains what that workflow is, what it runs on, how long it takes to bring a site onto it, how the client portal works, and why I think it changes what a small business can expect from its website.
What “agentic” means here
An AI coding agent is not a chatbot writing a paragraph for you. It works inside a project: it reads a site’s code and database, runs commands, crawls pages, drafts a fix, tests it, and writes down what it did. Mine work in the terminal on my workstation, on a copy of your site, under my direction. They do not publish to your live website; I run every live update myself, and only after you have approved it.
The workflow, step by step
- A private working copy. Your site is copied to my workstation and runs in its own container, with the same PHP and database versions as your host. Live passwords and API keys are removed from the copy before any work starts, outgoing email is caught locally so no customer gets a test message, and scheduled tasks are switched off.
- A full check. The agent crawls the whole site (status codes, broken links, missing images, headings, structured data) and reads the code and the database to find what is wrong or out of date.
- Small, documented changes. Each fix is a short script. It checks that the page is in the state it expects, makes the change, keeps the old content so it can be restored, and does nothing if it runs a second time.
- Tested twice before you see it. Changes are checked on my copy, then put on a private review copy of your site on your own hosting, hidden from search engines, where the same checks run again. For bigger releases I rehearse the whole set on a fresh copy of the live database first.
- You approve in the portal. Every change is listed with before-and-after screenshots and its price. You decide item by item.
- Published with a backup. Only the approved items go live. The database is backed up first, and the publishing script checks the result on the live site straight afterwards.
- A written record. Every change is recorded in the site’s history: what changed, why, and when.
The tech stack
Nothing here is exotic, and every piece can be replaced. The tool matters less than the workflow around it.
- Claude Code (Anthropic) is the main coding agent. OpenAI Codex works as a second reviewer: it reads the live site and suggests what to improve next, and I decide what goes on the list.
- A Linux workstation with Docker and DDEV. Each client site runs locally in its own containers, matched to its host.
- WordPress and WP-CLI, so database changes are made by script instead of by clicking through the admin.
- Git keeps a history for every site. It stays on my machine and is never uploaded to your server.
- rsync over SSH (or SFTP where the host only allows that) for files. Every deploy is a dry run first, and the script refuses to write unless the destination is the site it expects.
- Mailpit catches every email the working copy tries to send.
- A small crawler and headless Chromium for page checks and before-and-after screenshots.
- The client portal, a small PHP app on your review site.
The client portal
The portal is where you see and approve changes. It is a password-protected page on your review site, not on your live website, and search engines do not index it. You get a login once; the password is stored only in scrambled (hashed) form.
Each release is a short list of changes. For every item you see what changes, why, which pages it affects, before-and-after screenshots, and the price, or “included” if it is part of your plan, before you decide. A running total shows what you have approved this month and this year. Each item has three buttons:
- Publish live: go ahead with this change.
- Do not publish: leave it out.
- I need more information: ask a question; I answer in the portal.
Items are independent, so you can approve three and hold one. When you decide, I get an email. Nothing runs by itself: I collect the decisions, and only the approved items go live. The price you saw when you approved is the price on the invoice, one line per item. No more email threads about which version of a page you meant; there is one list, and a record of every decision.
How long onboarding takes
For a WordPress site on a host with SSH access, bringing it onto this workflow usually takes about one working day. Two recent examples:
- This website. The copy was pulled, checked, and the first fixes were live the same day, with a full crawl and a backup.
- A client site. Set up one afternoon; its first repairs were live the next day. That evening the client approved a second release in the portal, and it was live the same night.
Onboarding covers registering the site, copying its files and database, removing live credentials from the copy, scanning for anything else that should not run locally, setting up the private review copy on your hosting, and creating your portal login. It takes longer when a host only offers FTP, when the database has to be exported by hand, when a review address needs a DNS change, or when the media library is very large.
Why this helps your website and your business
- More of your site gets checked, more often. A crawl looks at every page in the sitemap, not a sample, so a broken form or a missing image is much more likely to be found before a customer runs into it.
- Fewer surprises. Changes are tested on copies first, a backup is taken before publishing, and changes can be rolled back.
- No surprise invoices. You see the change, the screenshots and the price before you approve.
- Improvements ship when they are ready. Small approved releases go live in days instead of waiting for the next redesign.
- The time saved goes into your project. Less time on repetitive checking means more on strategy, content and design decisions.
- You own everything. Code, content and designs are yours, and there is a written record of what was done.
I ran the whole process on this site first; the results are in the site audit case study.
How this will reshape design and development
These are my predictions, based on working this way every day:
- From projects to continuous improvement. Instead of a redesign every few years and little in between, sites will improve in small, approved steps all year.
- Review becomes the core skill. Writing code is getting cheap. Deciding what should change, checking that it is right, and taking responsibility for it is not.
- Designers spend more time on judgment. Messaging, brand and the visitor’s experience get more attention when agents handle the repetitive checks and variations.
- Clients get closer to the work. Approving individual changes with screenshots replaces signing off a whole project and hoping.
- Guardrails matter more than tools. Review copies, backups, removing credentials and approval steps are what make AI speed safe. Speed without review is just faster mistakes.
- Small businesses get what used to need a big budget. Full-site checks, written records and staged releases no longer require an agency team.
What stays the same
You work with one person who is responsible for the result: me. Nothing goes live without your approval, and you own your site. Read how I use AI for the rules I work by, or see AI-assisted web development.
Want your site on this workflow? Start with a website audit, keep it healthy with Site Care, or request a free estimate.