# Can WordPress Studio Code Build This Website (Welcher) > [!question] Lingering Questions > - Has WordPress Studio since published a documented threat model for the local custom-domain feature raised as a security concern in this stream? > - How does this stream's block-bindings-first hierarchy compare against Kevin Bossenger's companion Studio Code stream — agreement or divergence on the same tool? > - Is "AI-code dependency = plugin dependency" (Welcher's framing) actually right, or does platform-integrated AI output carry systematically different risk than a bespoke third-party plugin? > [!tip] Article Ideas > - The unresolved on-stream debate (AI-code dependency vs. plugin dependency: same risk or different?) as a standalone piece — neither position was resolved live, both stated as opinion. > [!link] Cross Reference > - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — real-time trust-calibration exercise for an agentic coding tool during its beta > - [[3. Resources/Permanent Notes/Primitive-First Design Absorbs Conflicting Feedback Without Scope Creep]] — same "prefer composable primitives over bespoke systems" discipline, applied to WordPress's own block-bindings API rather than to a separate product's user feedback > [!quote] Vocabulary > - **Block bindings** — the core WordPress API connecting block attributes to external data sources without a custom block; the stream's clearest example of the agent defaulting to WordPress-native architecture unprompted > - **Studio Code** — WordPress.com's agentic coding assistant embedded in WordPress Studio, evaluated here during its free beta ## Bibliographic capsule Ryan Welcher live-streamed roughly 108 minutes of building a real website — a roster site for his son's special-needs hockey team — using WordPress Studio's agentic assistant "Studio Code" as close to exclusively as he could manage: fixing a mislabeled AI-generated starter theme, standing up a custom post type and taxonomy, watching the agent both over-reach (installing a plugin, writing PHP metaboxes) and self-correct (block editor slot-fill API, block bindings unprompted), finishing with a tabbed, team-filterable roster pattern on the Advanced Query Loop plugin. ## Author's thesis This is a real-time trust-calibration exercise for an agentic WordPress tool: what it gets right without being told, what it defaults to that the developer has to override, and what an experienced developer's steering instructions look like in practice — a knowledgeable operator in the loop, not the tool alone, is what keeps the output aligned with WordPress best practice. ## Key arguments (≤3) 1. **Dependency risk is contested, not resolved, on stream.** Welcher argues AI-generated code and third-party plugins carry equivalent lock-in risk; a chat participant argues WordPress already has a plugin over-dependency problem AI won't fix. Neither position wins. 2. **The tool's best moment was an unprompted architectural default.** Choosing block bindings without being told to is the single clearest positive data point for the tool matching best practice on its own. 3. **A live, undocumented risk-acceptance decision got made informally.** A named security concern about Studio's local-domain feature is engaged seriously, then set aside as out of scope — a real risk call, made on camera, without documentation. ## Claim atoms ### Plugin dependency and AI-code dependency are treated as equivalent > [!quote] ID:rw_h1_wpcc_studio_code > We have plug-in lockin syndrome that we have in in the WordPress world. Where/why: ~00:25:29, immediately after the agent's unprompted Custom Post Type UI plugin install was reversed. Anchors Welcher's core thesis for the plugin-lock-in segment; directly relevant to any WordPress dependency-risk or plugin-review policy discussion. ### Studio Code chose block bindings without being told to > [!quote] ID:rw_h2_wpcc_studio_code > It's doing bindings for me. That's amazing. I didn't tell it to do bindings. Where/why: ~00:55:23, building the roster pattern from the players custom post type. The stream's single clearest example of the tool's architectural default matching best practice unprompted — a concrete positive data point worth testing for reproducibility. ### Block-bindings-first hierarchy over custom blocks > [!quote] ID:rw_h3_wpcc_studio_code > if you have to use a custom block, see if you can structure the block Where/why: ~00:46:25–00:47:11, answering an enterprise question about systems vs. hard-coded solutions. The most reusable, tool-agnostic idea in the source: prefer core block bindings, then a custom binding filter, then — only if necessary — a custom block built from bound inner blocks. ## Permanent candidates - **Prefer core integration over custom systems for long-term maintainability** — strongest candidate, supported by H3. No existing vault note covers this specific block-bindings-first maintainability claim. Promoted below. ## Processing checklist - [ ] Watch or read the companion Kevin Bossenger Studio Code stream and note agreement/divergence - [ ] Check whether WordPress Studio has published a threat model for the local-domain feature - [x] Connect into [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] ## Links - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — agentic coding tool trust calibration, real-time developer steering - [[3. Resources/Readwise/Articles/Can WordPress Studio Code Build This Website Live Test]] — source document