I've been building WordPress plugins since long before an AI agent was in the loop. The catalogue I run today — the MSC plugins — is small, live on WordPress.org, and maintained by exactly one person. This post is the honest version of how that works now that an agent harness is part of the build.
The short version: AI didn't let me skip the quality work. It let me do the repetitive parts faster and spend the saved time on the parts that still need a human who knows the platform. The rest of this post walks the actual shape of it — what ships, how a new plugin starts, where the review gate sits, and where AI still leaves me cold.
What I actually ship
Four plugins are live on WordPress.org right now, all free and GPL-2.0 or later:
- MSC Last Update
- MSC Post Expiry
- MSC Scheduled Visibility
- MSC Stealth Login
All four are verified live at the WordPress.org profile for djm56. That profile is the public home for the free catalogue; if you want to browse them, that's where they sit.
[OPERATOR INPUT — needed before publish]: The exact plugin-page URLs on WordPress.org and anomalous.co.za for each of the four live MSC plugins, so they can be deep-linked here. (The profile link above is live; the individual pages need their real URLs.)
The public install count for each is, honestly, small.
[OPERATOR INPUT — needed before publish]: Install numbers, if you're happy to share them. The public WordPress.org figure for each live plugin is "Less than 10 active installs" — state that honestly, or omit numbers entirely. Don't dress it up.
In development, two pro plugins are further along: MSC Translation Health (project anom-010, a WPML/Polylang integrity scanner) and MSC WC Store Health Monitor (project anom-006). A third, MSC Multilingual SEO Auditor (project anom-011), is built but not yet released. None of those three are on WordPress.org yet, and I won't describe them as shipped until they are.
The numbering isn't cosmetic. Every product lives in a numbered folder — anomalous/projects/anom-NNN-{slug}/ — and anomalous/projects.md is the single source of truth for status. Numbers are never reused, and folders never move. That registry is what lets one person hold a catalogue in his head without a spreadsheet: ask the file what's real, and it tells you.
It also prevents the quiet drift that kills solo catalogues. Without a hard record, a plugin half-built in a branch becomes "shipped" in your memory long before it is. The registry refuses that — a plugin is live, in development, or built-not-released, and the file is the arbiter when memory gets optimistic.
The bootstrap that makes a new plugin fast
Starting a new MSC plugin isn't a blank-file exercise. There's a bootstrap — a structure that gets a new plugin to "scaffolded and compliant" in minutes, so the interesting work starts immediately. It carries the boilerplate that WordPress.org will later check, so the agent and I aren't re-deriving the same shape every time.
What the bootstrap is not: a code generator that writes the plugin for me. It's the frame. The agent fills the frame; I still decide what goes in it, and I still read what comes out.
[OPERATOR INPUT — needed before publish]: The bootstrap's provenance — how much of it can be made public, and whether to link to or describe its origin. (This is operator input per the brief; don't invent a history.)
[OPERATOR INPUT — needed before publish]: One concrete example of a plugin that went from idea to submitted — what the idea was, roughly how long the build took, and what the review process caught. (1–2 sentences, or a short paragraph.)
The point of the bootstrap is leverage, not automation. It removes the friction that used to eat the first hour of every new plugin, and it does so without pretending the hard decisions are someone else's.
One codebase, free and pro
The free plugins on WordPress.org and the pro plugins I sell directly come from one codebase, split by a clear line. The free tier is the real, complete plugin — not a teaser with the good half locked away. Pro adds capability on top, behind its own load, without forking the core.
That split matters for maintenance. One bug fix in the shared layer fixes both editions at once. The alternative — two separate repos that drift apart over months — is exactly how a solo developer drowns. The free/pro boundary is a build decision made early, not a monetisation idea bolted on after the fact.
It also keeps the catalogue honest. Because the free plugin is genuinely complete, the WordPress.org listing isn't a funnel in disguise. People get working software; the pro edition is for the teams that need more, not for everyone who wanted the basics.
That single-codebase discipline is also why a catalogue stays maintainable as it grows. Each new plugin inherits the frame instead of reinventing it, so the cost of adding the eleventh plugin is far below the cost of the first — and the review gate I already trust keeps applying without being rebuilt for every release.
What the agents do — and what I still read by hand
The agents handle the parts that are tedious and well-specified: generating the repetitive glue, drafting the first pass of a function, writing the escaping boilerplate, producing the PHPUnit scaffold, and proposing the diffs. They're fast at the work where the shape is known and the job is to fill it in.
I still read, by hand, every patch before it lands — the same review discipline the Bishop milestone describes. If you haven't read that one, it's live: Building Bishop — an AI agent harness for real development work. The argument there is that a single agent with a good prompt doesn't survive real work; roles, hard limits, and a review path do. That's exactly the posture I bring to plugins.
What I review by hand is the judgement-heavy part: does this respect WordPress platform conventions, does the security model hold, is the user-facing behaviour actually what a site owner expects when something goes wrong at 2am? The agent can propose; it can't be the one who signs off that this is correct for WordPress. That call is mine, and it stays mine.
"Reading by hand" isn't nostalgia — it's the only step the agent can't do. The harness can show me the diff, explain its reasoning, and even flag the lines it's least sure of, but the yes-or-no is a human decision by design. That's the same hard limit the Bishop work landed on: the agent earns scope by proving it can be stopped, not by being trusted with the final key.
The WordPress.org guidelines are instructions, not an afterthought
The WordPress.org plugin review guidelines aren't a final hurdle I clear after the code is written. They're instructions the agent builds against from the first commit. The constraints the guidelines impose — how a plugin must declare itself, how it must handle data, what it may and may not do at runtime — go into the build as constraints, the same way the security model does.
Treating the guidelines as instructions rather than a gate changes the failure mode. Instead of "submit, get rejected, scramble to fix," the review tends to be a formality, because the constraint was already in the scaffolding. The catalogue's recent shipping activity shows the approach holding up: WordPress 7.1 compatibility releases went out across every plugin on 2026-08-27, and translation contributions landed across 12 locales on WordPress.org. That's maintenance work that only pays off because the foundation was built to absorb it.
One person, a real catalogue
This is the part people find surprising: the catalogue is real and maintained by one developer. The bootstrap, the shared free/pro codebase, and the review gate are what make that possible. None of it is magic — it's the boring infrastructure that turns "I could maintain ten plugins" into "I do maintain them."
The pro plugins in development (MSC Translation Health, MSC WC Store Health Monitor) and the built-not-released MSC Multilingual SEO Auditor are the next layer. They're real code, not slideware, but they aren't on WordPress.org yet, and I won't present them as shipped until they are. The registry keeps that distinction unambiguous: a plugin is either live, in development, or built-not-released, and the file says which.
Where AI genuinely doesn't help yet
I'll be straight about the limits. AI is weak at the parts of WordPress work that depend on why — why a given site runs a particular configuration, why a legacy pattern exists, what a real client will actually do with a setting they don't fully understand. It's good at the known shape and poor at the unknown intent.
It also doesn't replace the security review as a specific discipline. A first pass that looks clean can still carry a subtle issue, and "the agent wrote it" is not a review. The judgement load went up, not down — I'm reviewing more code, not less, and the code I'm reviewing I didn't write. That's the honest trade, and pretending otherwise is how people ship things they don't understand.
There's a second gap worth naming: AI is good at producing a plugin that passes a checklist and bad at producing one that fits a real workflow. Fitting the workflow is the part that needs the human who's actually shipped for clients. The agent can't know that a setting will confuse the exact person who'll use it, because it's never met them.
What I'd tell someone starting a plugin business now
If you're starting a WordPress plugin business today, the leverage is real but it isn't in skipping the hard parts. Build the scaffolding first — the bootstrap, the shared codebase, the review gate — because that's what lets you move fast later without breaking things. Treat platform guidelines as build-time instructions, not a final gate. Keep a single source of truth for what you've shipped and what you haven't, so the catalogue stays honest as it grows.
Start with one plugin that's genuinely complete, not three that are almost there. A complete free plugin teaches you the whole loop — build, review, submit, maintain — and the scaffolding you make for it pays for the next nine. Resist the urge to monetise before the quality bar is real; a pro edition built on a shaky free base just multiplies the shakiness. And measure yourself by what's live and maintained, not by what's planned, because planned is the easy part and the file will remind you which is which.
And keep the human in the review seat. The agent earns the right to do more by proving it can't do the wrong thing — which is the same principle behind the Bishop harness, and behind every plugin I'm willing to put my name on. A plugin you can't fully explain is one you're shipping on faith, and I've never been good at that.
Get in touch
If you want help setting this up for your team, get in touch.
The next milestone in the writing queue is M4 — WordPress in the AI Era, on how AI changed the shape of client work more than the volume of it. It's on the list, not yet published, so I won't point you to it as if it exists.
If you want the groundwork first, M1 — How I Actually Work With AI — and M2 — Building Bishop — are both live. The related cluster posts in this category (plugin bootstrap, free/pro structure, reviewing AI-written plugins, the .org guidelines, catalogue maintenance, multilingual suites) will link in once they're published.