I Let an AI Agent Patch a Theme With a Tiny Reversible Plugin

A travel side project of mine still had dead theme markup after a long REST cleanup pass. A booking box linked to a page that now returned 404, sponsored event cards pointed at URLs that were gone, a captcha script loaded on every page instead of only the contact form, the author avatar was a heavy PNG, and the theme pulled in full font sets nobody asked for.

Editing the theme was the tempting next move. Instead I had an AI coding agent build a tiny front-end plugin that fixes the rendered HTML and changes nothing else, and I can switch it off to undo everything.

How I split the work with the agent

1. Crawl and classify. The agent crawled the public pages and split every problem into two buckets: content bugs that live in post JSON (fixable over REST) and markup the theme or another plugin injects at render time (not reachable over REST).
2. Write pure transforms. Each fix is a small function that takes HTML in and returns HTML out. Nothing reads or writes the database.
3. Test on saved HTML, not production. The agent saved real pages, ran the transforms against them, and diffed the output before the plugin went anywhere near the live site.
4. Ship behind kill switches. Every fix can be turned off on its own, and deactivating the plugin restores the original output.

I kept the product rules and approved the install. The agent did the crawling, coding, testing, and the boring before/after counting.

What the plugin does

• Swaps a dead booking-category link in a theme box for the live one
• Removes sponsored event cards that pointed at a removed post type
• Loads the captcha script only on the contact page, deferred
• Serves a self-hosted icon font subset and cuts the web fonts down to what the design actually uses
• Preloads the homepage hero, swaps the avatar PNG for a small WebP, and defers animation scripts
• Applies small CSS fixes to the cookie banner on mobile and to heading contrast on the contact page
• Rewrites outbound links in theme-rendered boxes from a static map that ships inside the plugin zip, with no runtime API calls

It has no settings screen, writes no options rows, and makes no external requests. The skeleton is short:

<?php
/**
 * Plugin Name: Site Front-End Fixes
 * Description: Pure output transforms for theme-injected markup. Deactivate to revert.
 */
if ( defined( 'SITEFIX_DISABLE' ) && SITEFIX_DISABLE ) {
    return;
}

add_action( 'template_redirect', function () {
    if ( is_admin() || is_feed() || wp_doing_ajax() || ( defined( 'REST_REQUEST' ) && REST_REQUEST ) ) {
        return; // Never touch admin, feeds, REST, or AJAX output.
    }
    if ( ! apply_filters( 'sitefix_enabled', true ) ) {
        return;
    }
    ob_start( 'sitefix_transform' );
} );

function sitefix_transform( $html ) {
    $map = array(
        'https://partner.example.com/old-category/' => 'https://partner.example.com/live-category/',
    );
    $html = strtr( $html, $map );
    // Drop cards that point at a removed post type.
    $html = preg_replace( '#<div class="inline-event"[^>]*>.*?</div>#s', '', $html );
    return $html;
}

The real plugin has one function per fix, and each one has its own filter so I can disable a single change without touching the rest.

How the agent tested it before install

• php -l and a PHPCompatibility scan against the PHP versions the server might run
• Unit tests for each transform against saved copies of real pages
• A harness that ran the transforms over every crawled page and counted the targets before and after (dead links, old font requests, avatar PNG references, captcha loads)
• A local WordPress install with a stub theme to check that activation and deactivation behave
• Headless Chrome screenshots at phone and desktop widths
• Proof that feed, REST, and login output is byte-identical with the plugin on or off, and that the HTML after deactivation is byte-identical to before activation

That last check is what made me comfortable approving it. If the agent got something wrong, deactivating the plugin really does put everything back.

What the plugin refuses to do

• No options table rows, no admin screens, no “one more settings page”
• No runtime calls to third-party APIs. Link rewrites come from a static map baked into the zip.
• No changes to feed, REST, login, or admin output
• No silent theme edit that vanishes on the next theme update
• No invented Lighthouse, traffic, or revenue claims in the ship notes

Ship checklist (if you copy the pattern)

1. Have the agent crawl first and split REST-fixable content from theme-injected markup.
2. Prefer a tiny front-end plugin with kill switches over patching a theme in place.
3. Keep transforms pure and testable: lint, compatibility scan, unit tests on saved HTML, a local WordPress stub, and headless Chrome.
4. Prove feed, REST, and login are unchanged, and that deactivating restores byte-identical HTML.
5. Purge the page cache after every activate or deactivate on production.

FAQ

Why not just edit the theme?

Theme edits are fragile across updates and hard to test in isolation. A plugin you can deactivate to revert, with a kill switch for each fix, is the reversible patch I wanted. It’s also much easier to review when an agent wrote it.

Did the agent install it on its own?

No. It built and tested the zip, then I approved the install. Once it was live, the agent re-crawled the site to confirm the before/after counts held on production.

Closest related Builders notes?

I Let an AI Agent Ship Live WordPress Pages and a www Redirect uses the same plugin-over-theme rule on a different project, and I Built an Admin-Only WordPress CRM With Cursor is another small AI-assisted WordPress plugin.