I had a client come to me a few months back with a classic performance headache. Their WooCommerce store was lagging, but not because of the usual suspects. There were no oversized images and no bloated tracking scripts. It turned out to be five different plugins: one for SEO, one for translations, two for “chatbots,” and one for product descriptions, all hitting external LLM APIs on every save. Each one wanted its own API key, its own configuration and its own billing account.
My first thought was to build a custom wrapper to centralize the keys. If I could proxy the requests through a single utility class, I’d at least stop the redundant overhead. It sort of worked, but I was still chasing my tail every time a plugin update broke the integration. It felt like the early days of web dev, when you had to handle file pointers by hand because nobody agreed on a standard database. The problem isn’t the AI features. It’s that AI as a WordPress Fundamental doesn’t exist yet.
The “bring your own database” problem
Imagine if every plugin you installed asked for your MySQL credentials and wanted to create its own isolated database instance. We’d call that insane. In WordPress, the database is something you take for granted. You call get_post_meta() or hit $wpdb, and it works. You don’t care whether it’s MySQL, MariaDB or some cloud instance tuned for performance, because the platform abstracts that away.
AI in WordPress sits in that same phase today. We’re asking users to juggle Anthropic, OpenAI and Google keys just to generate some alt text, and the friction adds up fast. That is changing, going by the upcoming core AI roadmap. The direction is a setup where the LLM is one more service the environment provides, like the database or the filesystem.
Code that works (finally)
Instead of managing curl requests and headers, we’re looking at a standardized client. WordPress 7.0 is expected to ship the Ai_Client, which should cut out most of the debugging around weird timeout errors. Alt-text generation would look something like this:
/**
* Using the new AI Client to fix my client's messy alt-text problem.
* This is clean, abstracted, and standard.
*/
function bbioon_generate_smart_alt_text( $image_url ) {
try {
$alt_text = Ai_Client::prompt( 'Write a short, descriptive alt text for this image.' )
->with_file( $image_url )
->generate_text();
return esc_html( $alt_text );
} catch ( Exception $e ) {
// Fallback gracefully if no model is available
return '';
}
}The clean syntax matters less than the fact that the plugin developer never needs to know which model is running underneath. The host provides the engine and the code just runs. It also opens the door to “Abilities,” a concept coming in WP 6.9, which can be chained together into larger workflows without the usual integration spaghetti.
Why your host matters more now
If AI becomes a fundamental layer, the responsibility shifts to the hosting providers. A host that already manages your database performance and your backups will soon provide the AI model as part of the plan, which takes care of the API key fatigue and keeps these features fast enough to be worth using. Early versions of this are already around: the MCP (Model Context Protocol) Adapter helps different AI tools talk to your site’s data securely.
This stuff gets complicated fast. If you’re tired of debugging someone else’s mess and you just want your site to work with the next generation of tooling, drop my team a line. We’ve probably seen it before.
The shift from “AI as a feature” to “AI as a fundamental” is the biggest change to the WordPress architecture since the block editor. Chatbots are the least interesting part of it. What matters is that the ecosystem gets smarter by default and you stop spending your afternoons managing keys.
