Can WordPress Studio Code Build This Website? Live Test  🔗 **Source:** [Can WordPress Studio Code Build This Website? Live Test](https://www.youtube.com/watch?v=hrR77NyQzYs) > [!note]+ Document Notes > tags: [wordpress-studio, ai-assisted-development, block-bindings, custom-post-types, plugin-dependency, local-development] > author: Ryan Welcher > source: Ryan Welcher (livestream) > reference: https://www.youtube.com/watch?v=hrR77NyQzYs > date created: 2026-08-01 12:40 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > > [!warning] This is an unedited ~2-hour livestream with substantial live-chat interaction and > > extended off-topic tangents (Napster, Flash, doctypes, visa policy). Timestamps are > > approximate. Chat participants are identified only by handle and their remarks are > > paraphrased, not attributed as quotes. > > # 🏷️ Title: Can WordPress Studio Code Build This Website? Live Test > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [WordPress Studio](https://developer.wordpress.com/studio/) — local development environment; Studio Code is its built-in AI agent - [WordPress Playground](https://playground.wordpress.net/) — Studio is built on top of it - [Block bindings API](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-bindings/) — the central technical recommendation - [Advanced Query Loop](https://wordpress.org/plugins/advanced-query-loop/) — the presenter's own plugin, used in the build ## 📝 Summary - **What happened.** Ryan Welcher livestreams roughly two hours of building a real site — a roster page for his son's special-needs hockey team — using WordPress Studio Code, the AI agent built into Automattic's Studio local development tool, with a self-imposed rule to use it "as much as I can." - **Why it matters.** This is an unusually honest evaluation because it is unedited and the presenter corrects the tool live. Two findings stand out: the agent **reaches for PHP first** even inside the block editor, which he judges the wrong default; and it **spontaneously used block bindings** without being asked, which he calls out as better than what he had planned. - **Key stakeholders.** WordPress developers evaluating AI tooling; the Studio team (a member appears in chat); plugin authors, given the dependency debate; anyone weighing block bindings against custom blocks. - **Risks and tradeoffs.** The stream is a single anecdote by an Automattic developer advocate using an Automattic product, which he acknowledges. The build is a low-stakes personal site. Usage is free during beta, so the cost question is unanswered. - **Bottom line.** The tool handled a genuinely non-trivial build — custom post type, taxonomy, custom fields, a pattern with a bound query loop, and team tabs — with the presenter writing no code and only steering. The most durable takeaway is not the tool but his **block bindings decision tree** and his argument that integrating with core moves the maintenance burden onto core. ## 📖 Main Content **The setup, and the rule.** Welcher's constraint is to use Studio Code as much as possible. The starting point is a site whose theme was generated by Miles AI in an earlier stream, which amusingly still identifies itself as a "handmade jewelry site" in the theme metadata. The target is a roster section for the Aurelia Eagles, his son's team. He clarifies a point of confusion raised in chat: **Studio itself needs no WordPress.com account** — it is a local development environment like any other. A free account is required only for the connected features: previews, sync, and Studio Code's AI. He notes Studio is now on Linux, supports Blueprints (which he values for workshops because a single file spins up an identical environment for every attendee), is built on Playground, and now offers a native-PHP option that is faster than the default. Models available are Sonnet, Opus, and GPT 5.6; he runs Sonnet for most of the session and switches to Opus and then another model late on. He confirms, by asking the tool itself, that Automattic does not host the models — it relays requests to providers. A Studio Code CLI exists and can be run like any other agent harness. **What it built.** The work is not trivial. A custom post type for players, a taxonomy for teams (junior, intermediate, senior), custom fields for number and position, an admin list-table column showing the number, a pattern using his own Advanced Query Loop plugin to render the roster, randomized team assignment across players, and finally tabs to filter the roster by team. He writes no code — "I haven't written a line of code today but I've directed the code where I want it to be." **The two findings that matter.** First, the criticism: **"it is reaching for PHP first."** He is careful to say this isn't wrong in general, but it is the wrong default inside the block editor, where JavaScript is the appropriate tool. The concrete instance is the agent registering a PHP metabox for player details. Welcher rejects it explicitly — "I don't want it introduced via PHP. We are in the block editor. We should use the document settings panel slot fill" — and the agent rebuilds it correctly. His own reflection is that this preference belongs in an agent instructions file rather than being re-stated each time. Second, the praise: building the roster pattern, the agent **used block bindings without being asked**. Welcher notices mid-stream and is visibly pleased, noting he hadn't thought of it until afterwards. This is the reverse of the usual complaint about AI reaching for outdated patterns. **Annotate.** A Studio feature he repeatedly calls his favorite: it opens the site in a browser and lets you select an element visually and attach an instruction to it. He uses it to convert a hardcoded section into a query-loop-driven pattern and later to fix layout issues. The workflow — point at the thing, describe the change — sidesteps having to describe location in prose. **The block bindings decision tree.** Prompted by a chat question about writing a skill to guide a team on when to build systems versus hardcode, Welcher gives the most reusable content in the stream — an explicit ordering: 1. If you can use a **built-in block binding**, use it. 2. If not, use the **filter that allows binding anything to anything**. 3. If the functionality still doesn't fit, consider a **custom block** — and first check whether it can be structured with **inner blocks that themselves use bindings**. 4. Only if none of that works, build the block. His reasoning is a maintenance argument rather than a purity one: "the burden of maintenance falls on core to make sure block bindings are handled in an appropriate way." Because the project has a backwards-compatibility commitment, binding means you know it will keep working and you don't maintain that code. He adds the bus-factor case — inheriting a site where everything is custom and undocumented — and the aphorism "if you want to go alone, go fast. If you want to go far, go together." **The plugin dependency debate.** A chat participant argues 90% of plugins could be vibe-coded. Welcher partly agrees, naming "plugin lock-in syndrome" and observing that a plugin he'd just installed was immediately upselling him. But he draws a clear line: he would not rebuild WooCommerce, Yoast, or Akismet. His framing is "is the juice worth the squeeze" — you could, but core functionality at that level is a reasonable dependency. His sharpest move is to reframe the dependency objection entirely: "it's kind of the same as saying, oh, I don't want to depend on React. If you're depending on a framework that you didn't build, that's a dependency. Full stop." He also notes the twenty years of indexed WordPress development data as why AI does reasonably well here, with the caveat "unless you're using a really bad model." **Accessibility, raised by chat.** Asked whether he faces legal accessibility requirements, he correctly answers no for a personal project, then immediately says it should be accessible anyway "especially given the people that this is servicing." The discussion covers Canadian government AA/AAA requirements and the observation that accessibility-focused agencies gravitated to Drupal. His conclusion — "accessibility should just be a first thought instead of an afterthought" — is right, though notably the build itself does not include any accessibility work. **Cost, unanswered.** Late in the stream he discovers a usage indicator showing **1.55% of a monthly limit** consumed after roughly two hours of heavy use. Tokens are free during beta and there is no in-tool usage command; he doesn't know the roadmap for charging. So the economics are genuinely untested. **The part that isn't about software.** Explaining why he's building the site, Welcher describes the team: players from six years old to men in their forties, a sport he characterizes as often "wildly toxic," and this as "the biggest antithesis of that I've ever been involved with." They play games where, if not every kid has scored, both teams take penalty shots and the goalies are told to let them in. He describes a player who could not skate, accompanied on a skate aid, scoring a penalty shot. He gets audibly emotional and moves on. It is the most memorable content in two hours and has nothing to do with the tool. **Uncertainties and contested claims.** One presenter, one session, one low-stakes site, using his employer's product — all acknowledged. The free-beta pricing makes cost unassessable. Several chat claims (a security objection about custom domains, the 90%-of-plugins figure) are discussed without resolution. And the agent's late-stream work on tabs runs long enough that he switches models mid-task, so the comparison between models is not controlled. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=0) Pre-stream chat - Extended informal opening with regulars. Tangents on Luna/Prime games and stream setup before any work begins. #### ⏱️ [09:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=540) The rule and the starting point - Self-imposed constraint: "I am going to use studio code as much as I can." - The site's theme was generated by Miles AI on an earlier stream and still identifies itself as a "handmade jewelry site" — the first thing he fixes. - He asks Studio Code to explain the site, running Sonnet 5. #### ⏱️ [11:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=660) What actually requires a WordPress.com account - Corrects a chat misunderstanding: Studio as a local development environment needs **no** account and no .com connection. - An account is required for connected features — previews, sync, and Studio Code's AI. "It's free, the tokens are free for now, until it's out of beta." #### ⏱️ [12:30](https://www.youtube.com/watch?v=hrR77NyQzYs?t=750) Why he uses Studio — Blueprints - Now available on Linux, which he notes matters for conference workshops. - Blueprints are the reason he reaches for it: hand attendees one file and everyone spins up an identical site. "I don't know really of any other thing that makes it that simple." - Built on Playground; a newer advanced setting enables native PHP, which is faster. #### ⏱️ [18:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=1080) Planning the roster - The site is a single page with jump links and no posts. He decides players should be a custom post type so they can be queried. - Uses SuperWhisper to dictate the request rather than type it: a players post type, a team taxonomy with junior/intermediate/senior, and custom fields for number and position. #### ⏱️ [20:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=1200) A UX complaint - Enter inserts a newline; Command/Shift-Enter sends. "That's counterintuitive to everything I've ever done in ever in my entire life when it comes to chatting." - He trips over it repeatedly across the stream and suggests logging a bug. Shift-Enter appears to behave identically to Enter, which he flags as possibly broken. #### ⏱️ [22:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=1320) Built-in skills - Discovers Studio ships with agent skills (block development among them) already installed, plus site-level skill overrides and agent instructions. - His reaction: "I was like, wow, this is doing really well. If it doesn't know about any of this sort of stuff, that's pretty great" — the built-in WordPress knowledge explains the quality. - Mentions Context7 as a skill he uses constantly for documentation lookups. #### ⏱️ [24:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=1440) Trying a plugin instead - On a chat suggestion, asks it to install Custom Post Type UI and rebuild the post type there. It finds the plugin despite him getting the name slightly wrong, and does it. - His verdict: it worked and the setup was "clearly not a simple setup," but "I personally wouldn't use a plugin to manage my stuff here." He reverts to the custom plugin. #### ⏱️ [26:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=1560) Plugin lock-in syndrome - Agrees with a chat take that most plugins could be replaced by generated code: "We have plug-in lock-in syndrome that we have in the WordPress world." - Notes the plugin he just installed immediately tried to upsell him. "If you can write some code, write some code." #### ⏱️ [27:30](https://www.youtube.com/watch?v=hrR77NyQzYs?t=1650) Where he draws the line - Would not rebuild WooCommerce, Yoast, or Akismet. "Is the juice worth the squeeze?" You could, but why. - Cites twenty years of indexed WordPress development data as why generated code is usually fine — "unless you're using a really bad model." #### ⏱️ [28:30](https://www.youtube.com/watch?v=hrR77NyQzYs?t=1710) Reframing the dependency objection - "It's kind of the same as saying, oh, I don't want to depend on React. In my opinion, if you're depending on a framework that you didn't build, that's a dependency. Full stop." - Conclusion: some dependencies you simply accept, and the argument is about which, not whether. #### ⏱️ [31:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=1860) The PHP metabox problem - The generated plugin registers a PHP metabox for player details, which appears in the editor and looks wrong. - He rejects the approach outright: "I don't want it introduced via PHP. We are in the block editor. We should use the document settings panel slot fill to put that in and save the meta that way." - Concedes the PHP version is "completely valid" — the objection is fit, not correctness. Notes this preference belongs in an agent instructions file. #### ⏱️ [32:30](https://www.youtube.com/watch?v=hrR77NyQzYs?t=1950) The block bindings decision tree - Prompted by a chat question about writing a skill for when to build systems versus hardcode. - The ordering: built-in block binding → the filter that binds anything to anything → custom block, first checking whether it can use inner blocks that are themselves bound → only then a plain custom block. - Rules of thumb: "If you just want to show a piece of text, block binding. If you want to show a piece of post meta somewhere, block binding most likely." #### ⏱️ [34:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=2040) Why bindings — the maintenance argument - "The burden of maintenance falls on core to make sure block bindings are handled in an appropriate way." - Because the project commits to backwards compatibility, bound connections keep working and you don't maintain that code going forward. - Explicitly not advocacy: "I'm not saying that as a developer advocate that wants you to use core. I'm saying that as a person that has done exactly what you're talking about in real world projects." #### ⏱️ [35:30](https://www.youtube.com/watch?v=hrR77NyQzYs?t=2130) Bus factor and the aphorism - Raises inheriting a site where everything is custom and undocumented as the practical risk. - "If you want to go alone, go fast. If you want to go far, go together." Integrating with core is the more sustainable long-run choice. #### ⏱️ [38:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=2280) Annotate - Opens the site in a browser, lets him select an element and attach an instruction to it. "I absolutely love annotate." - Uses it to convert the hardcoded "meet your eagles" section into a query-loop-driven pattern using Advanced Query Loop. - Quirk: annotation must be toggled off before returning to the agent. #### ⏱️ [41:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=2460) The PHP-first criticism, stated generally - "There does seem to be it is reaching for PHP first, which I don't have a problem with necessarily, but it's not always the best tool for the job depending on when working especially when we're working inside the block editor." - His view: block editor work "needs to be JavaScript first because it's just a second-class experience when you're doing it in PHP." #### ⏱️ [45:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=2700) It reached for bindings unprompted - Inspecting the generated pattern: "Look at this. It's doing bindings for me. That's amazing. I didn't tell it to do bindings." - "That's pretty nice that it reached for bindings right away because that I didn't think about that until afterwards." #### ⏱️ [48:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=2880) The workflow observation - Watching it work: "Oh, is this how people build WordPress sites now? They just sit here and drink coffee and tell Claude to do stuff?" - Later, more precisely: "I haven't written a line of code today but I've directed the code where I want it to be." #### ⏱️ [50:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=3000) Pushback from chat, handled well - A viewer argues there are better tools than WordPress for a site like this. Welcher agrees rather than defends: "I don't disagree with you... this is just my tool of choice." - His stated reason is situational — he coaches the team, he knows WordPress, it's easy. "If I was trying to maximize profit and efficiency, yeah, I'd probably do some kind of static site." - Explicitly welcomes the disagreement. #### ⏱️ [52:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=3120) Why this team - A special-needs hockey team spanning a six-year-old to men in their forties. He is a coach; the person who runs it has done so for thirty years. - Notes hockey can be "wildly toxic," with the sports-parent behavior everyone recognizes. "This is the most... the biggest antithesis of that I've ever been involved with in my entire life." - They take penalty shots until every kid has scored, goalies instructed to let them in. He describes a player unable to skate, accompanied on a skate aid, scoring one. - "That's what it's about right, just making everyone feel good and have fun." He becomes audibly emotional and moves on. - Special Hockey International is an annual tournament; last year Toronto, in two years Finland — which they will need to fund. #### ⏱️ [60:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=3600) Long tangent - Extended nostalgia segment: Napster, Flash, Newgrounds, doctypes, editing index.php live over FTP, an agency client who merged staging into trunk immediately after a Git training session. - Also a substantive digression on passport privilege and visa difficulty, prompted by a chat participant with a Turkish passport. He names his own advantage directly: "I realize I'm super privileged with where I live." #### ⏱️ [85:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=5100) Accessibility, raised by chat - Asked whether he has legal accessibility obligations. Correct answer for a personal project: no. - Immediately adds it should be accessible regardless, "especially given the people that that this is servicing." - Discussion of Canadian government AA/AAA requirements, and that accessibility-focused agencies used Drupal for its framework. - "Accessibility should just be a first thought instead of an afterthought." Notably, no accessibility work is done in the build. #### ⏱️ [95:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=5700) Model choice and the CLI - Sonnet, Opus, and GPT 5.6 are the available options. He switches from Sonnet to Opus mid-task when the tabs work runs long, then tries another model. - A Studio Code CLI exists and can be run standalone with a configurable model. - Confirms by asking the tool that Automattic does not host models — it relays requests. "We don't host Claude or GPT models." #### ⏱️ [105:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=6300) The usage number - Discovers a previously unnoticed indicator: **1.55% of monthly limit used**, after roughly two hours of heavy use. - No usage slash-command exists. Free during beta; he doesn't know the charging roadmap. "I've been told it's free." #### ⏱️ [110:00](https://www.youtube.com/watch?v=hrR77NyQzYs?t=6600) The result - Working roster with tabs filtering junior, intermediate, and senior teams, driven by the custom post type through a bound query loop pattern. - Remaining nits are ordering and spacing — "the only things I've wanted to change so far have been personal preference things." - Asked to implement the Konami code as a closing gag, it produces something close but misses part of the sequence. ## 📚 References - [WordPress Studio](https://developer.wordpress.com/studio/) — including Studio Code and the CLI - [WordPress Playground](https://playground.wordpress.net/) — the underlying technology - [Blueprints](https://developer.wordpress.org/playground/blueprints/) — reproducible site setup, his main reason for using Studio - [Block bindings API](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-bindings/) — the central recommendation - [SlotFill / document settings panel](https://developer.wordpress.org/block-editor/reference-guides/slotfills/) — the correct place for post meta UI - [Advanced Query Loop](https://wordpress.org/plugins/advanced-query-loop/) — the presenter's own plugin - [Custom Post Type UI](https://wordpress.org/plugins/custom-post-type-ui/) — tried and then abandoned - [Context7](https://context7.com/) — the documentation-lookup skill he mentions using constantly ## 🗣️ Paraphrase - Welcher sets himself the rule of building a real site using WordPress Studio Code as much as possible. - Studio needs no WordPress.com account for local development; an account is required only for previews, sync, and the AI features, which are free during beta. - He values Studio primarily for Blueprints, which let workshop attendees spin up identical environments from one file. - The build target is a roster for his son's special-needs hockey team, on a theme previously generated by another AI tool. - He asks for a players custom post type, a team taxonomy, and custom fields for number and position, dictating rather than typing. - Studio ships with WordPress-specific agent skills already installed, which he credits for the quality of the results. - Trying Custom Post Type UI on a viewer's suggestion works, but he prefers his own plugin and reverts. - He agrees the ecosystem has plugin lock-in but would not rebuild WooCommerce, Yoast, or Akismet, asking whether the juice is worth the squeeze. - He reframes the dependency objection by pointing out that depending on React is equally a dependency, so the question is which dependencies to accept. - The agent registers a PHP metabox for post meta, which he rejects as valid but wrong for the block editor, directing it to use a SlotFill instead. - His general criticism is that the tool reaches for PHP first, when block editor work should be JavaScript first. - Asked how to guide a team on when to build custom, he gives an ordering: built-in binding, then the binding filter, then a custom block using bound inner blocks, and only then a plain custom block. - His justification is maintenance — core's backwards-compatibility commitment means bound connections keep working without your effort. - He raises bus factor as the practical risk of fully custom sites and summarizes with going fast alone versus going far together. - Annotate lets him select page elements visually and attach instructions, which he uses to convert a static section into a query-driven pattern. - The agent uses block bindings in that pattern without being asked, which he had not planned himself and praises. - Challenged in chat that better tools exist for this site, he agrees rather than defending, citing familiarity and context as his reasons. - He explains the team is special-needs hockey spanning a six-year-old to men in their forties, describing penalty shots taken until every child has scored. - Asked about accessibility, he correctly notes no legal obligation for a personal site but argues it should be accessible given who it serves. - Late in the session he finds a usage indicator showing 1.55% of a monthly limit after two hours, with tokens free during beta. - The finished roster filters by team through tabs, with remaining issues he characterizes as personal preference. ## 📰 Newsletter **An AI agent that reached for block bindings before the developer did.** Ryan Welcher spent two hours on stream building a real thing — a roster page for his son's hockey team — using WordPress Studio Code, the AI agent built into Automattic's Studio. Custom post type, team taxonomy, custom fields, a pattern driven by a query loop, tabs to filter by team. He wrote no code. "I haven't written a line of code today but I've directed the code where I want it to be." Two findings, and they cut opposite ways. **The criticism:** it reaches for PHP first. When he asked for player metadata, it registered a **PHP metabox** — perfectly valid, and exactly wrong inside the block editor. His correction is worth quoting as a prompt you may want to steal: *"I don't want it introduced via PHP. We are in the block editor. We should use the document settings panel slot fill to put that in and save the meta that way."* It rebuilt it correctly. His own conclusion is that this belongs in an agent instructions file rather than being said every time. **The praise:** building the roster pattern, it used **block bindings without being asked**. He noticed mid-stream and was genuinely surprised — "I didn't tell it to do bindings... I didn't think about that until afterwards." That's the reverse of the usual AI-reaches-for-outdated-patterns complaint. But the most reusable thing in the stream isn't about the tool at all. Asked how to write a skill guiding a team on when to build custom, he gave a clean decision tree: 1. Can you use a **built-in block binding**? Use it. 2. If not, use the **filter that binds anything to anything**. 3. Still doesn't fit? Consider a custom block — but first, can it be **inner blocks that are themselves bound**? 4. Only then, build the block. And the reasoning isn't purity, it's maintenance: *"the burden of maintenance falls on core to make sure block bindings are handled in an appropriate way."* Core's backwards-compatibility commitment means bound connections keep working and you don't maintain them. He's explicit he's not saying this as a developer advocate wanting you to use core, but as someone who's inherited fully-custom sites. Bus factor is the risk. Also good: when a viewer argued there were five million better tools for a site like this, he just agreed. "This is just my tool of choice... if I was trying to maximize profit and efficiency, yeah, I'd probably do some kind of static site." Refreshing from someone streaming their employer's product. One practical note: usage showed **1.55% of a monthly limit** after two hours of heavy use, and tokens are free during beta — so the economics are still genuinely untested. And the part that isn't about software at all. The team is special-needs hockey, ages six to forties. Welcher describes a sport he calls "wildly toxic" and this as "the biggest antithesis of that I've ever been involved with" — games where both sides take penalty shots until every kid has scored, goalies told to let them in, and a player who couldn't skate scoring one with a skate aid. He got choked up and moved on. Best two minutes of the stream. ## ✅ Action Items #### DevRel - Developer advocacy: the block bindings decision tree is a ready-made talk and a ready-made skill file; publish it as a standalone artifact. - Education: teach "JavaScript first in the block editor" as an explicit agent instruction, since the PHP-first default is now a reproducible AI behavior worth naming. - Developer experience: publish a WordPress agent-instructions template covering the SlotFill-over-metabox preference and the bindings ordering. - Developer marketing: not applicable to this source. - Community management: the way he handled tool-choice pushback — agreeing rather than defending — is worth modeling in community guidance. - Internal/external/cross-project: feed the PHP-first observation to the Studio team as a default-behavior issue, not a bug. #### OSPO - Policy & Governance: adopt "integrate with the platform where the platform commits to backwards compatibility" as an explicit build-versus-buy criterion. - License Compliance: not applicable to this source. - Security Management: AI-generated plugins entering production need review; the stream demonstrates generation without a review step, which is fine for a personal site and not for a client one. - Software Inventory: track which sites carry AI-generated custom plugins, since their provenance and maintenance story differ from vendor plugins. - Developer Support: document the bindings decision tree internally so teams stop relitigating custom-block decisions. - Community Engagement: not applicable to this source. - Strategic Alignment: the bus-factor argument is a real procurement criterion — measure how much of your estate is bespoke versus platform-integrated. #### Community - Maintainers: the plugin lock-in critique is worth engaging honestly; the immediate upsell he encountered is a real driver of the sentiment. - Contributors: agent instruction files are a low-barrier contribution — encoding project conventions helps every AI-assisted contributor. - Sponsors: fund block bindings documentation and examples; the API's value proposition is maintenance transfer and that is under-communicated. - Ecosystem: converge on shared WordPress agent skills so every developer doesn't write the same instructions. #### WordPress - Core: the PHP-metabox-versus-SlotFill confusion suggests core documentation under-signals the modern path for post meta UI. - Core Performance: Studio's native PHP option is noted as faster — worth benchmarking for local development guidance. - Core AI: **the directly applicable item** — publish canonical agent instructions for WordPress development, starting with JavaScript-first in the editor and the bindings ordering. - **Core Program Team:** not applicable to this source. - Mobile: not applicable to this source. - Playground: Blueprints are named as the single best thing about this workflow for teaching; invest accordingly. - Community: workshop-in-a-Blueprint is a proven pattern worth standardizing for meetups and WordCamps. - Training: turn the bindings decision tree into a Learn module; it answers a question learners ask constantly. - Marketing: not applicable to this source. - Support: expect an increase in AI-generated custom plugins in support requests. - Design: Annotate's select-an-element-and-describe-the-change interaction is worth studying as a design-feedback pattern. - Documentation: block bindings docs should lead with the maintenance argument, which is more persuasive than the technical description. - Photos: not applicable to this source. - TV: caption and chapter this stream; the substantive segments are buried in two hours of chat. - Polyglots: not applicable to this source. - Accessibility: **worth flagging** — the stream discusses accessibility thoughtfully and then builds a roster for a disability-serving organization without doing any accessibility work. That gap is the teachable moment. - Meta: not applicable to this source. - CLI: a Studio Code CLI exists; compare its ergonomics with WP-CLI for agent workflows. - Hosting: not applicable to this source. - Tide: AI-generated plugins are a new provenance category worth considering. - Themes: the theme metadata carrying a stale AI-generated description ("handmade jewelry site") is a small but real generated-artifact hygiene issue. - Plugins: the bindings-first ordering would reduce the number of near-duplicate custom blocks in the directory. #### The WPOCC - Programs: fund development of shared, open WordPress agent skills — the built-in Studio skills are proprietary to one tool. - Projects: publish the bindings decision tree as community guidance with worked examples. - Funding experiments: sponsor accessibility audits for community and nonprofit sites like the one built here, where obligation is absent but need is high. ### FAIR - Technical independence: Studio Code's AI is gated behind a WordPress.com account, which is a dependency worth naming in any independence conversation about tooling. - Policies and covenants: core's backwards-compatibility commitment is exactly the kind of covenant that makes platform integration rational — a useful precedent. - Productized governance artifacts: agent instruction files are becoming project governance artifacts; they encode conventions and deserve the same review as coding standards. ## 🧪 Hypotheses 1. AI coding agents default to PHP for WordPress tasks even where JavaScript is the appropriate tool, at a rate measurable across prompts and models. 2. Explicit agent instruction files reduce incorrect-paradigm output more than restating preferences per-prompt. 3. Sites built with block bindings require fewer compatibility fixes across major WordPress releases than equivalent sites using custom blocks. 4. Bundled domain-specific agent skills improve first-attempt correctness more than model capability alone, at equivalent model tiers. 5. Visual annotation interfaces reduce instruction ambiguity relative to prose descriptions of page locations. 6. Developers evaluating their own employer's tooling report fewer critical findings than independent evaluators, controlling for tool quality. ### 📊 Methodology - **H1:** Fixed prompt set covering block editor tasks, run across models, coded for PHP-versus-JavaScript approach. Cheap, and directly tests the stream's central criticism. - **H2:** Two-arm trial with and without an instruction file, same prompts, measuring corrections needed per task. - **H3:** Longitudinal tracking of matched sites across two major releases, counting compatibility fixes. This tests his maintenance argument, which is currently asserted from experience. - **H4:** Compare first-attempt correctness with skills enabled and disabled at fixed model tier. Studio's built-in skills make this directly testable. - **H5:** Task-completion study comparing annotation-based instruction against prose, measuring clarification rounds. - **H6:** Content analysis of tool evaluations by employed versus independent reviewers, coded for criticism density. Welcher's evaluation would score unusually high on criticism for an employee, making him a useful outlier case. ### ❓ Questions - Is the PHP-first default a model behavior, a Studio skill behavior, or an artifact of WordPress's training corpus skewing old? - What will Studio Code cost after beta, and does 1.55% per two hours imply a workable limit? - Do the built-in Studio skills exist anywhere open, or are they proprietary to the tool? - Would the bindings-first ordering hold for genuinely complex blocks, or does it break down past a certain interactivity threshold? - Does core's backwards-compatibility commitment actually extend to block bindings with the strength his argument requires? - What accessibility issues does the generated roster have, given nobody checked? - Does the Studio Code CLI produce the same results as the GUI, given the same model? - Is "twenty years of indexed WordPress data" a reason generated code is good, or a reason it reproduces outdated patterns — including PHP-first? ### 🔮 Future Research - Empirical study of paradigm defaults in AI-generated platform code, using WordPress's PHP/JavaScript split as a clean natural test. - Research into whether training-corpus age causes AI tools to recommend superseded patterns, which would explain both the PHP-first default and its apparent contradiction with the unprompted bindings use. - Comparative evaluation of agent instruction files versus bundled skills as mechanisms for encoding project convention. - Study of maintenance cost for platform-integrated versus bespoke implementations, which would test the core-carries-the-burden argument directly. - Investigation of visual annotation as an instruction modality, which is underexplored relative to chat and inline-comment interfaces. ### 💡 Implications - **Practice.** Write the agent instructions file first. The PHP-first default is reproducible enough that correcting it per-prompt is waste. - **Policy.** "Integrate where the platform guarantees backwards compatibility" is a defensible build-versus-buy rule that generalizes past WordPress. - **Security.** AI-generated plugins are entering codebases without review steps in the demonstrated workflow. Acceptable for personal projects; a policy gap for client work. - **Education.** The bindings decision tree answers a question learners ask constantly and currently has no canonical published answer. - **Funding.** Nonprofit and community sites like this one have real accessibility need and zero legal obligation — precisely the gap where funded audits would do the most good. ### 🧠 Learning Styles Assessment - Reading level estimate: **Flesch-Kincaid Grade ≈ 7.0**, Flesch Reading Ease ≈ 71. Very conversational, heavy disfluency and digression. The low score badly understates difficulty — the technical content assumes custom post types, taxonomies, SlotFills, block bindings, and query loops as known concepts. #### 👀 Visual learners - Present: the whole thing is screen-shared work — the agent's output, the editor, the resulting page, and Annotate's element selection. - Improve: the presenter repeatedly acknowledges the audience may not be able to read the screen ("Can you all read that? I don't actually know if I can zoom this in"). Zooming and larger fonts would help substantially. #### 🔊 Aural learners - Present: continuous narration and genuine dialogue with chat. - Improve: a two-hour unedited stream with long tangents is a poor listening ratio. An edited cut of the substantive segments would serve this group far better. #### 🗣️ Verbal learners - Present: several durable formulations — "is the juice worth the squeeze," "if you want to go alone, go fast; if you want to go far, go together," "plugin lock-in syndrome." - Improve: terms arrive undefined at pace — SlotFill, block bindings, query loop, Blueprints, taxonomy. A glossary or pinned links would help. #### 🧩 Kinesthetic learners - Present: strongest dimension. Everything is reproducible — Studio is free, the beta AI is free, and the tasks are ordinary. A viewer can follow along in real time. - Improve: publish the Blueprint for the starting state so viewers begin from the same place, which is exactly the workflow he praises Blueprints for. #### 🧠 Logical learners - Present: the bindings decision tree is a genuine, ordered decision procedure with stated reasoning. - Improve: the rest of the session is exploratory rather than structured. A stated plan at the top and a recap at the end would make the reasoning followable. #### 🧑‍🤝‍🧑 Social learners - Present: excellent. Chat drives real content — the Custom Post Type UI experiment, the dependency debate, the accessibility question, and the bindings decision tree all originate from viewers. - Improve: chat contributions are spoken but not shown to video viewers consistently; on-screen display or a summary would preserve them. #### 🧘‍♀️ Solitary learners - Present: works as background viewing; the tool is available to try alone. - Improve: no summary, no chapter list, no takeaway recap. A solitary learner must extract structure themselves from two hours. #### 🌿 Naturalistic learners - Present: not applicable in the usual sense, though the sustainability framing of maintenance burden is a genuine lifecycle argument. - Improve: the token-consumption question is raised but never connected to resource use; the 1.55% figure is discussed purely as quota. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: auto-captions exist. - Improve: captions garble names and terms badly — "Welchure" (Welcher), "Goodenberg" (Gutenberg), "Collad"/"Coll" (Claude), "metab boxes" (metaboxes), "slot fill," "Miles" for the AI tool, "AQL." Chat handles are mangled throughout, which misattributes contributions. **WCAG 2.2 AA 1.2.2**. #### Keyboard navigation - Present: standard player controls. - Improve: a two-hour stream with no chapters and roughly 40% tangent is the strongest possible case for chapter markers. **2.4.5 (Multiple Ways)**. #### Contrast and readability - Present: he zooms occasionally when prompted. - Improve: he explicitly doubts the audience can read the screen and continues anyway. Editor and terminal content at native resolution on a stream is largely illegible. **1.4.3**, **1.4.4**. #### Text resizing and reflow - Present: platform-level only. - Improve: none of the code or configuration shown is published as text. **1.4.4**. #### Media and captions - Present: captions; narration covers most actions. - Improve: substantial content is visual-only — what the agent generated, whether the roster rendered correctly, the Annotate selection. Chat messages are read aloud inconsistently, so audio-only listeners lose half the conversation. **1.2.3 / 1.2.5**. #### Forms and interactions - Not applicable to the recording. For the *built site*: the roster tabs are an interactive component built with no accessibility review — keyboard operability and ARIA semantics of those tabs are unverified. **2.1.1**, **4.1.2**. #### Standards reference - Media gaps: **1.2.2**, **1.2.3/1.2.5**, **2.4.5**. Product gap: the tab interface built during the stream is unaudited, which matters more than usual given the site serves a disability community — **2.1.1**, **4.1.2**, **2.4.3**. ### 🌍 DEIB Assessment #### Cultural breadth - Present: genuinely good and unforced. An extended chat exchange about passport privilege and visa difficulty — a Turkish-passport holder in the Netherlands, a South African colleague facing weeks-long processes — where Welcher names his own advantage directly: "I realize I'm super privileged with where I live." He also notes Canadians clear US customs on the Canadian side and can simply go home, which he identifies as luck rather than merit. - Improve: the cultural references (Napster, Newgrounds, Strong Bad, Fanshawe College) are North American and generational, and the nostalgia segment is long. #### Inclusive language - Present: consistently respectful. "To each his own, to each their own, I should say" — a self-correction made in real time and without fuss. Discussion of the special-needs team is person-centred and avoids inspiration framing. - Improve: heavy undefined jargon limits who can follow the technical content. #### Neurodiversity support - Present: the subject matter itself — a special-needs sports program described with evident respect and specificity. He describes accommodations (skate aid, penalty shots until everyone scores) as normal practice rather than exceptional kindness. - Improve: the stream's own format is hostile to attention differences — two hours, unstructured, rapid topic switching, overlapping chat, no chapters. There is an irony in a session about a disability-serving organization being difficult to consume for some disabled viewers. #### Representation - Present: chat participants from several countries shape the content substantively. Credit is given by name to viewers whose suggestions he acts on, and to a Studio team member who answers questions. - Improve: named individuals are predominantly men, and the technical community depicted is homogeneous. The team being built for is described but not heard from. #### Psychological safety - Present: the strongest dimension. He agrees with a viewer who says better tools exist rather than defending his choice, and explicitly welcomes the criticism: "I don't disagree with you and I am glad you're here." He criticizes his employer's product on stream. He self-deprecates about laughing at his own jokes, quoting his daughter. He admits not knowing current HTML doctype conventions. And the hockey segment models emotional openness — he gets choked up and says so rather than editing around it. - Improve: one chat participant is characterized as "a bit of a well actually type" and later "that guy was a clown," which is a mild departure from an otherwise generous norm. ### ✅ Logical Validity #### Strong reasoning - **Maintenance-transfer argument for bindings, [34:00].** The strongest reasoning in the stream. Rather than arguing bindings are cleaner, he identifies *who bears the maintenance cost*: core's backwards-compatibility commitment means bound connections keep working without your effort. He explicitly disclaims the advocacy motive and grounds it in inherited real projects, which raises rather than lowers credibility. - **Reframing the dependency objection, [28:30].** "If you're depending on a framework that you didn't build, that's a dependency. Full stop." This dissolves a false binary — the choice was never dependency versus independence but which dependencies are worth accepting. It reframes the chat debate onto better ground in one move. - **An ordered decision procedure, [32:30].** The bindings tree is a genuine decision procedure with a stated criterion at each step, not a preference list. It is the most transferable content in two hours precisely because it is falsifiable and followable. - **Distinguishing valid from appropriate, [31:00].** Rejecting the PHP metabox while conceding it is "completely valid" separates correctness from fit. Many critiques of AI output conflate the two; this one doesn't, which makes the criticism more useful. - **Conceding to a critic, [50:00].** Told there are better tools for this job, he agrees and states his actual reason — familiarity and context, not superiority — while noting that optimizing for efficiency would point elsewhere. Conceding a point that undercuts your own demo is strong practice. - **Correct answer plus the better question, [85:00].** Asked about legal accessibility obligations he answers accurately (none, personal project) and immediately supplies the more important consideration — that it should be accessible because of who it serves. #### Fallacies - **Appeal to data volume — [27:30].** "We've got 20 years of development data that's been indexed by every LLM on the planet," offered as why generated WordPress code is fine. **Weakness:** twenty years of data includes twenty years of *superseded* patterns, and this is very likely the cause of the PHP-first behavior he criticizes fourteen minutes later. Volume of training data is an argument for fluency, not for currency, and the stream contains its own counterexample. **Fix:** distinguish breadth of coverage from recency of practice. - **Hasty generalization from one session — throughout.** The tool's competence is assessed from a single build of a low-complexity personal site. **Weakness:** no comparison, no failure cases sought, and success criteria set by the operator during the run. He never attempts a task he expects it to fail. **Fix:** frame as an existence proof rather than an evaluation, and include a deliberately hard case. - **Undisclosed-in-the-moment conflict of interest — [50:00] onward.** He is an Automattic developer advocate evaluating an Automattic product. **Weakness:** his employer is stated elsewhere and known to his audience, and he criticizes the tool substantively, both of which mitigate it considerably. But the framing "I'm not trying to sell you on using Studio" appears early and does not carry an explicit conflict disclosure. **Fix:** state the relationship at the point of evaluation, not only in general. - **Anecdotal counterexample to a security claim — [235–240].** Responding to a security objection about custom local domains: "there are zero hackers thinking to install studio and create a WordPress install on someone's device in order to fake a domain." **Weakness:** an assertion about attacker behavior with no basis, dismissing a threat model rather than analyzing it. The practical-convenience argument is strong on its own and doesn't need this. **Fix:** address whether the threat is realistic rather than asserting no attacker would try. - **False equivalence — [240].** "It's the same reason why when we build out sites, everyone uses admin and password because nobody cares. No one's going to hack your local site." **Weakness:** weak local credentials and trusted-domain certificates are different risk categories; the latter can have effects beyond the local machine. **Fix:** treat the domain question on its own terms. - **Unsupported extrapolation — [105:00].** Discovering 1.55% of a monthly limit used, he treats the economics as unproblematic. **Weakness:** the limit's size is unknown, pricing after beta is unknown, and one session is not a usage profile. The number is presented as reassuring when it is uninterpretable. **Fix:** note that percentage-of-unknown-limit conveys nothing about future cost. #### Tone of voice - Loose, generous, and unusually self-critical for someone demonstrating their employer's product. The register is a working developer thinking aloud rather than a presenter delivering, which produces both the stream's best material — the unplanned bindings decision tree, the live correction of the PHP metabox — and its main cost, roughly 40% tangent. He is consistently deferential to chat, treating viewer suggestions as worth acting on rather than as interruptions, and he concedes points readily, including ones that undercut his demo. The tone shifts markedly at the hockey segment, where the humor drops entirely and he becomes emotional before deliberately moving on. Notably absent: any defensiveness about the tool's failures, and any claim that AI-assisted development is transformative — his framing stays at "I directed the code where I want it to be," which is a modest and accurate description of what happened. ### 🛡️ DARVO Analysis - **Deny:** Not present. The stream surfaces the tool's problems live rather than editing around them — the PHP-first default, the counterintuitive Enter behavior, the possibly-broken Shift-Enter, and a task that runs long enough to require switching models. - **Attack:** Present in a limited and non-DARVO form. One chat participant is characterized as "a bit of a well actually type" and later "that guy was a clown" — directed at a person's conversational style rather than at an accuser, and not part of any accusation-response sequence. Logged here for completeness; it is a lapse in an otherwise generous norm rather than a DARVO structure. - **Reverse victim/offender:** Not present. Challenged on his tool choice, he concedes rather than recasting himself as unfairly criticized. Presented with a security objection he disagrees on the merits, without characterizing the objector as attacking him. - **Emotional cues and rhetoric:** Warmth and concession dominate. The recurring move is agreeing with critics and then explaining his own reasons as situational rather than superior — structurally the opposite of a defensive posture. - **Assessment:** No DARVO structure present. Recorded per template requirements rather than omitted. ## 🎯 Conclusion - **Bottom line.** Studio Code built a genuinely non-trivial feature — custom post type, taxonomy, custom fields, a bindings-driven pattern, and team tabs — with the developer writing no code and only steering. The two findings worth carrying are opposed and both instructive: it defaults to PHP even inside the block editor, which is the wrong paradigm and probably a training-corpus artifact; and it reached for block bindings unprompted, which the developer hadn't planned himself. The most durable content isn't the tool review at all but the **block bindings decision tree** and its justification — that integrating with a platform which commits to backwards compatibility transfers maintenance burden away from you. - **Next steps for readers.** - Write the agent instructions file before the next AI-assisted WordPress build. "JavaScript first in the block editor; SlotFill not metaboxes for post meta" is worth encoding once. - Adopt the bindings ordering — built-in binding, then the binding filter, then a custom block with bound inner blocks, then a custom block — and use the maintenance argument, not aesthetics, to justify it. - Try Studio while the AI is free in beta, but don't draw cost conclusions from a percentage of an undisclosed limit. - If you build for a community organization with no legal accessibility obligation, audit it anyway. This stream discusses accessibility thoughtfully and then ships an unaudited tab interface for a disability-serving org — a gap worth not repeating. ## 🔄 Refactor Appendix — Can WordPress Studio Code Build This Website? > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Platform integration transfers maintenance burden to core > [!quote] ID:rw_studio_h1 > the burden of maintenance falls on core to make sure block bindings are handled in an appropriate way **Context & use**: - [34:00] — justifying the bindings-first ordering - The argument is economic, not aesthetic: core's backwards-compatibility commitment means bound connections keep working without your effort. Explicitly disclaimed as advocacy and grounded in inherited real projects. **Tags**: #xref #share #articleseed **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] AI defaults to PHP even inside the block editor > [!quote] ID:rw_studio_h2 > it is reaching for PHP first, which I don&#x27;t have a problem with necessarily, but it&#x27;s not always the best tool for the job **Context & use**: - [41:00] — the general form of the criticism; the concrete case is a PHP metabox for post meta at [31:00] - Probably a training-corpus artifact, which sits in tension with his own "20 years of indexed data" argument for why generated code is good. Fix belongs in an agent instructions file. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Every framework you didn't build is a dependency > [!quote] ID:rw_studio_h3 > if you&#x27;re depending on a framework that you didn&#x27;t build, that&#x27;s a dependency. Full stop. **Context & use**: - [28:30] — reframing the plugin lock-in debate - Dissolves the false binary. The question was never dependency versus independence but which dependencies are worth accepting — which is why he'd rebuild a small plugin but not WooCommerce or Akismet. **Tags**: #xref #aphorisms #share **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] The agent chose bindings without being told > [!quote] ID:rw_studio_h4 > It&#x27;s doing bindings for me. That&#x27;s amazing. I didn&#x27;t tell it to do bindings. **Context & use**: - [45:00] — inspecting the generated roster pattern - The reverse of the usual complaint about AI reaching for outdated patterns, and notable because he hadn't planned it himself. Sits oddly beside the PHP-first default — the same tool is ahead in one dimension and behind in another. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H5] Directing code is not writing code > [!quote] ID:rw_studio_h5 > I haven&#x27;t written a line of code today but I&#x27;ve directed the code where I want it to be **Context & use**: - [48:00] — describing the session's actual working mode - A modest and accurate description of AI-assisted development, notable for what it doesn't claim. The steering — rejecting the metabox, specifying SlotFill — is where his expertise showed up. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Integrate where the platform guarantees compatibility **Claim** (one sentence, Courtney's voice): Building on a platform API that carries a backwards-compatibility commitment moves the cost of future breakage from you to the platform, so integration beats customization wherever the API fits. **Evidence pointer**: [[#H1]] > [!quote] > if you want to go alone, go fast. If you want to go far, go together **Scope & conditions**: Holds where the platform's compatibility commitment is real and historically honoured, and where the API covers the need without contortion. Breaks where the commitment is nominal or the project is young enough that no track record exists. Also breaks where fitting the API requires so much distortion that the resulting code is harder to maintain than a bespoke implementation would have been — the ordering exists precisely to identify that boundary. **Links**: - [[Portability Is Proven by a Second Implementer Not by Design Intent]] — because extends: both concern whether a stated platform property can actually be relied on - [[Maintainer Attention Is the Scarce Resource in Open Source]] — because applies-in: integration is a way of not spending your own scarce attention on compatibility - [[A Project Is the Community Not the Code]] — because extends: the bus-factor argument is about legibility to future maintainers <!-- atomicity: 1 idea ✓ --> #### [P2] Training-corpus age biases generated code toward superseded patterns **Claim** (one sentence, Courtney's voice): A model trained on a platform's full history reproduces that history's older idioms, so volume of training data predicts fluency rather than currency. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds for mature platforms where a paradigm shift happened recently relative to the corpus — WordPress's PHP-to-JavaScript editor transition is close to ideal. Breaks where the newer pattern dominates the corpus by volume, and weakens where retrieval or bundled skills supply current documentation at inference time, which is exactly what the unprompted bindings use suggests was happening. **Links**: - [[Documentation is now dual-audience infrastructure]] — because contrasts: live documentation lookup is the counterweight to stale training data - [[When Answers Are Cheap Understanding Becomes the Scarce Good]] — because applies-in: judging whether generated code uses the current idiom is the understanding work - [[Knowing what not to ship is the scarce skill]] — because evidence-for: rejecting the valid-but-wrong metabox is exactly this judgment <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Write a WordPress agent-instructions file: JavaScript-first in the block editor, SlotFill not metaboxes for post meta, bindings before custom blocks. Reusable across projects. #articleseed #fleeting #inbox - [F2] The bindings decision tree deserves publishing as standalone community guidance — no canonical version exists. #articleseed #fleeting #inbox - [F3] Tension worth writing about: "20 years of indexed data" is offered as why AI is good at WordPress, and is probably why it defaults to PHP. #articleseed #fleeting #inbox - [F4] Are Studio's built-in agent skills published anywhere open, or proprietary to the tool? Matters for independence. #xref #fleeting #inbox - [F5] Accessibility gap worth noting kindly: thoughtful discussion, then an unaudited tab interface shipped for a disability-serving org. #fleeting #inbox - [F6] Special Hockey International is in Finland in two years and the team needs funding — non-technical, worth remembering. #fleeting #inbox - [F7] Annotate (select element → attach instruction) as an instruction modality — underexplored vs chat. #xref #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft a reusable WordPress agent-instructions file encoding JS-first editor work and the block bindings ordering — AI tooling setup #things - [ ] Try Studio Code while the beta is free and test it on a deliberately hard task, not an easy one — tool evaluation #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Can WordPress Studio Code Build This Website Live Test.md|Can WordPress Studio Code Build This Website? Live Test by Ryan Welcher]] ## Highlights - [00:25:29] plugin to do a lot of this stuff. Majority of it like it's a it's a dependency. We have plug-in lockin syndrome that we have in in the WordPress world. Um, like no shade on this plugin, but I I clicked on it and it was literally like already trying to get me to upgrade like um you know if I go oh oh it's gone which is fine because I don't want it anyways but um yeah I agree 100%. If you if you can write some code write some code and I also think that like what I'm doing here they put it in in a plugin but I don't think a a cloud-built plugin could be a worse dependency though. I don't think so. I think unless you're building something super edgy edge Casey or or super super complicated, the majority of WordPress information out there and the skills ([View Highlight](https://read.readwise.io/read/01kyj61q5mcr3rrzq4c9tgwf39)) - Note: [H1] Welcher's core thesis in the plugin-lock-in-vs-AI-code debate: WordPress's real dependency risk is its existing plugin-install culture, not AI-generated code per se ("we have plug-in lockin syndrome"). The claim gets complicated minutes later when the same agent defaults to outdated PHP metaboxes without being asked — so the "AI-built dependency isn't worse" position is tested and partly undercut within the same stream. Cross-link to the Bossenger /liberate stream, which recommends plugins (Events Calendar, WooCommerce) into migrated sites — the same lock-in dynamic from the tool's side. - Tags: atom/literature/h1, plugin-dependency-tradeoffs - [00:55:23] in patterns, I've got Oh, roster query. Is there templates in here? Got roster query. Okay. So, it's putting my advanced query loop in there. We'll see. Paragraph title. Oh. Oh my god. Look at this. It's doing bindings for me. That's amazing. I didn't tell it to do bindings. It's doing bindings. And it's doing a bindings here, too. So nice. I wonder how that's going to work. Oh, I wonder how that's going to work, though. That might get replaced. That's the the hash symbol. So, let's see. Let's see where this ends up here. Come on now. ([View Highlight](https://read.readwise.io/read/01kyj627pk6kth17vwrcez0dz5)) - Note: [H2] The stream's clearest positive data point: Studio Code chose core block bindings *unprompted* for the roster pattern — matching the architectural preference Welcher only articulates explicitly later ("if you can use a binding, use a binding... custom block last"). Worth testing for reproducibility rather than treating as proof of general good judgment, since the same session also reached for outdated PHP metaboxes elsewhere. The tension between these two moments is the real finding: the agent's WordPress architectural instincts are good on average but not reliably. - Tags: atom/literature/h2, block-bindings ## New Highlights added 2026-08-01 at 10:47 AM - know that that level of dependency on a website, that sort of core functionality level is is is I mean kind of the same as saying, "Hey, Cy." It's kind of the same as saying like, "Oh, I don't want to depend on React." In my opinion, like if you're if you're depending on a framework that you didn't build, that's a dependency. Full stop. Right? So, if you're if you're worried about like having too many dependencies and I know that you're just like, you know, we're just having a conversation here, but I I think that like there are certain things that you just accept, right? Um Yeah, exactly. ([View Highlight](https://read.readwise.io/read/01kyyv2wystpx4c52jwgp40c91)) - Note: [H3] Every framework you didn't build is a dependency. Dissolves the false binary in the plugin lock-in debate — the question was never dependency vs independence but which dependencies are worth accepting. Why he'd rebuild a small plugin but not WooCommerce or Akismet. - Tags: atom/literature/h2, atom/zettel/z1, plugin-dependency - that's usually the right solution. And I'm not saying that as a developer advocate that wants you to use core. I'm saying that as as a person that has done exactly what you're talking about like in in real world projects. I think that like the the the burden the maintenance of burden the burden maintenance the burden the burden of maintenance um falls on core to make sure block bindings are handled in an appropriate way. So if you've connected things in blockb bindings, you know that you're backwards compatible, which is because the the the project has that that um commitment to backward ([View Highlight](https://read.readwise.io/read/01kyyv291sefnrwpn5zp65eg02)) - Note: [H1] Platform integration transfers maintenance burden to core. The argument is economic, not aesthetic — core's backwards-compat commitment means bound connections keep working without your effort. Explicitly disclaimed as advocacy. Seeds Permanent candidate P1. - Tags: atom/zettel/z1, block-bindings, atom/literature/h1 - annotation off and then go back in. Okay. So, let's see what that does. Now, I I don't know if I gave it enough sort of Okay, so it found my plugin. That's That's cool. This is actually fairly straightforward [laughter] and it's been fun. So, uh so far a couple of things that I would change personally. Um there does seem to be uh there does seem to be it is reaching for PHP first, which I don't have a problem with necessarily, but it's not always the best tool for the job depending on when working especially when we're working inside the block editor. that needs to be JavaScript first ([View Highlight](https://read.readwise.io/read/01kyyv2hm574gqr9n2ae0dhs4m)) - Note: [H2] AI defaults to PHP even inside the block editor. Probably a training-corpus artifact — which sits in tension with his own "20 years of indexed data" argument for why generated WordPress code is good. Fix belongs in an agent instructions file. Seeds Permanent candidate P2. - Tags: ai-assisted-development, atom/zettel/z1, atom/literature/h1 - becomes a case of um like right now I haven't written a line of code today but I've directed the code where I want it to be except for the plug-in thing. I don't know if I'm super happy with that. I might merge that into the theme but uh like I took a look at what it built and I said I don't want it built that way. I want it built a different way and it just built it for me. And like honestly it doesn't matter in my opinion right now that I like if I don't have a build process it doesn't really matter. It's working fine. Um the one thing that did jump out to me was maybe I should be using the ([View Highlight](https://read.readwise.io/read/01kyyv3vp2fey6dd06qrbtjn2y)) - Note: [H5] Directing code is not writing code. A modest and accurate description of AI-assisted development, notable for what it doesn't claim. The steering — rejecting the metabox, specifying SlotFill — is where his expertise actually showed up. - Tags: ai-assisted-development, atom/literature/h2, atom/fleeting/f1 - Okay, so it's making Where is it putting it though? Is it putting it in patterns? Let's see. So, in patterns, I've got Oh, roster query. Is there templates in here? Got roster query. Okay. So, it's putting my advanced query loop in there. We'll see. Paragraph title. Oh. Oh my god. Look at this. It's doing bindings for me. That's amazing. I didn't tell it to do bindings. It's doing bindings. And it's doing a bindings here, too. So nice. I wonder how that's going to work. Oh, I wonder how that's going to work, though. That might get replaced. That's the the hash symbol. So, let's see. Let's see ([View Highlight](https://read.readwise.io/read/01kyyv3fshn7naavc65168jkct)) - Note: [H4] The agent chose bindings without being told. Reverse of the usual "AI reaches for outdated patterns" complaint — and he hadn't planned it himself. Sits oddly beside the PHP-first default: the same tool is ahead in one dimension and behind in another. - Tags: ai-assisted-development, atom/literature/h2, block-bindings ## Links - [[3. Resources/Permanent Notes/Intent Written on the Outside Compounds While Re-Derived Intent Is Debt]] — evidence-for: the presenter identifies PHP-first behavior as a preference that belongs in project instructions. - [[3. Resources/Permanent Notes/Accessibility Enforced at Authoring Time Beats Post-Hoc Auditing]] — qualifies: accessibility was endorsed but not demonstrated in the build itself.