How I built a WordPress plugin in 2 minutes with AI (and what it got wrong)

I gave an AI coding agent a single prompt: "Build me a WooCommerce plugin that hides the 'Add to cart' button on products tagged 'coming-soon' and replaces it with a mailing list signup form that pushes to Mailchimp." Two minutes later I had a working ZIP. Here is exactly what happened.

The setup

I was not interested in writing a plugin from scratch. I was interested in testing how much of the boring scaffolding work a modern AI can actually do without me babysitting it. My test rig was a WordPress 6.4 site with WooCommerce 8.5 running in a Docker sandbox, exactly the setup most of my client projects look like. I also had Mailchimp API credentials in a test account. Nothing was mocked.

What the AI got right in the first pass

The generated plugin had a proper plugin header block, the required Plugin Name, Requires at least and Requires PHP fields. It wired into the correct WooCommerce hook (woocommerce_single_product_summary) with a sensible priority. It added a defer guard so it would not throw if WooCommerce was deactivated. It created an options page under WooCommerce settings, sanitized inputs with sanitize_text_field and escaped outputs with esc_html and esc_attr. All of it with the WordPress Coding Standards whitespace I would normally have to reformat by hand.

The real surprise was the uninstall behavior. Without being prompted, the AI added an uninstall.php file that cleaned up the three options it created. I have seen paid plugins ship without that.

What it got wrong

The Mailchimp integration used the v3 API and a Bearer token, which is correct, but it stored the API key in plain text in the options table. For a quick prototype this is acceptable. For a real plugin I would either push this to an encrypted option or require the user to paste it through a connection flow that at least hashes it at rest. The AI did not volunteer that.

The signup form had no nonce. For a form posting to admin-ajax.php that is a real bug, not a style issue. I had to add wp_nonce_field on the form and check_admin_referer on the handler. Two lines of code, but the kind of thing you cannot ship without.

Finally, the product tag lookup used get_the_terms inside a loop without caching. On a category archive with 48 products per page that is 48 extra queries. I added a single get_posts with a meta query and cached the result in a transient for five minutes. The AI accepted the refactor when I pasted back the fixed snippet and asked it to explain why the original was slower, which was a useful sanity check.

The time breakdown

Generation: 1 minute 47 seconds. Manual fixes (nonce, caching, a bit of copy tweaking): 18 minutes. Packaging and testing: 5 minutes. Total end to end: roughly 25 minutes for a plugin I would have quoted a client at three to four hours.

What I learned

AI is not replacing plugin developers in 2026. What it is doing is eating the first 80% of the job, the part that was always the least interesting: boilerplate, hook wiring, settings pages, escapes, sanitizers, uninstall hooks. That is exactly the part I was slowest at, because it is the part I was most bored by.

The remaining 20% is what you were actually hired for: caching strategy, security review, UX on the settings page, and knowing when not to ship something. That does not go away. But getting to it in two minutes instead of three hours changes the economics of the work completely.

Would I use this in production?

For a client site, I would generate, review line by line, add the security bits the AI missed, add tests around the API calls, and then ship. For my own site, I have already replaced three snippet-plugins with AI-generated versions and I have not regretted any of them.

The part I care about most is the reviewing. If you cannot read the code the AI produces, you should not ship it. That is not new advice, it applies to any code you did not write yourself, and it is exactly as true with AI as it was when you were copy-pasting from Stack Overflow in 2015.