Location: #core-ai Slack Channel
Agenda: No formal agenda
This summary covers the key discussion points from the last bi-weekly AI chat in the Make WordPress Slack. This week, the discussion focused on the PHP AI Client SDK.
1. PHP AI Client SDK – Project Status and Discussion
- @flixos90 started the chat with a discussion on the PHP AI Client SDK, recognized as the most concrete project currently.
- Participants were encouraged to review open issues and the PR detailing the proposed architecture.
2. Defining User Audiences: Extenders vs. Implementors
- @jason_the_adams highlighted a distinction regarding the SDK’s users and its impact on design:
- Extenders: Highly technical users who will extend the client by adding providers and models. The APIs for this group will be technical to ensure well-defined integrations.
- Implementors: Developers who want to use the client for features like generating alt text without needing deep knowledge of AI models. The goal for this API surface is ease of use and simplicity, minimizing the need to understand underlying AI complexities.
- @flixos90 clarified that the implementor API would still allow granular customization, but such advanced options would not be mandatory.
- @jeffpaul also noted that some users might operate at the intersection of both roles.
- The overall idea to “make the easy things easy, and the hard things possible” was reiterated as a guiding principle.
- The distinction between the two API surfaces is outlined in the SDK’s architecture requirements.
3. Fluent API vs. Traditional Method Calls
A significant part of the discussion revolved around the proposed shift to a Fluent API for the implementor surface, contrasting it with the traditional method call pattern inspired by the Vercel AI SDK.
- Fluent API Advocates: @jason_the_adams and @flixos90 provided code examples demonstrating the cleaner, more declarative, and readable nature of a Fluent API (e.g., `Ai::prompt(…)->generateImage();`).
- They agreed it would reduce errors and typos associated with nested arrays in traditional approaches.
- @borkweb later echoed strong support, noting its discoverability in IDEs.
- Proposed Approach: @flixos90 suggested updating the proposed architecture to prioritize the Fluent API while allowing the traditional method-based API as a wrapper.
- @jason_the_adams advised starting with the Fluent API first, as it’s easier to add the traditional API later than to remove it.
4. Token Usage and Response Metadata
- @dunhakdis raised the importance of standardizing token-usage data exposure, suggesting that the SDK should consistently provide metadata regardless of the AI provider.
- @jason_the_adams elaborated on three types of prompt returns:
- Result object: Contains comprehensive data and is synchronously returned.
- Operation object: For asynchronous, long-running requests.
- Ease-of-use method: Directly retrieves the intended value from the Result object.
5. Open Floor: Researching Triage Opportunities
- @karmatosed inquired about collaborating on research into AI systems for easing Core/Gutenberg ticket triage.
- @flixos90 suggested using GitHub discussions for these asynchronous conversations, a proposal @karmatosed welcomed.
Props to @jeffpaul for review.