AI tools have changed how WordPress plugins get built. A plugin that used to take a week now takes an afternoon. The WordPress Plugins Team reviewed 12,713 plugins in 2025, a 40.6% increase over the previous year, and explicitly credited AI-assisted development for the surge.
Building the thing is mostly solved. Getting it onto your clients' sites is still the bottleneck.
The vibe coding workflow hits a wall at distribution
If you haven't heard the term yet: vibe coding is building software by describing what you want in natural language and letting an AI write the code. Cursor, Claude, Copilot. You know the tools. A developer named Nathan Onn published a writeup last year about building a complete WordPress plugin in 50 minutes with Claude Code. That kind of timeline is becoming normal.
The problem is what happens when you finish.
You have a working plugin. Now you need to get it onto the WordPress sites running it. That workflow hasn't changed since WordPress 2.7 shipped plugin management in 2008.
What private WordPress plugin distribution actually looks like
WordPress.org handles updates automatically. If your plugin lives on the repository, clients see the update notification in their wp-admin and click one button. For anything outside WordPress.org — client builds, premium plugins, internal tools — none of that infrastructure exists by default.
You have three options, and none of them are good.
Email the ZIP. You package the plugin, email it with instructions. Fine for two clients. Falls apart at ten. Every time someone asks "am I on the latest version?", you're back in your inbox.
Manual dashboard uploads. You log into each wp-admin, go to Plugins → Add New → Upload Plugin, and install the ZIP. This immediately hits a WordPress limitation that's been open in Trac since 2009: if the plugin already exists, you get a "destination folder already exists" error. The fix is to deactivate and delete the old version first, which means there's a window where the plugin is just gone. Some managed hosting providers block ZIP uploads entirely, so this isn't even an option.
Roll your own update server. This is the serious route. Libraries like plugin-update-checker let you point WordPress's built-in update mechanism at your own endpoint. Connected sites see update notifications exactly like WordPress.org plugins.
The catch: you own the server now. It needs uptime, security patches, backups, and someone to debug it at 11pm when an update fails across a client's sites. You're also still uploading ZIPs manually; you've just changed where you upload them. No release history, no changelog hosting, no CI integration without building it yourself. We cover this route in detail — including the Update URI header and the update_plugins_{$hostname} filter WordPress 5.8 introduced — in How to Set Up a WordPress Plugin Update Server.
Why this hurts more when you're shipping fast
When a plugin takes a week to build, spending two hours on packaging and distribution is a rounding error. When it takes an afternoon, those two hours are the slow part of your day.
There's also a subtler cost: slow release processes make you avoid releasing. If shipping is painful, you batch changes instead of pushing them. Bugs stay live longer. Small improvements sit in branches waiting to be grouped with something else. You end up shipping less, which mostly defeats the point of using AI to build faster.
Around 41% of all code written globally is now AI-generated, according to recent estimates. The build side of software development has been moving fast. The distribution side for WordPress plugins specifically has not.
The release workflow that actually matches how you work
The workflow that makes sense here is the same one modern software uses: push a tag, automation handles the rest.
# .github/workflows/release.yml
name: Release
on:
push:
tags:
- 'v*'
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build plugin
run: |
composer install --no-dev --optimize-autoloader
zip -r my-plugin.zip . --exclude="*.git*" --exclude="tests/*"
- name: Deploy to AutomagicWP
uses: automagicwp/deploy-action@v1
with:
api-key: ${{ secrets.AUTOMAGICWP_API_KEY }}
plugin-id: ${{ secrets.AUTOMAGICWP_PLUGIN_ID }}
file: my-plugin.zip
Push a tag. The action builds the ZIP, uploads it, and every connected site pulls the update on WordPress's standard 12-hour check cycle. Nobody touches a dashboard.
10up, Ahmad Awais, and most serious WordPress shops have been running workflows like this for WordPress.org deployments for years. The gap has always been private and commercial plugins — the ones distributed outside the repository. That's what AutomagicWP is for.
What you get with a managed update layer
AutomagicWP is between rolling your own server and a full commercial platform like Freemius. It does one thing: connect your release pipeline to the WordPress update mechanism on your clients' sites.
The WordPress-side integration is a small PHP library and an API key added to your plugin. It hooks into pre_set_site_transient_update_plugins and redirects update checks to AutomagicWP. From WordPress core's perspective it looks like any other update source. From your clients' perspective they see the standard update notification in their dashboard.
What comes with it:
- Version history. Every release is stored. You can download or redeploy any previous version without keeping your own archive.
- Changelogs in the update UI. What you write shows up next to the version number in the WordPress update screen, the same way WordPress.org plugins surface it.
- Plugin metadata. Icons, banners, and descriptions render correctly in the WordPress plugins interface.
- License key support. Optional. If you need to gate updates behind a valid license, it's built in.
- Theme support. Same workflow, same GitHub Actions setup, uses
pre_set_site_transient_update_themeson the WordPress side.
The GitHub Actions integration is what closes the loop. You commit code, push a tag, clients see the update. You don't touch a dashboard.
The pattern is already established
Tooling for automating WordPress.org plugin deployments has been mature for years. 10up's action-wordpress-plugin-deploy is widely used, Ahmad Awais built wp-continuous-deployment to similar effect. The CI/CD workflow for WordPress is understood.
The missing piece has always been private distribution — plugins and themes that can't or shouldn't live on WordPress.org. The update mechanism is identical under the hood; the delivery layer was just never there.
If you're vibe coding plugins and distributing them to client sites, your build workflow is already where it needs to be. The question is whether your release workflow has caught up.
Frequently asked questions
Does adding AutomagicWP require significant changes to my existing plugin?
Minimal. Add the PHP library and an API key. The library handles the pre_set_site_transient_update_plugins hook and points update checks at AutomagicWP. Most plugins need fewer than ten lines of setup code, and it doesn't affect plugin functionality.
What about managed WordPress hosting that restricts plugin uploads?
Managed hosts commonly block manual ZIP uploads but allow the standard WordPress update API path. AutomagicWP uses that path, so it works the same way WordPress.org updates do without any special hosting configuration.
Does this work for themes as well as plugins?
Yes. Same GitHub Actions workflow, same setup. You specify plugin or theme in the deploy action configuration. The hook on the WordPress side is pre_set_site_transient_update_themes for themes.
What happens if I need to roll back a release?
Every release is stored. You can redeploy any previous version from the dashboard, and connected sites will see it as an available update through the standard update UI.
How often do connected sites check for updates?
WordPress runs wp_update_plugins on a 12-hour cron cycle automatically. It also checks when a user visits Dashboard → Updates or the Plugins page. No manual triggering needed.
Can I push releases without GitHub Actions?
Yes. AutomagicWP has a REST API. Any CI platform works — GitLab CI, Bitbucket Pipelines, CircleCI, or a manual script. The GitHub Actions integration is pre-built for convenience.