The Modern WooCommerce Developer Workflow  🔗 **Source:** [The Modern WooCommerce Developer Workflow](https://www.youtube.com/watch?v=Bz5_gfDmkzA#transcript) > [!note]+ Document Notes > tags: [woocommerce-development, ai-coding-assistants, wordpress-blocks, local-development, developer-workflow] > author: James Kemp, Katie Keith > source: Do the Woo Podcast > reference: https://www.youtube.com/watch?v=Bz5_gfDmkzA > date created: 2026-07-16 10:47 > > # 🏷️ Title: The Modern WooCommerce Developer Workflow > <!-- deep-read:sections start --> ## 📝 Summary - **What happened.** James Kemp (Core Product Manager, WooCommerce) and Katie Keith (founder/CEO, Barn2) host Brian Coords (Developer Advocate, WooCommerce) for a 57-minute walkthrough of how WooCommerce development actually works in mid-2026: local environments, extending Woo safely, block-era extensibility, AI-assisted coding, MCP servers, and release/testing discipline. - **Why it matters.** WooCommerce has shifted from a PHP-hooks-and-filters-only extension model to a hybrid world of block-based cart/checkout, the Interactivity API, React-powered settings UIs, and AI coding agents (Claude Code, Codex) that can read an entire WordPress codebase. Agencies and freelancers building client stores need an updated mental model or they'll build brittle, unsupported customizations. - **Key stakeholders.** WooCommerce core/DevRel (Brian Coords, Luigi and other engineers referenced), the WooCommerce Community Slack, agency/freelance developers building stores for clients, plugin/extension authors, and hosts (Automattic/WordPress.com/Pressable) that manage staged rollouts. - **Risks and tradeoffs.** Directly editing the database or WooCommerce core breaks upgrade safety. Building on "experimental" feature flags risks wasted work if a feature changes or is scrapped (the Product Editor is cited as a cautionary tale). Letting AI agents freewheel on frontend markup or payment-adjacent code without human review risks brittle, unmaintainable, or risky output — especially since agents "can't literally see" visual/design quality. - **Bottom line.** The safe, durable path is: build on documented hooks/filters/blocks/Store API, use official local-dev tooling (WordPress Studio, Playground, Herd) and the Beta Tester plugin to track feature flags, lean on WooCommerce's own agent skills and MCP servers for AI-assisted development, test on staging with real payment gateways before shipping, and reserve "vibe coding from scratch" for low-stakes work rather than payments/subscriptions. ## 📖 Main Content - The episode moves from **local setup** → **extending WooCommerce** (hooks/filters, blocks) → **AI-assisted workflows** (agents, skills, MCP) → **testing and release discipline** → **community/contact info**. - **Local development**: Brian's own stack varies by task — WordPress Playground for disposable checks, the WooCommerce monorepo's bundled environment when working on WooCommerce itself, WordPress Studio for general site-building, and Laravel Herd as his primary daily driver. James Kemp uses a Raycast shortcut that spins up a fresh WooCommerce Playground site with test products in about 30 seconds. - **Feature flags**: WooCommerce ships some feature flags visibly in Settings → Advanced Features, but many more exist in the codebase and are only surfaced through the WooCommerce Beta Tester plugin. Brian's guidance: features above the "Experimental" tier are safe to build on; anything still Experimental is "alpha" — test it, report on it, but don't build production plugins on it. - **Extending WooCommerce safely**: the core rule is "if there's a function or filter or hook for it, use that — don't touch the database directly and don't hand-edit core/extension code," because that breaks safe upgrades. - **Block-era extensibility**: use WooCommerce's own blocks rather than rebuilding them; use documented JS filters to inject/alter block content; swap template parts; build custom blocks as a last resort. The Interactivity API is the long-term direction for front-end interactivity, though WooCommerce is still "in a bit of a middle ground." - **Agent skills**: the WooCommerce GitHub repo ships its own agent skills (backend-developer, frontend-developer) that guide coding agents on repo setup, coding conventions, and PR creation. - **Settings UI**: an internal tool auto-converts PHP-registered WooCommerce settings pages into React-powered UI components with a single line of code — shipped experimentally in 10.9, broader rollout expected ~11.0. - **Custom blocks**: WordPress 7's PHP-only block support is a lower-friction path for PHP-native developers, but AI coding agents are unusually good at React — "AI loves React," will reach for it even unprompted. - **AI's effect on daily workflow**: Brian gives agents WP-CLI access and browser access to self-verify before reporting done. A human is still required for taste, risk judgment, and visual/design quality — agents "can't literally see." Block themes (Ollie named specifically) are a guardrail constraining agents to design tokens. - **MCP servers**: WordPress core, WordPress.com/Jetpack, and WooCommerce all expose or are experimenting with MCP connections, mostly read-oriented today. Merchants mostly don't want to be designers — they want proven, converting patterns, which is why WooCommerce is building an internal block theme ("the purple theme") intended to replace Storefront. - **Testing and release discipline**: WooCommerce.com extensions must pass QIT (Quality Insights Toolkit) before release. Automattic auto-updates a small cohort of managed-hosting sites ahead of general release and monitors logs, catching real regressions (e.g., an old Stripe gateway version triggering errors on 10.9). - **Git, backups, and "vibe coding"**: Brian wants rollback capability (Git plus host-level backups, Jetpack's granular backup/restore named) and argues this is itself a reason to prefer trusted, maintained extensions over "vibe coded" custom replacements for payments/subscriptions-adjacent work. ### 🗒️ Notes #### ⏱️ [00:00:43](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=43) Welcome and topic framing - Hosts James Kemp and Katie Keith open the show; guest Brian Coords, WooCommerce Developer Advocate. #### ⏱️ [00:04:30](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=270) Local development stack options - Playground, WooCommerce monorepo bundled env, WordPress Studio, Laravel Herd. James's Raycast shortcut spins up a fresh Playground WooCommerce site with sample products in ~30 seconds. #### ⏱️ [00:07:49](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=469) WooCommerce Beta Tester plugin and feature flags - Lets any site try the next WooCommerce version/beta and toggle feature flags without pulling the full monorepo. #### ⏱️ [00:10:00](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=600) Feature flag lifecycle and build-on-experimental risk - Features past "Experimental" are safe to build on; Experimental-tier is alpha and can change or be scrapped (Product Editor precedent). #### ⏱️ [00:14:26](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=866) Best practices for extending WooCommerce safely - Use documented functions/filters/hooks; avoid touching the database directly or hand-editing core/extension code. #### ⏱️ [00:16:33](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=993) Block-era extensibility and the Interactivity API - Use WooCommerce's own blocks first; JS filters, template part swaps, custom blocks as extension points; Interactivity API is the long-term direction. #### ⏱️ [00:21:00](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=1260) Agent skills in the WooCommerce GitHub repo - Backend-developer and frontend-developer skills guide coding agents through repo setup, conventions, PR creation. #### ⏱️ [00:23:56](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=1436) Settings UI SDK: auto-converting PHP settings to React - Shipped experimentally in 10.9 (WooPayments first adopter); roughly one added line of code, no JS required from the extension author. #### ⏱️ [00:28:26](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=1706) Custom blocks: PHP-only blocks vs. React/JS - WordPress 7's PHP-only block authoring vs. AI's strong React bias. #### ⏱️ [00:30:38](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=1838) Do AI coding agents actually need "skills"? - Limited value for generic React/WordPress work; real value for WooCommerce-specific quirks (Interactivity API, Store API, checkout blocks). #### ⏱️ [00:33:25](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=2005) How AI has transformed Brian's daily workflow - WP-CLI + browser self-verification; human still required for taste, risk judgment, visual quality; block themes as a guardrail. #### ⏱️ [00:37:43](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=2263) MCP servers for WordPress and WooCommerce - WordPress core, WordPress.com/Jetpack, WooCommerce all exposing/experimenting with MCP; merchants want proven patterns, not novel design. #### ⏱️ [00:44:32](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=2672) The upcoming default WooCommerce block theme - "The purple theme," intended to eventually supersede Storefront. #### ⏱️ [00:45:38](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=2738) Testing and shipping code safely - QIT automated testing; staging environment with test payment gateway recommended for revenue-bearing stores. #### ⏱️ [00:48:54](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=2934) How Automattic staggers WooCommerce core releases - Small-cohort auto-update ahead of general release; caught a Stripe-gateway regression on 10.9. #### ⏱️ [00:51:12](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=3072) Git, backups, and the case against "vibe coding" payments - Git + host backups (Jetpack granular restore); trusted extensions over self-built payments/subscriptions replacements. #### ⏱️ [00:53:54](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=3234) Where to reach Brian and the Woo team - developer.woo.com, WooCommerce Community Slack. #### ⏱️ [00:56:04](https://www.youtube.com/watch?v=Bz5_gfDmkzA&t=3364) Next episode teaser: the Woo Marketplace - Aug 7, guests from Iconic and the Woo Marketplace team. ## 📚 References - [WooCommerce Developer Blog](https://developer.woo.com) - [Do the Woo Podcast](https://dothewoo.com) - [Brian Coords — WordPress Developer and Writer](https://www.briancoords.com) - [WordPress Playground](https://playground.wordpress.net) - WooCommerce Beta Tester plugin (referenced, not linked in episode) - QIT — Quality Insights Toolkit (referenced, not linked) - Laravel Herd (referenced, not linked) ## 🗣️ Paraphrase - WooCommerce development has split into two layers that both matter: the stable PHP layer (hooks, filters, the Store API, settings classes) that's safe to build on indefinitely if you stick to documented extension points, and a fast-moving block/React/Interactivity-API layer that's still settling — Brian's advice is to treat anything short of "shipped and out of Experimental" as unstable ground. - AI coding agents change the day-to-day mechanics more than the underlying discipline: give them WP-CLI and browser access so they can generate test data and self-verify, point them at WooCommerce's own agent skills for platform-specific gotchas, and let a well-defined block theme constrain their design output — but a human still has to supply taste, risk judgment, and anything visual, and still has to test real payment flows on staging before anything reaches a live, revenue-bearing store. ## 📰 Newsletter Building for WooCommerce in 2026 looks different than it did even two years ago — blocks, the Interactivity API, and AI coding agents have all reshaped the day-to-day. In this episode of Do the Woo, hosts James Kemp and Katie Keith sit down with Brian Coords (WooCommerce Developer Advocate) for a genuinely practical rundown: which local dev tool to reach for and when (WordPress Studio, Playground, or Herd), how to safely try WooCommerce's experimental features, the right way to extend blocks versus classic hooks and filters, and where AI agents actually help (WP-CLI + browser-driven self-testing, WooCommerce's own agent skills, MCP servers) versus where you still need a human — especially for anything visual or payments-adjacent. Brian's blunt take on vibe-coded checkout replacements: pay for a trusted, maintained plugin instead. Resources: developer.woo.com, the WooCommerce Community Slack, and the WooCommerce Beta Tester plugin. ## ✅ Action Items #### DevRel - Developer advocacy: Brian Coords' role model (bridging Woo engineers ↔ community via Slack, social, Reddit, conferences) is a reusable pattern for other plugin/platform DevRel programs. - Education: the WooCommerce agent-skills-in-repo approach (skills that teach agents *and* onboard human contributors simultaneously) is worth evaluating for other developer-tools projects. - Developer experience: the Settings UI SDK ("one line of code" PHP→React conversion) is a strong DX case study — track its 11.0 rollout. #### OSPO - Policy & Governance: WooCommerce's feature-flag tiering (hidden → Experimental → stable) is a clean, documentable governance pattern for pre-release API stability commitments. - Developer Support: QIT is a strong reference model for "developer support via tooling, not just docs." #### Community - Maintainers: WooCommerce's staged-rollout process (small-cohort auto-update, log monitoring, pause capability) is a release-hygiene pattern worth adapting. - Contributors: the WooCommerce agent skills for backend/frontend contribution function as a modern "first PR" onboarding path. #### WordPress - Core: the Interactivity API's WooCommerce integration is a concrete example of core/plugin-ecosystem collaboration. - Core AI: WordPress/WooCommerce's MCP experimentation (WordPress.com/Jetpack "battle testing" ahead of core) is directly relevant to Core AI guardrails/pilot-project work. - Playground: WordPress Playground's role as a disposable "quick vibe check" environment is a good real-world usage example. - Design: the "purple theme" and the design-guardrail pattern (constrain agents to theme tokens) are directly relevant to Design team UX-audit and design-token work. - Documentation: developer.woo.com's structure is a solid documentation/dev-relations hub model. - CLI: WP-CLI's role as the backbone of AI-agent-driven testing is a concrete example for CLI-team UX documentation. - Hosting: Automattic's staged-rollout/managed-WooCommerce-update process is a strong case study for cross-host reliability-checklist work. - Themes: the upcoming default WooCommerce block theme is directly relevant to Themes-team review/mentoring pipeline planning. - Plugins: QIT's cross-plugin/theme/version compatibility testing is relevant to Plugins-team security-liaison and provenance-check discussions. #### The WPCC - Not applicable to this source — no fellowship/microgrant/funding-model topics were discussed. ### FAIR - Not applicable to this source — no FAIR/federation topics were discussed. ## 🧪 Hypotheses - H1: Agencies/freelancers who build exclusively on documented WooCommerce hooks, filters, blocks, and the Store API experience measurably fewer breaking changes across major version upgrades than those who touch the database or core code directly. - H2: Coding agents given WP-CLI and browser access for self-verification produce fewer post-deployment bugs on WooCommerce customizations than agents used without those affordances. - H3: WooCommerce's staged managed-hosting rollout catches a materially higher share of real-world compatibility regressions than QIT's pre-release automated testing alone. - H4: Developers who constrain AI agents to a defined block theme's design tokens produce front-end output requiring less manual design cleanup than developers who let agents write custom CSS freely. - H5: WooCommerce extensions marketed as "trusted/maintained" have lower long-run total cost of ownership for merchants once ongoing compatibility maintenance is included, versus custom-built "vibe coded" equivalents. ### 📊 Methodology - H1: Retrospective analysis of support tickets/agency case studies coded for customization technique vs. upgrade-breakage incidents. - H2: Controlled study giving matched developer/agent pairs the same task, with/without WP-CLI + browser self-verification; measure defect rate. - H3: Compare Automattic's staged-rollout incident log against QIT's pre-release test results for the same release cycles. - H4: A/B comparison of front-end output between agent sessions with/without theme-constraint system prompts. - H5: TCO model comparing subscription cost + zero maintenance vs. build cost + tracked maintenance hours over 24 months. ### ❓ Questions - How will the Settings UI SDK's "one line of code" conversion handle genuinely novel/complex custom field types past 11.0 experimental status? - What does WooCommerce's MCP server roadmap look like once the broader protocol stabilizes? - Will the Interactivity API fully replace the current "middle ground" block-extension approach, and on what timeline? - How is "the purple theme" being tested for accessibility and conversion performance before replacing Storefront? - What percentage of Community Slack questions get answered by the actual engineer who built the relevant feature, and does that scale? ### 🔮 Future Research - Comparison of WooCommerce's agent-skills-in-repo approach against similar approaches from other major open-source platforms. - Longitudinal tracking of QIT catch-rate vs. staged-rollout catch-rate. - Merchant-side study on trust/adoption of AI-agent-built vs. human-designed WooCommerce stores, especially around checkout components. ### 💡 Implications - **Practice**: Developers should treat "Experimental" feature-flag status as a hard build gate, not a soft suggestion. - **Policy**: WooCommerce's staged-rollout model is a strong reference pattern for any platform managing high-blast-radius core updates across independently-customized installs. - **Security**: "Stay away from direct database/core edits" doubles as a security posture — undocumented, unaudited code paths are also unaudited attack surface. - **Education**: WooCommerce's own agent skills function as a de facto onboarding curriculum for new contributors. - **Funding models**: Brian's "pay for a plugin rather than vibe-code and maintain it yourself" argument is a direct case for the plugin/extension subscription economy over DIY replacement. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ≈ 9–10 (conversational, technical-but-plain-language spoken register). #### 👀 Visual learners - Present: none — audio-only conversation, no diagrams described. - Improve: a companion diagram of the extension-decision-tree (hooks/filters vs. blocks vs. custom blocks vs. Interactivity API) would help. #### 🔊 Aural learners - Present: the source is a podcast — strong native fit. - Improve: chapter markers at natural topic boundaries would help re-navigation of a 57-minute episode. #### 🗣️ Verbal learners - Present: strong analogy use ("AI loves React," "black background with a purple gradient"). - Improve: a glossary of undefined jargon (Interactivity API, Store API, QIT, HPOS) would help. #### 🧩 Kinesthetic learners - Present: concrete reproducible steps described (Beta Tester plugin, WP-CLI sample data). - Improve: a companion "set up a WooCommerce local dev environment in 10 minutes" checklist. #### 🧠 Logical learners - Present: feature-flag tiering and the extension-safety rule are clearly structured decision rules. - Improve: a decision-tree translating "which local dev tool for which task" into explicit branching logic. #### 🧑‍🤝‍🧑 Social learners - Present: three practitioners trading real experience, repeated pointers to the Community Slack. - Improve: an accompanying discussion thread tied to this specific episode. #### 🧘‍♀️ Solitary learners - Present: works fine as solo listening/reflection material. - Improve: a self-check ("which of these five extension mechanisms would you use for X scenario?"). #### 🌿 Naturalistic learners - Present: minimal — no ecosystem/sustainability framing. - Improve: not a strong fit for this content. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: not assessable directly (audio-only source). - Improve: if published with show notes, ensure heading structure and descriptive link text. #### Keyboard navigation - Not applicable to this source — audio content has no interactive UI of its own. #### Contrast and readability - Not applicable to raw audio content. #### Text resizing and reflow - Not applicable to raw audio content. #### Media and captions - Present: **this episode shipped with no captions and no host-published transcript at time of processing** — a real accessibility gap for a 57-minute technical episode. This analysis required generating a transcript via local Whisper ASR because none existed on YouTube or the show's own site. - Improve: publish official closed captions and a proofread transcript alongside the episode — the single most concrete, actionable accessibility improvement available for this source. #### Forms and interactions - Not applicable to this source. #### Standards reference - Primary gap maps to WCAG 2.2 SC 1.2.2 (Captions, Prerecorded) and SC 1.2.1/1.2.9 (Audio-only content — transcript) — both currently unmet for this video as published. ### 🌍 DEIB Assessment #### Cultural breadth - Present: single-region framing (US/UK WooCommerce ecosystem). - Improve: include non-US/UK case studies or guest perspectives in future episodes on this topic. #### Inclusive language - Present: generally plain, jargon-explained-in-context language; no exclusionary phrasing observed. - Improve: define acronyms (HPOS, QIT, MCP, SDK) on first use. #### Neurodiversity support - Present: conversational structure without hard topic breaks; no chapter markers evident. - Improve: add timestamped chapter markers. #### Representation - Present: three participants — two men and one woman — represents current core/agency/DevRel roles fairly but is a narrow slice of the broader contributor/merchant base. - Improve: future episodes could include a broader range of voices (a merchant, a non-Automattic-affiliated core contributor, a builder outside North America/Europe). #### Psychological safety - Present: collegial, respectful tone throughout; a brief warmly-handled interruption is treated with humor. - Improve: none needed. ### ✅ Logical Validity #### Strong reasoning - **Causal/practical reasoning** (~00:14:26–00:15:57): the argument that hand-editing database/core code breaks safe upgrades, illustrated with a concrete agency anecdote, is a clear cause-and-effect case grounded in real consequence. - **Analogical reasoning** (~00:27:12): the HPOS comparison — "if you were doing things the right way before HPOS, you didn't have to do too much work afterwards" — is used effectively to predict how the new Settings UI SDK will treat developers who already followed documented patterns. #### Fallacies - **Hasty generalization** (~00:47:16): "I know I have probably a dozen sites that have auto updates on, nothing happens... I think it's actually pretty safe to continue updating things." Generalizing platform-wide update safety from a personal sample of ~12 sites is a weak inductive base, even though the surrounding staged-rollout evidence is much stronger support for the same conclusion. Fix: lean on the staged-rollout data rather than the personal-anecdote framing. - **Appeal to personal experience presented as general rule** (~00:29:34, "AI loves React... it will use it if you don't ask it to"): stated as a general property of AI coding agents based on personal usage rather than any cited benchmark. Fix: frame as "in my experience" or cite a concrete benchmark. #### Tone of voice - Collegial, informal, and exploratory throughout — hosts and guest regularly hedge with "I think," "probably," "I don't know," which is intellectually honest but signals expert opinion and lived practice rather than rigorously benchmarked fact. ### 🛡️ DARVO Analysis Not applicable to this source — this is a collegial expert-interview podcast with no accusation, conflict, denial, or victim narrative present. ## 🎯 Conclusion - **Bottom line**: WooCommerce development in 2026 rewards developers who build strictly on documented, stable extension points and treat everything else — direct database access, Experimental-tier features, unreviewed AI-agent output — as provisional. AI agents (given WP-CLI and browser self-verification, WooCommerce's own agent skills, and a constrained design system) meaningfully speed up the mechanical parts of this work, but human judgment is still load-bearing for visual quality, risk assessment, and anything touching payments. - **Practical next steps for readers**: (1) install the WooCommerce Beta Tester plugin before building against any new feature and confirm it's past Experimental status; (2) audit existing customizations for direct database/core edits and migrate to documented hooks/filters; (3) if using AI coding agents, explicitly grant WP-CLI and browser access and load WooCommerce's agent skills; (4) set up a staging environment with a test payment gateway before any store update if real revenue is at stake; (5) reconsider "vibe coding" custom replacements for payments/subscriptions functionality against the maintenance cost of a trusted extension. ## 🔄 Refactor Appendix — The Modern WooCommerce Developer Workflow ### 📚 Literature Atoms (H3) #### [H1] Extend WooCommerce only through documented hooks, never the database > [!quote] ID:rw_Bz5_gfDmkzA_h1 > "If you find yourself writing, you know, actual database level code, like you're writing SQL commands, you're probably going down the wrong track." **Context & use**: - ~00:15:26 — Brian Coords, on WooCommerce extension best practice. - Direct DB/core edits break safe upgrades; the single most repeated rule in the episode. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] AI coding agents default to React even when not asked to > [!quote] ID:rw_Bz5_gfDmkzA_h2 > "AI loves to write React. AI loves React. It writes it very well. It will use it if you don't ask it to." **Context & use**: - ~00:30:04 — Brian Coords, comparing PHP-only blocks against React/JS blocks for AI-agent-assisted development. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Give coding agents WP-CLI plus browser access to self-verify > [!quote] ID:rw_Bz5_gfDmkzA_h3 > "You have WPCLI, which is a command line tool that lets you interact with everything inside of WordPress and Woo." **Context & use**: - ~00:34:30 — Brian Coords, describing his standard AI-agent setup. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] Trusted extensions beat vibe-coded replacements for payments code > [!quote] ID:rw_Bz5_gfDmkzA_h4 > "But I think this is a good argument for why people should not vibe code everything and stick to trusted extensions." **Context & use**: - ~00:51:48 — Brian Coords, on why he'd rather pay for a maintained plugin than self-build payments-adjacent functionality. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Build on the stable layer, treat everything else as provisional **Claim** (one sentence, Courtney's voice): When a platform exposes a documented, stable extension API alongside an evolving/experimental one, durable client work goes only through the stable layer, and anything built against the experimental layer is treated as throwaway until it graduates. **Evidence pointer**: [[#H1]] [[#H2]] **Scope & conditions**: Holds for any plugin/platform ecosystem with an explicit stability tiering; breaks down if the platform doesn't clearly mark stability tiers. **Links**: - [[AI agent workflow guardrails]] — because extends (constraining agents to a design system is the same "build on the stable layer" instinct applied to visual output) <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check whether WooCommerce's "Settings UI" reaches general availability in 11.0 as previewed. #xref - [F2] Look into whether Do the Woo / dothewoo.com publishes transcripts for other recent episodes — this episode had none at time of processing. #xref ### → Things 3 (max 2 actions) - [ ] Check developer.woo.com for the WooCommerce 11.0 changelog once released, to confirm Settings UI general-availability status — WooCommerce dev tracking #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/The Modern WooCommerce Developer Workflow.md|The Modern WooCommerce Developer Workflow by James Kemp, Katie Keith]] ## Highlights - If you find yourself writing actual database-level code, like you're writing SQL commands, you're probably going down the wrong track, and there's probably a safer way to do it. ([View Highlight](https://read.readwise.io/read/01kxnp73vyp8js7w5cb0gwaxg6)) - Note: Core extension-safety rule, repeated throughout the episode: use documented hooks/filters, never raw database code. - Tags: atom/literature/h1 - But I will say on the other side, if you do write JavaScript and React — AI loves to write React. AI loves React. It writes it very well. It will use it if you don't ask it to. ([View Highlight](https://read.readwise.io/read/01kxnp75kwy228qhwdkjxx9ac0)) - Note: AI coding agents default to React even unprompted — informs the PHP-only-blocks vs. React/JS decision. - Tags: atom/literature/h2 - if you have a local environment running, I tell it: alright, you have WP-CLI, which is a command-line tool that lets you interact with everything inside of WordPress and Woo, you have access to that, here's how to use it. You have access to the browser — open the browser, test the thing before you tell me it's done. ([View Highlight](https://read.readwise.io/read/01kxnp76yb8871je2195dgarhp)) - Note: Standard AI-agent setup: WP-CLI for test data generation, browser access for self-verification. - Tags: atom/literature/h3 - But I think this is a good argument for why people should not vibe code everything and stick to trusted extensions, because what's really nice about that is I don't want to have the work of checking that my code is going to work on every version — I'd rather pay whatever, $29 a year, for some plugin and let them deal with it. ([View Highlight](https://read.readwise.io/read/01kxnp78kqhppgp90zxz8ncx92)) - Note: Trusted, maintained extensions beat vibe-coded replacements for payments/subscriptions-adjacent work. - Tags: aphorisms, atom/literature/h4