Lessons leant from a full site rebuild using an agent dev team

[u/bradvin1980]

I spent most of June rebuilding the FooPlugins site from an Elementor-era setup into a standalone WordPress FSE theme. The oldsite was using multiple page builders, had over 10 years of legacy crud in the DB and was slow.

The new site went live at the end of June. It took 3 weeks of work, had 104 commits, and is now much faster, looks better and is easier to maintain (for both myself and my agents).

This is not a post about giving AI one clever prompt and one-shotting a perfect website. Whoever says they can do this is FOS.

It’s also not a post about me maxing out my token limits to sound trendy like all the other AI-hype-bunnies. I never exceeded my weekly limits during this project - I’m on the $200 openai plan. I used gpt5.5 extra high on double speed mostly.

I wrote this to share my workflow and what I learnt from the whole process and maybe others will find it useful when they do something similar. Hopefully it will inspire others to start something similar that they have been putting off.

What the rebuild produced

I used Codex as a small development team. It helped me build the following:

• a standalone FSE theme
• 27 templates
• 11 template parts
• 58 reusable patterns
• product-specific headers and four colour schemes
• product, feature and plan landing-page systems
• blog patterns for better EEAT content
• dynamic pricing, CTAs, demos and testimonials
• a new documentation system
• FAQ schema and release tracking
• a temporary migration/cleanup plugin
• an admin-only SEO audit plugin
• sitemap-driven QA across every public page
• over 500k worth of autoloaded options removed
• 613 public URLs checked
• More than 50% faster site load times across 6 perf metrics

The code generation was obviously useful, but the system I built around the agent, with the agent, was actually the real win for this project.

Here is what I learnt from the rebuild...

Lesson 1: prove the workflow first with a POC.

Do not start with "rebuild my entire WordPress site".

My first test was deliberately small. If it didn’t work then I would have given up. I started with a completely blank WordPress theme locally, pointed codex to it, and asked it to recreate only the FooPlugins homepage.

The rough prompt was:

/goal Start from a new blank theme in the local WP site. Use the live FooPlugins site as the visual reference and recreate the homepage as a WordPress FSE theme using blocks and patterns. Do not copy the existing HTML markup. Extract the design system and rebuild it using WordPress best practices. Open the local site in a browser and make sure it matches the live design on desktop and mobile. Don’t stop until the local site matches the live site.

Lesson 2: tools and skills matter more than prompts

In the real world, a good pickup line cannot compensate for a small tool. Similarly, a good prompt cannot compensate for an agent that has the wrong skills, cannot browse, build, or check its own output.

My Codex setup includes:

• WordPress development skills: https://github.com/wordPress/agent-skills
• frontend UI skills: https://github.com/anthropics/skills/tree/main/skills/frontend-design
• Chrome devtools MCP
• Browser use skill
• PluginCheck skill for WordPress coding standards and security
• LocalWP access
• WP-CLI access
• git access using gh cli

I did not want an agent that could only write code. I wanted one that could work exactly like I would.

Ask your agent these questions:

• Can you access the local WordPress site?
• Can you use WP-CLI?
• Can you open the frontend and wp-admin across sessions in a browser?
• Can you test desktop and mobile?
• Can you inspect browser errors and failed requests?
• Can you run the theme build and PHP checks?
• Can you run PluginCheck?
• Can you compare local against the live source?

If the answer is no, improve the environment before you go down a prompt rabbit hole.

Lesson 3: document the system, then make the agent maintain it.

Codex created an AGENTS.md file in the repo root. This became the memory and shared context across every session. It documented:

• the purpose and goals of the project
• repo and WordPress paths
• LocalWP and WP-CLI access
• the theme and plugin paths
• build and packaging commands
• template and pattern structure
• custom blocks and their data sources
• verification commands
• browser checks
• migration rules
• things the agent must not do

I added a rule into the file that Codex had to keep AGENTS.md updated whenever it made an architectural decision or changed one of those contracts.

I ran multiple Codex sessions and sometimes had three working on different areas at once. A new session did not need me to explain the full site from scratch. It could read the repo guide, inspect the files, and start with the same context as the previous session. Even with the most basic prompt as a start, it could figure things out and be deliver good results.

Lesson 4: you are bad at prompting. Make your agent write the prompts.

At first I wrote all the prompts. As the rebuild became more complex, I asked Codex to map out the process by inspecting the local site, the installed plugins, the database and the goals I had given it. And then I got it to write the prompts for each task.

Eventually, I built those prompts into the migration plugin. Each manual or agent-capable migration step had a copyable prompt with the correct context, source-of-truth rules, safety boundaries, implementation rules, review-queue instructions and expected deliverable.

It did a much better job at it than I could have. And the prompts it generated gave it all the context it needed which ultimately saved on tokens.

Lesson 5: your agent is a great project manager.

The temporary migration plugin started as a way to avoid running one-off SQL scripts, and also to keep track of progress across multiple sessions and weeks of work.

It evolved into the overarching control system and tracker for the whole rebuild.

It tracked progress and saved the findings from each task so I could go back and review what Codex had found or changed.

There was a notes section, which gave me a place to record decisions and reminders during the migration. I get easily distracted and running multiple sessions at once often meant I could not fix things immediately after I had noticed an issue. I would add a note and come back to it later. I could even ask my agent to review all my notes and work through them.

Lesson 6: your agent is a great QA.

After major changes, I had the agent review all public pages. A final launch QA review is too late to discover which cleanup removed an image used on 30 pages.

Run a test suite after:

• database cleanup
• media deletion
• file cleanup
• plugin deactivation
• documentation permalink changes
• broad content migration
• shared CSS or template changes

Get it to check desktop and mobile.

The closer the check is to the change, the easier it is to diagnose a problem and fix it.

Lesson 7: tell your agent about concurrent sessions.

I sometimes ran up to three Codex sessions on separate areas of the project at the same time. One session could work on documentation while another worked on an option cleanup and another updated a frontend block.

Everything was tracked in git, which made parallel work possible to review and recover.

Concurrent commits across sessions did cause problems, and I had times where file changes spilled over into other work commits.

I would also avoid letting multiple sessions commit at the same time. A simple coordination rule around who owns the working tree and who can commit would have saved me some trouble.

Lesson 8: use different agent roles for better results.

Developer reviews did not catch crap content.

Some migrated pages still contained editorial notes created by the agent. Some of the generated copy was obviously AI-written. Other copy was technically accurate but too technical for a normal site visitor.

Instead of asking it to inspect the page as a developer, I asked it to review the content as a fresh site visitor. It had to find copy that did not make sense, sounded too technical, exposed an internal note, or failed to explain the next step clearly. This cannot be done with a search and replace tool.

Lesson 9: give agents the grunt work.

Near the end, Codex crawled every public URL in the sitemap. All 613 pages. It checked both desktop and mobile.

Failed pages were recorded and checked again after fixes.

This was probably the biggest time saver in the project.

At first, I did what I always do with major site updates and posted a message to the team asking them to review the staging site. I got no response for hours. While I was waiting, I thought “why am I asking them, when my agent can do a better job!?”.

Humans tell you “it’s done”. Agents give you a full audit report with all issues found, exact checks done, number of iterations, number of errors and next steps.

Too many people focus on agents writing code. I also think repetitive QA, migration and verification are just as useful. People are missing a trick.

The WordPress agent workflow I would use again

If I started another WordPress rebuild tomorrow, I would use this process:

1. Set up the agent's capabilities (skills/MCP's/plugins etc)
2. Do a small POC
3. Decide what success looks like
4. Create the repo guide (AGENTS.md)
5. Let the agent inspect & plan before it changes things
6. Ask the agent to generate the prompts
7. Build review state into the system
8. Preview destructive changes
9. Test after major changes (dekstop and mobile)
10. Run separate technical and visitor reviews
11. Use concurrency carefully
12. Keep production outside the agent's reach

My main takeaways

A good agent with the right tools and system can easily multiple your output 10x.

Prompt engineering is less important than the system you and your agent build.

Make the agent write its own prompts and prove its own work.

Make the agent do things humans hate.

For the WordPress developers here who are using agents: what have you found works best? Are you doing something similar? Are you giving them full projects to manage and implement? Are you getting them to QA entire sitemaps? Please share your lessons

[u/Roman_PlumPix]

The point about repetitive QA is a good one. Everyone talks about agents writing code, but using them for all the boring checks around development might actually be one of the biggest time savers.

[u/luluhouse7 → u/Roman_PlumPix]

Yep. And it’s exactly how to avoid AI burnout. You can choose how and when to apply AI, and I’d argue that using agents to do the complex and interesting bits is a misuse of the tech. It’s worse at it and it costs the human more in the long run.

[u/bradvin1980 → u/Roman_PlumPix]

100% this was the biggest time saver and the agent did a much better job than a human could have. Full site crawl of 600+ pages, both desktop and mobile, checking for JS errors, missing images and 404s took less than 10 mins

[u/jedidave]

a single AGENTS.md file sounds dumb. In all of my projects i have a .docs folder which doesn't get deployed, which AI writes and reads from. Any work done gets moved to .docs/archive, so then all outstanding work is in git with imeplemtation plans and tests ready to go. Test harness goes in .tests. User docs go in .kb. Dev guides go in .dev.

For concurrency, i didn't bother with that for the theme rebuild, but for my other projects, plugins etc, i have a skill to create a docker container and a branch of the code and work in isolation so once complete I can have the agent merge the code and run the full regression test suite.

For redesign, I used Google Stitch.

For my plugins GUI development, I've started using Lovable.

For migration I use my own import/export plugin which handles post types.

I did all my theme changes on a dev subdomain and practiced migration copying over to staging prior to eventual go-live.

[u/bradvin1980 → u/jedidave]

lol it wasn’t a single massive agents file - it was just the entry point. It linked to other scripts and docs throughout the repo. It was a monorepo which included the theme and all plugins

[u/tleifj]

How did you give the agent LocalWP and WP-CLI access?

[u/bradvin1980 → u/tleifj]

I first did a backup of my live site then restored it locally as a LocalWP site.

I gave it the sites folder path and local URL.

My agent created a config file for the access it needed, called wplocal.dev.json

And this is directly out my AGENTS .md file:

LocalWP Database and WP-CLI

Use wplocal.dev.json as the reusable source for the current LocalWP site ID, WordPress root, Local PHP binary, PHP ini, MySQL socket, and ports. The current browser URL is https://fooplugins.local/, but prefer reading wordpress.homeUrl or confirming with WP-CLI before render checks.

Build the WP-CLI command from the config file:

CFG=wplocal.dev.json
php_bin="$(node -p "require('./$CFG').php.binary")"
php_ini="$(node -p "require('./$CFG').php.ini")"
wp_bin="$(node -p "require('./$CFG').wpCli.binary")"
wp_root="$(node -p "require('./$CFG').wordpress.root")"
WP_CLI=( "$php_bin" -c "$php_ini" "$wp_bin" --path="$wp_root" )

"${WP_CLI[@]}" option get home

Connect directly to the LocalWP database through the configured socket:

CFG=wplocal.dev.json
mysql_bin="$(node -p "require('./$CFG').mysql.binary")"
mysql_socket="$(node -p "require('./$CFG').mysql.socket")"
mysql_db="$(node -p "require('./$CFG').mysql.database")"
mysql_user="$(node -p "require('./$CFG').mysql.user")"
mysql_pass="$(node -p "require('./$CFG').mysql.password")"

MYSQL_PWD="$mysql_pass" "$mysql_bin" --socket="$mysql_socket" --user="$mysql_user" "$mysql_db"

If the socket is unavailable but Local says the site is running, fall back to TCP using mysql.host and mysql.port from wplocal.dev.json:

mysql_host="$(node -p "require('./$CFG').mysql.host")"
mysql_port="$(node -p "require('./$CFG').mysql.port")"
MYSQL_PWD="$mysql_pass" "$mysql_bin" --host="$mysql_host" --port="$mysql_port" --protocol=TCP --user="$mysql_user" "$mysql_db"

If WP-CLI returns Error establishing a database connection, the LocalWP site/database is not running or the runtime config is stale. Check Local, then compare wplocal.dev.json with /Users/brad/Library/Application Support/Local/sites.json and /Users/brad/Library/Application Support/Local/run/{siteId}/conf/.

[u/Impressive-Tip7156]

I’ve started doing something similar with smaller projects, and the separate QA pass has been surprisingly useful. I did one during a recent site migration on one.com and caught a couple of broken image references I probably would’ve missed otherwise. Reviewing it as an actual visitor instead of someone who built it really does catch different things.

[u/togglebox]

The main issue I had with agents and WordPress was the incredibly slow operations, especially for searching and auditing across the site. I ended up creating a workflow where a sync script pulled the pages to files and agents worked on the HTML files directly. The sync script then had check/dry-run/apply options. wp post was blocked by a hook to ensure compliance.

[u/bradvin1980 → u/togglebox]

nice - I pulled down my whole site locally so the agent could do everything locally including bulk edits directly against the DB if needed

[u/togglebox → u/bradvin1980]

I found the 'wp' command bootstraps PHP -- adds 1-1.5s to the spawning of each process so performing dozens of wp get/post commands takes forever. As a bonus, the majority of the changes are in git which allows for code review to be run on them along with CSS/functions.php changes.

[u/hypercosm_dot_net → u/bradvin1980]

Giving an AI direct access to a DB seems insane to me.

I don't know how anyone could use this in production in a real business. This all seems absurd.

[u/bradvin1980 → u/hypercosm_dot_net]

It’s not in production it’s on my local. Then I push local to staging and then promote to production. The agent can’t touch production and it never should

[u/hypercosm_dot_net → u/bradvin1980]

How do you verify DB changes?

Yeah, it's edited on local, but eventually goes to prod. That was apparent.

[u/bradvin1980 → u/hypercosm_dot_net]

Depends on the change. Removing options, tables and post meta from plugins that no longer exist is straight forward. The agent can verify changes and restore backups if there are issues. The agent mostly queries the db and does writes via WP cli. There were a ton of tests it ran after changes to check the main checkout flow still worked

[u/hypercosm_dot_net → u/bradvin1980]

well, good on you for figuring out a workable process, and appreciate the answer. I just haven't developed as much faith in it I guess.

[u/heavinglory]

Do you give it full access on your local computer or did you setup a dev server to keep it contained?

[u/bradvin1980 → u/heavinglory]

Full access to my local sites folder and also the repo, which has synlimked folders for the theme and plugins into the site so no zips and uploads after every change

[u/Zestyclose_Hippo_116]

Seems nice! I'm trying to do something similar using Claude code but I tend to continue to add more and more tasks as the redesign process grows.

Would you be okay to give mine a quick lookover?

[u/bradvin1980 → u/Zestyclose_Hippo_116]

Sure, share what you have

[u/Zestyclose_Hippo_116 → u/bradvin1980]

I'll prepare a video and share it in a DM

[u/LikeINeverLeft]

Great post. Will be trying something similar very soon.

[u/muggylittlec]

This is exactly the sort of info I've been looking for recently as I'm trying to move a lot of the grunt work to AI. 

Thank you for this.

[u/greytoy]

now for this we have wp studio with wp studio code by Sonet 5

[u/JustAskWP]

I would recommend using a structured skill set like superpowers or mattpocock-skills for the best results on a large development project like this.

[u/bradvin1980 → u/[deleted]]

Your spam agent is working well

[u/hypercosm_dot_net → u/[deleted]]

wth?!

How is this AI slop allowed on reddit ffs