Make WordPress has published the official WordPress AI guidelines, and anyone watching the recent flood of automated pull requests will read that as overdue. I have spent more than a decade refactoring legacy code and cleaning up clever hacks, so I know how fast a tool turns into a bottleneck when nobody has a plan for it. The guidelines do not ban AI. They are a sanity check for the ecosystem.
The project is moving toward a human-in-the-loop requirement. Tools like GitHub Copilot or Claude are good at scaffolding and notorious for hallucinating hooks or skipping security patterns like nonces and sanitization. So the core principles come down to responsibility, transparency and licensing.
The core principles of the WordPress AI guidelines
The documentation lists five pillars that contributors, and plugin developers too, should know by heart. The one that matters most is plain: you are responsible for your contributions. If AI hands you a race condition that breaks a site’s checkout flow, “the bot did it” will not cover you. Understand every line you ship.
- Disclose AI assistance in the PR or Trac ticket when it meaningfully shaped your implementation.
- Everything you contribute has to stay GPLv2-or-later compatible, which becomes a real problem if your AI tool learned from non-permissive code.
- Quality counts more than volume. The project is explicitly rejecting AI slop, meaning the low-effort, high-volume code dumps with no human judgment in them.
I wrote earlier about Using AI Coding Tools for Developers, which covers where this fits into a working setup.
A technical example: naive AI versus senior dev
AI tools regularly suggest functions that look right and then fail in a WordPress context. Take saving a custom setting through an AJAX hook. The generated version often skips unslashing, or reaches for a generic PHP filter where WordPress has its own wrapper.
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 version that follows 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');That is the whole point of the WordPress AI guidelines. The tool drafts, the human reviews and signs off. On keeping standards up, see my guide on WordPress Plugin Standards.
Licensing and the GPLv2 barrier
Licensing is where this gets legally messy. WordPress core is strictly GPLv2-or-later. If a tool produces code it learned from a repository under a restrictive license such as CC-BY-NC, you cannot legally contribute that code to WordPress. The guidelines say it directly: do not use tools that launder incompatible licenses.
If the WordPress AI guidelines are eating your dev hours, hand the work to me. I have been wrestling with WordPress since the 4.x days.
What this means for contributors
The WordPress AI guidelines accept that AI is staying and insist a human stays the gatekeeper. Don’t ship code you cannot explain, and weigh long-term maintainability against the speed of a prompt. The official Make WordPress AI Handbook has the full text.
