The Make WordPress team recently published the official WordPress AI Guidelines, and if you have been watching the influx of automated pull requests lately, you know this was long overdue. As someone who has spent over a decade refactoring legacy code and fixing “clever” hacks, I have seen how quickly a tool can become a bottleneck if used without a roadmap. These guidelines are not a ban on AI; they are a sanity check for the ecosystem.
Specifically, the project is moving toward a “human-in-the-loop” requirement. AI tools like GitHub Copilot or Claude are excellent for scaffolding, but they are notorious for hallucinating hooks or ignoring critical security patterns like nonces and sanitization. Consequently, the core principles focus on responsibility, transparency, and licensing.
The Core Principles of the WordPress AI Guidelines
The documentation outlines five pillars that every contributor—and honestly, every plugin developer—should memorize. However, the most critical one is simple: You are responsible for your contributions. If an AI generates a race condition that breaks a site’s checkout flow, “the bot did it” is not an excuse. You must understand every line of code you ship.
- Disclosure: If AI meaningfully assisted your implementation, you must state it in the PR or Trac ticket.
- License Compatibility: All contributions must remain GPLv2-or-later compatible. This is a massive “gotcha” if your AI tool was trained on non-permissive code.
- Quality Over Volume: The project is explicitly rejecting “AI slop”—low-effort, high-volume code dumps that lack human insight.
Furthermore, you should check out my previous thoughts on Using AI Coding Tools for Developers to see how this fits into a professional workflow.
A Technical Example: Naive AI vs. Senior Dev
I often see AI tools suggest functions that look correct but fail in a WordPress context. For instance, consider saving a custom setting via an AJAX hook. A typical AI might skip unslashing or use a generic PHP filter instead of a technical WordPress wrapper.
The Naive Approach (What AI often outputs):
<?php
// Missing nonces and proper sanitization
function bbioon_save_settings() {
$value = $_POST['my_setting'];
update_option('bbioon_option', $value);
wp_send_json_success();
}
add_action('wp_ajax_bbioon_save', 'bbioon_save_settings');The “Sane” Approach (Following WordPress Standards):
<?php
function bbioon_save_settings_v2() {
check_ajax_referer('bbioon_secure_nonce', 'security');
if ( ! current_user_can('manage_options') ) {
wp_send_json_error('Unauthorized');
}
// AI often forgets that WordPress adds slashes automatically
$value = isset($_POST['my_setting']) ? sanitize_text_field(wp_unslash($_POST['my_setting'])) : '';
update_option('bbioon_option', $value);
wp_send_json_success();
}
add_action('wp_ajax_bbioon_save', 'bbioon_save_settings_v2');Therefore, the WordPress AI Guidelines emphasize that AI is a co-pilot, not the captain. For more on maintaining high standards, see my guide on WordPress Plugin Standards.
Licensing and the GPLv2 Barrier
Licensing is where things get legally messy. WordPress Core is strictly GPLv2-or-later. If an AI tool outputs code that it “learned” from a repository with a restrictive license (like CC-BY-NC), you cannot legally contribute that code to WordPress. The new guidelines make it clear: do not use tools that “launder” incompatible licenses.
Look, if this WordPress AI Guidelines stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway
The WordPress AI Guidelines are a practical framework for the future. They acknowledge that AI is here to stay but insist that human intuition and technical expertise remain the primary gatekeepers. Don’t ship code you can’t explain, and always prioritize the long-term maintainability of the project over the short-term speed of a prompt. If you’re looking for more technical deep dives, the official Make WordPress AI Handbook is the ultimate source.
