The advice going around the WordPress ecosystem is to prompt it and ship it, and AI coding assistants are wrecking site performance because of it. GitHub Copilot and Claude Code are impressive pieces of engineering. They are also a crutch for developers who have not yet learned the hook system or how WooCommerce behaves under a race condition.
Stephanie Kirmer wrote a piece on the seduction of these tools that landed uncomfortably close to home. I have spent the last few months refactoring codebases where an AI wrote a quick fix that grew into a site-wide fatal error. The AI is not really the problem. The problem is vibe coding, where understanding how the code works gets skipped because the output already looks finished.
The WordPress trap for AI coding assistants
These models learn from an ocean of generic PHP, and that is the trouble with AI coding assistants on WordPress. WordPress has its own laws: the Plugin API, the database abstraction layer, the REST API. A model can hand you valid PHP that wrecks a real site because it never reaches for a transient or sanitizes what comes in.
I audited a custom WooCommerce plugin recently where the developer had an AI handle a remote API call. The script worked in testing and read cleanly enough to anyone not looking for trouble. Under production load the site crawled, because nothing around that wp_remote_get call cached a response or handled an error.
I went through how this is playing out in Core in my breakdown of the WordPress 7.0 AI features and fatal errors.
The naive version
Ask an AI for a function that pulls data from an external API for a widget and you get something close to this. Syntactically fine, a bottleneck in practice.
<?php
// AI suggested this generic approach
function get_external_data() {
$response = wp_remote_get('https://api.example.com/data');
$body = wp_remote_retrieve_body($response);
return json_decode($body);
}
?>It runs on every page load, it never checks whether $response came back as a WP_Error, and it sets no timeout. The day that API goes down, your site hangs until the server gives up on it.
The refactor I actually ship
I treat AI coding assistants like a junior dev: read every line, then wrap the logic in the protection WordPress already hands you. A transient so the call does not repeat on every request, and is_wp_error() so a bad response does not take the page down with it.
<?php
/**
* A senior-level approach to external data fetching.
* Always prefix functions and use WordPress caching.
*/
function bbioon_get_stable_external_data() {
$cache_key = 'bbioon_api_data_cache';
$data = get_transient($cache_key);
if (false !== $data) {
return $data;
}
$response = wp_remote_get('https://api.example.com/data', [
'timeout' => 5,
]);
if (is_wp_error($response)) {
error_log('API Error: ' . $response->get_error_message());
return []; // Fail gracefully
}
$body = wp_remote_retrieve_body($response);
$data = json_decode($body, true);
// Cache the result for 1 hour to protect performance
set_transient($cache_key, $data, HOUR_IN_SECONDS);
return $data;
}
?>Productivity now, debt later
The seduction is real. Sitting there for 30 minutes writing a solid class is hard when a model will hallucinate one in three seconds. So the skill that pays now is the ability to audit code rather than produce it. Stop thinking logic through and the ability goes soft, and then you cannot work without the tool at all.
Use the AI for boilerplate and spend the time you save on architecture. Do not let it decide how your database is structured or in what order your hooks fire. You are the architect, and the AI is a very fast, slightly drunk intern.
If you want the Core side of this argument, I wrote about the WordPress 7.0 admin reskin debate.
If AI coding assistants are eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
Own the code you ship
AI coding assistants like GitHub Copilot are tools, not a replacement for knowing what you are doing. Let them speed up the typing, and never let them reach production without someone reading the diff. Keep the WordPress Developer Resources open as the ground truth, and hold on to one rule: code you do not understand is not code you own, it is technical debt you are renting.
