The WP AI Client is being treated like another API update. Read the WordPress 7.0 proposal and it looks more like a shift in core architectural philosophy. I have watched enough “revolutionary” features arrive and leave to know that the implementation details decide how it lands, and these details involve bundling third-party dependencies.
The recent AI contributor meeting surfaced real friction over the merge. After a decade of refactoring legacy codebases, I read the concerns about review velocity and technical rigor as the main defense against a maintainability nightmare rather than as red tape. Shipping this too fast means shipping debt alongside the feature.
The dependency dilemma and core inclusion
The loudest debate is whether the WP AI Client belongs in core at all. WordPress has always been cautious about bundling external libraries. The proposal argues that core inclusion is what makes the thing accessible, and that it avoids the long-term maintenance “stacks” that leave end users confused.
I have written before about why WordPress 7.0 needs this foundation, and the core versus plugin question still stands. Iterating quickly inside core risks backward compatibility. Staying a plugin means giving up the standard status that moves the ecosystem along. The compromise on the table is a smaller third-party dependency footprint, which also answers the CI/CD complaints.
Namespaces: LLM context versus WordPress precedent
Nested namespaces are the current tug-of-war. The WP AI Client team first pushed for a nested structure such as core/settings/get, on the grounds that LLMs and agentic workflows do better with clear contextual signals. WordPress precedent is flat, and it has been flat for a long time.
The registration syntax shows the split plainly. Flat naming and nested naming send developers down two different paths for the same API.
<?php
/**
* Example of the Ability Naming Dispute
* bb_prefix used to denote potential architectural choices.
*/
// The Proposed Nested Structure (Better for LLMs)
$nested_namespace = 'core/settings/get';
// The Standard WordPress Approach (Flat)
$flat_namespace = 'core-settings-get';
// Why it matters: LLMs can "chunk" the nested version more effectively
// to understand that 'settings' is the domain and 'get' is the action.
function bbioon_register_ai_ability( $name ) {
// Logic to register the ability...
}Abilities update: the first write-capable ability
Merging the get settings ability was the hello world moment. The real test is update settings, still in progress, and the first ability that can write. Handing an LLM the power to modify a database is where AI integration turns messy and, depending on the site, dangerous.
The post ability has been pushed to WordPress 7.1, which I think is the right call. The REST API has never exposed the query complexity that deep AI analysis wants, and forcing that into the 7.0 cycle with Beta 1 due February 19th would invite exactly the race conditions nobody wants to debug during a release week.
Technical takeaway for developers
If you are not testing the WP AI Client PR yet, March will be catch-up month. Run it with the provider plugins for Anthropic or OpenAI and leave feedback tied to something you actually built. Concrete use cases are what will settle the bloat question.
If the WP AI Client is eating your dev hours, I can take it on. I have been working with WordPress since the 4.x days.
Final thoughts
The push for AI literacy inside the contributor group counts for something. Less black box magic, more knowledge that survives the next release. Whether you are at WordCamp Asia or reading the Make posts, the aim is a technical foundation that fits how core already works. Watch the namespace discussion in particular, because it will set the DX (Developer Experience) for the next five years.
