A client came to me recently, excited about AI. They wanted to “slap some AI” onto their WordPress site, mainly on their sprawling e-commerce store: AI content, AI product descriptions, AI everywhere. Another developer had already taken a swing at it with an off-the-shelf plugin that promised a lot. What they got was a backend that crawled, product descriptions that read like every other product description, and alt text that had nothing to do with the images. They were frustrated, and so was I once I read the code.
None of this is an argument against AI. The question is how you integrate AI into WordPress without ending up with a bigger problem than you started with. My own first instinct was a custom plugin calling a big-name AI API directly, because that is the fastest way to get something on screen. Then I stopped myself. That road ends in vendor lock-in, and it means reworking the integration every time a model or an endpoint shifts.
Building WordPress AI features that hold up
A structured, flexible way to integrate AI is what the core team is now discussing, which is the part I have been following. The #core-ai Slack channel discussions are circling an experimental plugin aimed at WordPress 6.9, and the theme running through them is decoupling. They are starting with three things: content summaries, post titles and image descriptions. Sensible places to start, because each one is useful on its own and nothing serious breaks when a suggestion is wrong.
The piece that matters is the PHP AI Client in the middle. It is meant to cover local, browser-based and cloud services behind a common interface, so a plugin can ask for a summary of some content without knowing whether OpenAI, Gemini or an on-device model produced it. You are not tied to one provider, and swapping one out later becomes a configuration change rather than a rewrite.
What that looks like in code
Say you need alt text for an image. Rather than hardcoding a call to one service, you go through the interface WordPress hands you. Roughly this:
<?php
function bbioon_generate_image_alt_text( $attachment_id ) {
if ( ! class_exists( 'bbioon_AI_Client' ) ) {
return ''; // Or log an error.
}
$image_url = wp_get_attachment_image_url( $attachment_id, 'full' );
if ( ! $image_url ) {
return '';
}
$ai_client = new bbioon_AI_Client();
$alt_text = $ai_client->get_image_description( $image_url );
if ( ! is_wp_error( $alt_text ) && ! empty( $alt_text ) ) {
return sanitize_text_field( $alt_text );
}
return '';
}
// Example usage within a hook
add_filter( 'wp_generate_attachment_metadata', 'bbioon_auto_alt_text_on_upload', 10, 2 );
function bbioon_auto_alt_text_on_upload( $metadata, $attachment_id ) {
if ( ! get_post_meta( $attachment_id, '_wp_attachment_image_alt', true ) ) {
$generated_alt = bbioon_generate_image_alt_text( $attachment_id );
if ( ! empty( $generated_alt ) ) {
update_post_meta( $attachment_id, '_wp_attachment_image_alt', $generated_alt );
}
}
return $metadata;
}
?>bbioon_AI_Client is a placeholder there. Which service actually answers the request is not the caller’s problem, and that is the “low bar for implementors” jason_the_adams described in the Slack chat. A developer can add an AI feature without learning how the models work, and someone who does know can swap the provider or the model behind it.
The other requirement is that it feel native. As @jeffpaul pointed out, users should not have to jump out to another tab or another app. The AI tools belong inside the editor, block or classic, and they should be able to read relevant site data so the suggestions are worth accepting. It should fit the workflow people already have rather than replace it.
What this means for AI in WordPress
The excitement about AI in WordPress is fair. The implementation is where sites get hurt, and bolting on the first AI API you find is what produced my client’s crawling backend. What core is heading toward is a set of foundational capabilities that stay decoupled from any single service, which is exactly what you want when the services themselves keep changing. Extensibility and maintainability are the things to weigh before you pick a plugin, along with whether the feature is worth anything to the person using the site.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.
