A client inherited an AI setup that was really just API calls held together with duct tape, and it kept breaking. Here is the architecture I use instead: provider interfaces and DTOs that let you swap AI models without rewriting everything.
A real question from WordPress Core AI work: should a shared AI adapter ship as a canonical plugin or a Composer library, and why that architecture choice shapes maintenance later.
WordPress.org has started running the Plugin Check tool on every plugin update, new and existing. A look at what the automated scans catch and how to run the same checks before you upload.
Tying a WordPress site to one AI provider’s SDK makes switching painful later. This walks through an abstraction layer with per-provider adapters so you can change models without rewriting your core code.
A hardcoded AI API key in front-end JavaScript is a security hole and a performance drag. This shows how to move the calls to a WordPress server-side proxy using the REST API and wp_remote_post.
How to add AI to a WordPress site with the WordPress AI Client SDK instead of hardcoded API keys and provider-specific code. Covers setup, credentials, and generating text.
Why AI integrations in WordPress often break after launch, and how a wrapper layer, caching, and proper error handling keep them stable when the underlying APIs change.
A prep checklist for the Core AI table at WordCamp US Contributor Day: the AI Building Blocks, the main project repos, and the Slack channel, so you can build instead of getting your bearings.
Wiring an AI into WordPress through generic CRUD endpoints got confusing and risky fast. Breaking actions into separate, per-post-type abilities with clear permissions gives the AI the precision it needs.
Notes on registering custom WordPress AI abilities now that categories are required, with a CRM example and why categorizing keeps integrations manageable.