A year ago, AI in our WordPress work meant two things: autocomplete in the editor, and a chat window we pasted code into. Useful, but small. It sped up typing. It did not change the shape of the work. Today the picture is different enough that I want to write down what actually shifted, because the change is easy to miss if you only look at any one new feature in isolation. This is really a story about AI agents, and how they moved from a novelty in the sidebar to the center of how we build and maintain WordPress.

The short version: we stopped prompting and started orchestrating. A single clever prompt is no longer the interesting unit. The interesting unit is a set of agents, each with a job, running in a sequence we designed, checking each other’s work, and reporting back. That is a bigger shift than any single model release, and it touches every seat in the agency, not just the developers.

This is not a tool review. It is the bigger picture, built from a year of running this inside a real team that ships and maintains a large product catalog. I will keep the developer detail in its own sections so a non-technical reader can skip them without losing the thread.

From one prompt to a fleet of AI agents

The old habit was to open a chat, describe a task in one careful message, and hope the answer came back complete. When it did not, you argued with it. That loop was fun for a demo and painful for real work, because a real task rarely fits in one message and one answer.

What replaced it is orchestration. Instead of writing the perfect prompt, we now design the flow: a planning agent that reads the codebase and lays out the work, a set of worker agents that each take one slice, and a review pass that checks the result before anything is called done. The person running it is closer to a lead who assigns work and reviews it than to someone typing instructions into a box.

The loud version of this idea online right now is people running dozens or even a hundred agents at once. That headline is real, but it is also a trap if you copy it without a reason. Most of the value we see comes from a handful of agents with clear roles, not a swarm for its own sake. More agents is not more progress. More agents with a clear job, a clear hand-off, and a review gate is.

For the developers: what a fleet actually looks like

In practice a wave looks like this. One agent works in an isolated git worktree so it cannot step on anyone else. It reads the manifest, greps for the existing helper before writing a new one, makes the change, and runs the coding standards and static analysis. A second agent verifies the result against the real behaviour, in a browser, at phone width, not just against a passing unit test. Only when both agree does the change move forward. We built our own engine for this so the waves are repeatable rather than improvised each time.

The important design choice is the review gate between steps. A model left to mark its own homework will tell you everything passed. A separate verification pass, with its own instructions and no stake in the first agent looking good, is where the honesty comes from. That single idea, a builder and an independent checker, is most of what makes a fleet trustworthy.

Here is one wave, start to finish, so it is concrete rather than abstract. A support ticket becomes a bug card. A planning agent reads the card, pulls the plugin’s manifest, and confirms the reported behaviour is real by reproducing it on a reference site with the same third-party plugin the customer had installed. It writes a short plan: the one function at fault, the callers that route through it, and the fix. A worker agent takes that plan in an isolated copy of the repo, makes the change in the shared function rather than patching each caller, and runs coding standards, static analysis, and the test suite. A verification agent then opens a browser, walks the exact steps from the ticket, and confirms the bug is gone at desktop and phone width. Only then does a human read the diff and decide whether it ships. Four roles, one hand-off each, one gate at the end. The person spent their time on the two judgment calls that mattered, not on the typing in between.

The failure mode we watch for is a fleet that looks productive and produces noise: three agents rewriting the same file, a plan nobody checked, a green test that tested the wrong thing. The whole value sits in the review step, which is why we spend more design effort there than on the generating.

Speed without a gate is just faster mess. An unreviewed change is not a finished change, it is a liability with good formatting.

The plumbing that made this real

None of the above would work if agents could only read text. The change under the change is that agents got hands. They can now call real tools and read live data through a shared standard called the Model Context Protocol, or MCP. That sounds dry, and it is the most important thing that happened all year.

Before MCP, every integration was a one-off. If you wanted an agent to read your database, drive a browser, or post to your CRM, you wrote glue code that broke the moment anything moved. MCP turned that into a common plug. An agent that speaks it can pick up a new capability the way a laptop picks up a USB device. For us that meant we could give an agent safe, specific access to the pieces that matter: the site database, WP-CLI, a real browser for testing, the CRM, the support queue.

Because the standard is open and easy, everyone started shipping servers. That is the good news and the warning at the same time. There is a gold rush of MCP servers right now, and the quality is all over the place. Plenty look finished and then fail the moment you connect, or ask for access far beyond what they need, or quietly stop working when a token rotates. We have watched servers that pass a casual look fail the first real adversarial check.

For the developers: telling a real server from a demo

Our rule of thumb after a year of this is simple. A server we trust owns its own hard parts: token refresh, pagination, error handling, and a clear, narrow set of permissions. It fails loudly when something is wrong instead of returning an empty result that looks like success. It does not ask for the keys to everything to do one small job. When a server we depend on is missing a command, the honest fix is to add the command to that server, not to route around it with a throwaway script that nobody can maintain next month. A one-off script is a debt you pay again every session. A new command is a fix that stays fixed.

Vibe coding is fine, calling it engineering is the problem

The phrase of the year is vibe coding: describing what you want and letting the model produce the code without reading much of it. I am not against it. For a throwaway script, a quick prototype, or a one-time data fix, it is a fair trade and it saves real time. The problem is not the practice. The problem is calling the output engineering and shipping it to thousands of live sites.

Generated code is very good at looking correct. It compiles, it runs on the happy path, and the demo works. Where it breaks is the part a model cannot see from the prompt: the second caller of the same function that now behaves differently, the query that is fine on five rows and falls over at two thousand, the edge case that only shows up with a real third-party plugin installed and real data flowing through it. These are the failures that reach customers, and they are exactly the ones a quick vibe pass skips.

So the line we hold is about ownership, not about tools. A person still owns the outcome. That means reading what the agent wrote, tracing every caller of anything it touched, and reproducing the actual conditions before believing a fix. A report of a bug is a lead, not a spec, and the same is true of a model’s confident answer. We treat both the same way: reproduce first, then fix the real cause, never the surface.

If you cannot measure it, it stays a vibe

For most of the year, everyone was collecting agent setups: skills, rules files, prompts, servers. People shared configurations with hundreds of skills bundled in. The uncomfortable question nobody could answer was whether any of it helped. You could feel more productive without being more productive, which is a familiar trap for anyone who has confused a busy day with a useful one.

The recent shift is that measurement finally showed up. There are now ways to run an agent setup against a fixed set of tasks and score the result, so you can see whether a given skill or server changes the output or just adds weight. This is quieter than the swarm headlines, and it matters more. It moves the whole practice from taste and vibes toward something you can actually check.

Our own version of this is the audit gate. Nothing we generate ships because it looks done. A blog post passes a word-count, link, image, and forbidden-phrase gate before it publishes. A plugin release passes a contract audit that catches the “saved but not applied” class of bug. A fix passes an independent verification pass. The value is not in the generating. It is in the gate that refuses to let a confident-looking result through without proof.

The cost side nobody puts on the slide

There is a part of this that the excited posts skip, and I want to be honest about it because it shapes every decision we make. Running fleets of agents is not free. Each agent reading a codebase, planning, editing, and verifying spends tokens, and a swarm spends them fast. It is entirely possible to burn a real amount of money having ten agents circle a problem that one careful pass would have solved.

So we treat compute like any other cost on a job. A small, well-scoped task does not get a fleet, it gets one agent. A large migration that would take a person a week is where parallel agents earn their keep, because the wall-clock saving is large and the review is still one human reading diffs. The question we ask before spinning anything up is the same question a lead asks before assigning people: is this worth the hours, or am I adding motion because motion is available?

The other hidden cost is review time. Agents shifted the bottleneck, they did not remove it. If four agents each produce a change in an hour, a human still has to read four changes, and reading a diff you did not write is slower than reading your own. A team that scales agent output without scaling review capacity just moves the pile-up one step downstream and calls it progress. We size the work so the reviewing keeps up, because output that outruns review is not progress, it is just risk stacked up for later.

What this changed across the agency, seat by seat

The reason this is a bigger-picture story and not a developer story is that the same shift reached every function. A year ago AI touched one corner of the work. Now it touches all of it, and the pattern is the same each time: the cost of doing the task dropped, and the work moved up into deciding and reviewing.

  • Plugin and theme development. A year ago, completion in the editor. Now an agent takes a card, works across many files, runs the standards and tests, verifies in a browser, and opens the pull request. The bottleneck moved from writing code to reviewing it well.
  • Quality assurance and release. A year ago, manual click-throughs and a human writing browser scripts. Now agents drive the browser directly, run contract and scale checks against seeded large datasets, and hold a release gate. QA moved from finding bugs by hand to defining what correct means so an agent can check it every time.
  • Support and triage. A year ago, a person reading every ticket cold. Now an agent pulls the queue, cross-references a customer’s history, reproduces the issue on a reference site, and drafts the reply or files a clean bug card. The human keeps the judgment and the tone.
  • Content, marketing, and SEO. A year ago, generic drafts a human rewrote from scratch. Now a full pipeline runs: trend research, keyword work, draft, a humanize check, an SEO score, a featured image built as code and rendered, internal links, an audit gate, publish, and distribution to the social queue. The human work is taste, angle, and the guardrails that keep it from reading like a machine wrote it.
  • Site operations and security. A year ago, manual scans and cron babysitting. Now agents scan fleets of sites, clean infections, and harden configurations over the same tooling. The hard truth is that attackers use the same agents to find holes faster, which is part of why this year saw such a heavy run of plugin vulnerabilities. Defense has to move at agent speed now, not on a monthly checklist.
  • CRM and automation. A year ago, rules clicked together in a dashboard. Now an agent builds the funnel, backfills enrollments, runs cohort reports, and audits tag hygiene across a whole product line. The owner sets the intent and reviews the outcome.

What still needs a human

It would be dishonest to make this sound finished. Agents collapsed the cost of doing. They did not collapse the cost of deciding, and those are very different things.

Deciding what to build, whether a fix addresses the real cause or just the symptom, how a change lands for a customer who is not in the room, whether the tone of a reply is right, and who carries the responsibility when something ships wrong: all of that is still human, and I think it stays human for a long while. An agent will happily follow a written rule off a cliff, which is exactly why written rules alone do not reliably govern how an agent behaves. The judgment lives with a person who owns the result, not in the instructions.

There is also a quieter risk. When the cost of producing drops to near zero, the temptation is to produce more of everything: more code, more posts, more features, more of what nobody asked for. Cheap output is not the same as valuable output. The discipline that used to be enforced by how long things took now has to be a deliberate choice, because the natural limiter is gone.

The other thing that stays human is accountability, and it matters more than it sounds. When a change ships to a client’s live site and something breaks, no client wants to hear that the agent wrote it. They hired us. The responsibility is ours, whoever or whatever typed the code. That is not a small point. It is the reason we cannot treat agent output as trusted by default, and the reason a person has to stand behind every change with their name on it. An agent can draft the work. It cannot own the outcome, apologise to a customer, or carry the trust that took years to build.

That trust is also why we are careful about where agents touch client data at all. An agent with access to a live database and a browser is powerful in exactly the way that is dangerous if it is pointed at the wrong thing. So access is narrow and specific, actions that cannot be undone still go through a person, and the agent works on a copy wherever a copy will do. The speed is worth having only if it never comes at the cost of a customer’s data or a customer’s confidence. Those two things are the whole business, and no amount of automation is worth spending them.

The real moat is the rails you build

If every agency has the same models and the same public servers, then using AI is not an advantage. Everyone has it. The advantage is in the rails you build around it: your own servers that expose your own systems safely, your own audit gates that refuse bad output, your own verification passes that catch the confident mistake, and the accumulated judgment about which agent to trust with what.

That is the part that took us a year to build and the part a competitor cannot copy by installing a plugin. The models are a commodity. The orchestration, the gates, and the taste are not. We built our own tooling for exactly this reason, so that the work an agent does for us runs through rails we control and can trust, rather than through whatever a generic setup happens to do.

So when people ask what changed in WordPress work with AI in the last year, my answer is not a list of new features. It is a change in role. A year ago we used AI to type faster. Now we design the flow, build the rails, set the gates, and review the output, while a fleet of agents does the doing. The teams that will pull ahead are not the ones who adopted AI. Almost everyone did. They are the ones who built the rails to run it safely, and who kept a human firmly in the seat where the deciding happens.

If you are weighing how to bring this into your own team, my one piece of advice is to start with the gate, not the agents. Decide how you will check the work before you scale how much work gets made. Build one honest verification pass you trust, point a single agent at a real task, and only widen from there once you can prove the output is good. The teams that do it in that order end up faster and safer. The teams that chase the swarm first spend the year cleaning up after it.