How to Build a WordPress Plugin With ChatGPT in One Day

The genre of post this belongs to usually reads as a diary: I asked ChatGPT for a plugin, here is what it said, it worked, isn’t that remarkable. It was remarkable in 2023. It is now Tuesday.

What is worth writing down is the part those posts leave out. WordPress plugins run with full access to your site’s database and file system. The failure mode of AI-written plugin code is not that it does not work, which would be obvious and harmless. It is that it works perfectly while leaving an admin endpoint callable by anonymous visitors.

This is the workflow that produces a plugin you can actually deploy: the structure, the prompts that get secure code rather than merely working code, the four things to check every time, and the boundary where you should stop and hire a developer.

What a WordPress plugin minimally is

A folder in wp-content/plugins/ containing a PHP file with a header comment. That is the entire requirement. Everything else is convention.

wp-content/plugins/tc-reading-time/
├── tc-reading-time.php      <- header comment lives here
├── includes/
├── admin/
└── readme.txt

<?php
/**
 * Plugin Name: TC Reading Time
 * Description: Adds an estimated reading time above post content.
 * Version:     1.0.0
 * Author:      Your Name
 * License:     GPL-2.0-or-later
 * Text Domain: tc-reading-time
 */

// Refuse to run if loaded directly rather than through WordPress.
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

That ABSPATH guard is the first thing AI-generated plugins routinely omit, and it is the cheapest line of defence you will ever write. Without it, the file can be requested directly over HTTP, outside WordPress, with none of the security context loaded.

The four things AI code gets wrong

These are not exotic edge cases. They are the four checks that appear in every WordPress security guideline, and in practice a model will skip them unless you name them.

Safeguard	What it stops	The function	Typical omission
Capability check	A subscriber performing an admin action	current_user_can()	Form handler with no check at all
Nonce verification	Cross-site request forgery	wp_verify_nonce() / check_admin_referer()	Nonce is created in the form and never verified on submit
Input sanitisation	Malicious data entering the database	sanitize_text_field() and siblings	Raw $_POST written straight to options
Output escaping	Stored XSS when the value is displayed	esc_html(), esc_attr(), esc_url()	Value echoed directly back into the page

The nonce-and-capability pair is the one people get half right. A nonce proves the request came from your form; it does not prove the person is allowed to do the thing. A capability check proves they are allowed; it does not prove they meant to. You need both.

A settings handler, written correctly

This is the pattern to compare AI output against. It is deliberately ordinary: a form that saves one option. Every one of the four safeguards appears.

function tc_handle_settings_save() {

    // 1. Capability: is this user allowed to do this at all?
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( esc_html__( 'Insufficient permissions.', 'tc-reading-time' ) );
    }

    // 2. Nonce: did this request come from our form?
    check_admin_referer( 'tc_save_settings', 'tc_nonce' );

    // 3. Sanitise every value on the way in.
    $label = isset( $_POST['tc_label'] )
        ? sanitize_text_field( wp_unslash( $_POST['tc_label'] ) )
        : '';

    $wpm = isset( $_POST['tc_wpm'] )
        ? absint( $_POST['tc_wpm'] )
        : 200;

    // Validate ranges, do not just trust the type.
    if ( $wpm < 50 || $wpm > 1000 ) {
        $wpm = 200;
    }

    update_option( 'tc_reading_label', $label );
    update_option( 'tc_reading_wpm', $wpm );

    wp_safe_redirect( admin_url( 'options-general.php?page=tc-reading-time&updated=1' ) );
    exit;
}
add_action( 'admin_post_tc_save_settings', 'tc_handle_settings_save' );

Then escape on the way out, every time, without exception:

<input type="text"
       name="tc_label"
       value="<?php echo esc_attr( get_option( 'tc_reading_label', '' ) ); ?>" />

The rule is escape late, at the point of output, rather than trusting that a value was clean when it went in. A value sanitised in 2024 and displayed by code written in 2026 in a different context needs escaping appropriate to that context.

Prompts that produce usable code

The difference between a plugin you can ship and one you cannot is almost entirely in what you asked for. Four techniques, in order of impact.

1. Name the safeguards in the prompt. Not “make it secure”, which produces a comment saying the code is secure. Say: verify a nonce with check_admin_referer, check current_user_can(‘manage_options’), sanitise all input with the appropriate sanitize_ function, and escape all output with esc_html or esc_attr.
2. Ask for the WordPress way, not the PHP way. Models will happily write raw SQL, use file_get_contents for remote requests, and echo HTML directly. Specify $wpdb->prepare, wp_remote_get, the Settings API, and wp_enqueue_script.
3. Build one function at a time. Asking for an entire plugin in one prompt produces something plausible and hard to review. Asking for one function gives you code you can actually read, and each subsequent request keeps the context tight.
4. Give it the version you are targeting. Say WordPress 6.x and PHP 8.2. Otherwise you get deprecated patterns from older training data, and create_function or pre-namespace idioms that no longer run.

The day, realistically

Stage	Rough time	What actually happens
Define the scope in one sentence	15 min	The hardest part. Vague scope produces vague code
Scaffold: header, guard, activation hook	30 min	Fast and usually correct
Core functionality	2 to 3 hours	Iterative. Works around the third attempt
Admin settings screen	1 to 2 hours	Where the security omissions cluster
Security review against the four checks	1 hour	The step people skip. Do not
Testing on a staging site	1 hour	Fatal errors, conflicts, PHP notices

Test on a local install or a staging site, never on production. A fatal error in a plugin you just activated takes the site down, and although WordPress has fatal error protection, relying on it as your testing strategy is not a strategy.

Turn on WP_DEBUG while you develop. AI-generated code frequently produces undefined index notices and deprecation warnings that are invisible with debugging off and become fatal on the next PHP version.

When to stop and hire someone

AI-assisted development is genuinely good for small, self-contained plugins that solve one problem on one site. The boundaries are reasonably clear.

• Anything handling payments. Regulatory and liability exposure that no amount of prompting substitutes for expertise.
• Anything storing personal data. Data protection obligations attach to the design, not just the code.
• Anything you intend to distribute. A vulnerability in your own site is your problem. A vulnerability in a plugin a thousand sites installed is everyone’s.
• File uploads. The classic path to remote code execution, and the area where generated code is weakest because the correct approach involves several non-obvious WordPress functions.
• Anything you cannot read. If you cannot follow what the code does, you cannot review it, and shipping code you do not understand is the actual risk here regardless of who wrote it.

That last point is the honest summary. AI lowers the cost of writing a plugin; it does not lower the cost of being wrong. The review step is the whole job, and it is the step that a day-long build tends to eat.

If a plugin you built this way breaks the site, the recovery routes are in our guide to fixing a WordPress site after a plugin failure. If you are weighing building against commissioning, what WordPress development actually costs sets out the realistic numbers.

Frequently asked questions