Nobody Rips Out the Plumbing 🔗 **Source:** [Nobody Rips Out the Plumbing](https://regionallyfamous.com/nobody-rips-out-the-plumbing/) > [!note]+ Document Notes > tags: [WordPress, AI, web-development] > author: Regionally Famous > source: Regionally Famous > reference: [https://regionallyfamous.com/nobody-rips-out-the-plumbing/] > date created: 2026-02-15 00:00 > > # 🏷️ Title: Nobody Rips Out the Plumbing > <!-- 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 - Include links cited in or relevant to the article. ## 📝 Summary - What happened. - The author argues that AI will not “kill” WordPress because WordPress is the durable infrastructure layer (“the plumbing”) that modern sites still need. - Why it matters. - Frames AI as a collaborator that enhances WordPress, not a replacement, and urges the community to welcome AI builders. - Key stakeholders. - WordPress core contributors, agencies, plugin/theme developers, content creators, and AI-tool users. - Risks and tradeoffs. - Main risk is a defensive community that gatekeeps AI users instead of integrating them; tradeoff between tradition and rapid innovation. - Bottom line. - Nobody rips out working plumbing; AI will upgrade fixtures while WordPress remains the foundation, if the community stays open and welcoming. ## 📖 Main Content - Explain the core arguments in plain language. - The author spends most of their time building with AI tools yet never considers replacing WordPress with AI-generated sites. WordPress is compared to a house’s plumbing: boring but essential infrastructure that you don’t rip out during a remodel. Visible layers (design, themes, frontends) can be rapidly generated by AI, but they still need robust content management, users, media, SEO, and forms—things WordPress already does well. Historically, predictions of WordPress’s death (from mobile, Wix/Squarespace, Gutenberg backlash, JAMstack) have been wrong; instead, WordPress has absorbed each new wave and grown. AI will follow the same pattern if the community embraces it. - Add sourced context and define terms. - “Plumbing” = the stable backend: database, CMS, auth, content editing, plugin ecosystem. - “Curb appeal” = front-end experience: styling, components, layouts. - Historically: WordPress has grown from ~13% to 43%+ of the web despite multiple “WordPress is dead” cycles. - The article cites concrete features: Abilities API, MCP Adapter, a PHP AI Client SDK in core, and tools like Telex that convert natural language into Gutenberg blocks. - Note uncertainties or contested claims. - Long-term dominance of WordPress is not guaranteed; newer platforms could emerge if they combine AI-native design with robust infrastructure. - Adoption and impact of the Abilities API/MCP/SDK are early; their ecosystem success is still to be demonstrated. - The framing that Wix/Squarespace/JAMstack are only “rounding errors” ignores their importance in some niches and use cases. ### 🗒️ Notes - “WordPress is the plumbing.” The analogy: when you renovate a house, you redo fixtures and rooms but keep working pipes, wiring, and foundation. - WordPress has repeatedly survived “death” predictions: - Mobile: responsive themes helped usage grow during the iPhone era. - Wix/Squarespace: heavy marketing but small market share versus WordPress. - Gutenberg: internal backlash, but WordPress growth accelerated afterwards. - JAMstack: WordPress added the REST API and headless patterns and still grew. - AI can quickly generate full frontends, but then you need: - Content management. - User accounts and permissions. - Media handling. - SEO tools. - Form handling and data persistence. - Non-technical editing workflows. - The author uses AI to: - Build WordPress blocks. - Write plugin code. - Generate CSS and prototypes. - Speed up experimentation, not to replace WordPress. - WordPress core is already integrating AI: - Abilities API: makes core functions discoverable to AI agents. - MCP Adapter: allows tools like Claude to interact with WordPress. - PHP AI Client SDK: packaged AI access in core. - Telex: natural language → working Gutenberg blocks. - Strategic pattern: WordPress grows by absorbing new paradigms instead of resisting them. - Core question is social, not technical: - Will the WordPress community welcome AI builders or gatekeep them as “not real developers”? - WordPress is at its best when it is welcoming and permissionless for both bloggers and agencies. - The author clearly aligns with pro-AI inclusion: upgrade fixtures (themes, blocks, workflows) using AI instead of discarding the underlying WordPress “plumbing.” ## 📚 References - WordPress: https://wordpress.org/ - “Nobody Rips Out the Plumbing” (original article): https://regionallyfamous.com/nobody-rips-out-the-plumbing/ - WordPress Gutenberg project: https://wordpress.org/gutenberg/ - WordPress REST API overview: https://developer.wordpress.org/rest-api/ - Telex for WordPress blocks (conceptually referenced in article): https://telex.ai/ (or current official URL) ## 🗣️ Paraphrase - Paragraph A paraphrase. - The author, a heavy AI user, stresses they never think of replacing WordPress with AI-generated sites, because WordPress is the durable infrastructure behind everything. - Paragraph B paraphrase. - Over time, many trends were predicted to kill WordPress, but each time WordPress integrated the new capabilities, grew its share of the web, and demonstrated resilience that is now being repeated with AI. ## 📰 Newsletter WordPress keeps hearing the same old story: “this new thing will kill you.” The latest villain is AI. In “Nobody Rips Out the Plumbing,” Regionally Famous argues that WordPress is the plumbing of the web—solid infrastructure you don’t rip out when you remodel. AI is fantastic for fixtures: blocks, themes, frontends, and prototypes. What’s exciting is how fast core is leaning in. WordPress 6.9 ships with an Abilities API, an MCP Adapter so tools like Claude can talk to your site, and a PHP AI Client SDK to standardize integrations. Tools like Telex already turn plain-English prompts into working Gutenberg blocks. For builders and educators, this means: - Start teaching AI-assisted block and plugin development. - Update your workflows to pair AI with WordPress’s user, content, and media systems. - Welcome new contributors who arrive through AI tools, not just via PHP. Helpful links: - WordPress.org: https://wordpress.org/ - Gutenberg developer docs: https://developer.wordpress.org/block-editor/ - WordPress REST API: https://developer.wordpress.org/rest-api/ The plumbing is staying. Our job is to help everyone upgrade the fixtures. ## ✅ Action Items #### DevRel - Developer advocacy: - Create live demos of AI-assisted WordPress development (blocks, plugins, themes). - Propose talks for WordCamps on “AI as a WordPress collaborator, not competitor.” - Measure success via number of AI-integrated examples, GitHub stars, and workshop attendance. - Education: - Build short curricula on using Claude/Cursor with WordPress (block scaffolding, plugin skeletons). - Run office hours for agencies adopting AI in WordPress workflows. - Developer experience: - Provide SDK examples for the Abilities API and PHP AI Client. - Publish quickstarts for “Create your first AI-aware plugin” and “AI-generated Gutenberg block.” - Developer marketing: - Write case studies of teams that shipped faster by pairing AI with WordPress. - Track funnel from AI content → GitHub repos → deployment. - Community management: - Moderate discussions around “real developers” vs AI-assisted builders; enforce inclusive norms. - Survey developers on AI pain points inside WordPress. - Internal/external/cross-project: - Align messaging on AI across core, marketing, training, and hosting partners. - Establish feedback loops between AI-tool vendors and WordPress core teams. #### OSPO - Policy & Governance: - Document guidance on AI-generated contributions (code, docs) and review expectations. - Clarify decision rights for introducing new AI integrations in core or official plugins. - License Compliance: - Ensure AI tooling respects GPL obligations and compatible licenses. - Establish a scanning and review cadence for AI-generated code. - Security Management: - Set up vulnerability intake specifically for AI-integrated features (Abilities API, MCP, SDK). - Define embargo and disclosure processes for AI-related security issues. - Software Inventory: - Track where AI libraries and models are used in WordPress-related projects (SBOMs). - Define freshness SLOs for AI dependencies. - Developer Support: - Offer consultation hours for teams adopting AI models or SDKs in WordPress plugins. - Provide legal guardrails for data sent to third-party AI services. - Community Engagement: - Fund upstream AI-related work that benefits open CMS infrastructure. - Explore MoUs with AI providers around privacy and open standards. - Strategic Alignment: - Add AI–WordPress KPIs (e.g., number of active AI-integrated plugins, usage metrics) to OSPO OKRs. #### Community - Maintainers: - Host “roadmap clinics” on AI features (what belongs in core vs plugins). - Improve release hygiene for AI-integrated extensions (testing, documentation). - Contributors: - Create “first AI issue” rotations to onboard new contributors via small AI-related tasks. - Pair experienced PHP devs with AI-first newcomers. - Sponsors: - Offer sponsorship tiers for AI–WordPress experiments with transparent milestones. - Publish impact reports on funded AI tools that strengthen the ecosystem. - Ecosystem: - Run incident drills focused on AI features misbehaving or failing gracefully. - Coordinate security and privacy disclosures across hosting providers and large agencies. #### WordPress - Core: - Prioritize stable AI integration points (APIs, hooks) over one-off features. - Track performance and stability impacts of the AI Client SDK and MCP Adapter. - Core Performance: - Profile AI-related requests, ensure they don’t degrade TTFB or admin performance. - Build dashboards tracking latency and error rates for common AI tasks. - Core AI: - Define responsible AI guidelines (data handling, eval sets, opt-in defaults). - Launch pilot projects showcasing Abilities API in real-world workflows. - **Core Program Team:** - Coordinate AI work across release cycles; run retrospectives on AI features. - Maintain a public dependency graph of AI capabilities in core and official plugins. - Mobile: - Explore on-device AI-assisted editing or content suggestions within the WP apps. - Improve offline UX for AI-less editing, with sync once online. - Playground: - Add AI labs in WordPress Playground for experimenting with blocks and plugins safely. - Capture reproducible bug reports for AI-related tooling. - Community: - Provide meetup kits for sessions on “AI + WordPress.” - Encourage WordCamp tracks dedicated to AI in the WordPress stack. - Training: - Publish lesson plans on AI-accelerated WordPress development and content workflows. - Pilot badges or certificates for “AI-ready WordPress developer.” - Marketing: - Shape narratives around “WordPress is your AI-ready plumbing.” - Maintain an editorial calendar highlighting AI plugin success stories. - Support: - Update support playbooks for AI-related issues (tokens, rate limits, response quality). - Identify knowledge base gaps around AI integrations. - Design: - Provide UX patterns for AI prompts, results panels, and error states in the admin. - Run research on how non-technical users understand AI features in WordPress. - Documentation: - Fill DevHub/HelpHub gaps for Abilities API, MCP Adapter, and AI SDK usage. - Use examples-first patterns to show AI workflows end-to-end. - Photos: - Clarify guidelines for AI-generated images on WordPress.org Photos. - Tag and moderate AI content with clear taxonomy. - TV: - Encourage screencasts and talks demonstrating AI + WordPress workflows. - Ensure captions are present for all AI-related content. - Polyglots: - Coordinate translation sprints for new AI-related strings in core and plugins. - Maintain glossaries for AI terms across locales. - Accessibility: - Audit AI UI components against WCAG; ensure no hidden keyboard traps. - Provide guidance on using AI for accessible content (alt text suggestions, etc.). - Meta: - Ensure .org infrastructure reliably surfaces AI plugins/themes. - Improve contributor tools for discovering AI-related tickets. - CLI: - Add commands for managing AI integrations (keys, endpoints, health checks). - Document scaffolds for AI-aware plugins. - Hosting: - Coordinate default settings and telemetry for AI-heavy WordPress sites. - Offer reference architectures for AI-ready WordPress hosting. - Tide: - Consider AI-safety heuristics in plugin scoring. - Provide feedback loops for false positives on AI-related checks. - Openverse: - Clarify moderation policy for AI-generated media. - Provide educational content about AI licensing and attribution. - Themes: - Develop linting guidelines for AI-generated theme code. - Mentor theme authors experimenting with AI-based theme generation. - Plugins: - Prioritize review throughput for AI-integrated plugins. - Establish security liaisons for plugins handling AI tokens or PII. #### The WPOCC - Programs: - Create fellowship tracks for maintainers working on AI–WordPress interop. - Offer microgrants for experiments using AI to improve contributor experience. - Projects: - Host governance clinics around AI policies for big plugins and hosts. - Organize documentation sprints focused on AI features. - Funding experiments: - Pilot matched grants for AI tools that extend WordPress as “plumbing.” - Maintain transparent ledgers for AI-related funding decisions and outcomes. ### FAIR - Technical independence: - Encourage local metadata and provenance checks for AI-generated assets. - Promote signature or verification mechanisms for critical AI outputs. - Policies and covenants: - Define transparent funding policies for AI tooling in the ecosystem. - Include sunset clauses for experimental AI integrations in governance docs. - Productized governance artifacts: - Publish reusable charters and operator agreements for AI–WordPress collaborations. - Develop scorecards to evaluate AI tools’ fit with open, community-first values. ## 🧪 Hypotheses - H1: AI integration (Abilities API, MCP, AI SDK) will increase developer productivity for WordPress block and plugin development. - H2: WordPress’s share of AI-assisted site builds will grow faster than competing platforms that lack mature CMS plumbing. - H3: Communities that welcome AI-assisted developers will see greater contributor growth than those that gatekeep AI usage. - H4: AI will primarily transform the visible layers (themes/blocks) rather than displacing WordPress as backend infrastructure. - H5: Adoption of AI-aware APIs in core will correlate with growth in new plugins leveraging those APIs. ### 📊 Methodology - Study designs, data sources, and analyses to test the hypotheses. - For H1: - Run controlled studies where developers build the same feature with and without AI tools integrated into WordPress. Measure time-to-completion, bug rates, and perceived difficulty. - For H2: - Collect data from hosting providers and agencies about which CMS platforms underlie AI-generated frontends. Compare growth rates over time. - For H3: - Survey and track contributor sign-ups and retention across communities with explicit pro-AI vs anti-AI messaging. Use regression analysis controlling for project size. - For H4: - Classify AI-related WordPress projects into front-end vs infrastructure; track counts and downloads over time. - For H5: - Instrument the Abilities API and related features with opt-in telemetry to track real-world usage. Analyze correlation with plugin ecosystem growth. ### ❓ Questions - How can WordPress ensure AI integrations respect user privacy, especially for small sites? - Which AI use cases belong in core versus remain in plugins? - How do non-technical WordPress users perceive AI features in the editor? Helpful or overwhelming? - What governance structures best prevent over-dependence on any single AI vendor? - Can AI help reduce technical debt in long-lived WordPress sites rather than increasing it? ### 🔮 Future Research - Longitudinal studies of AI-assisted WordPress development workflows across agencies of different sizes. - UX research on AI features in the block editor for editors vs developers. - Best-practice patterns for AI-generated blocks/themes that remain maintainable. - Comparative analysis of AI-native CMSs vs WordPress + AI plugins. - Governance patterns for open-source communities integrating proprietary AI services. ### 💡 Implications - Practice: - Agencies should design workflows that treat WordPress as stable plumbing and AI as a power tool for fixtures. - Policy: - Projects may need clear policies on AI-generated contributions, licensing, and review standards. - Security: - AI integrations expand the attack surface; threat modeling and secure defaults are critical. - Education: - Training needs to include both WordPress fundamentals and AI-assisted development skills. - Funding models: - Ecosystem funding may shift toward infrastructure that makes AI safely usable inside WordPress. ### 🧠 Learning Styles Assessment - Reading level estimate: - Roughly high-school to early college level (Flesch-Kincaid ≈ grade 10–12), given conversational tone plus technical references. #### 👀 Visual learners - Present: - Strong central metaphor (plumbing/house) helps build a mental picture. - Improve: - Add diagrams showing layers: AI-generated frontends on top of WordPress plumbing. #### 🔊 Aural learners - Present: - No explicit audio version indicated. - Improve: - Provide a short audio narration or podcast-style reading, plus a 2–5 minute audio summary. #### 🗣️ Verbal learners - Present: - Clear analogies, narrative of past “WordPress is dead” cycles, concrete examples. - Improve: - Add a small glossary for newer terms (MCP, Abilities API) in plain language. #### 🧩 Kinesthetic learners - Present: - Conceptual, not hands-on. - Improve: - Include step-by-step mini-labs: “Use Telex to build a block,” “Call the Abilities API from an AI agent.” #### 🧠 Logical learners - Present: - Historical pattern logic: “Every time X was supposed to kill WP, WP absorbed X and grew.” - Improve: - Add simple tables or timelines with dates, percentages, and growth curves. #### 🧑‍🤝‍🧑 Social learners - Present: - Community-focused framing: “Will we welcome AI builders?” - Improve: - Add discussion prompts or recommended meetup topics. #### 🧘‍♀️ Solitary learners - Present: - Reflective tone invites personal stance (“I know which side I’m on.”). - Improve: - Provide explicit reflection questions or journaling prompts. #### 🌿 Naturalistic learners - Present: - Limited; “plumbing” is a built-environment analogy, not nature. - Improve: - Extend analogy to ecosystems: WordPress as soil/infrastructure supporting varied life (sites, apps) with AI as a new species. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: - As a typical article, likely uses headings and paragraphs; alt text unknown. - Improve: - Ensure proper heading hierarchy and descriptive alt text for any images or diagrams. #### Keyboard navigation - Present: - Standard article pages usually allow linear keyboard navigation. - Improve: - Provide visible focus states and skip links; avoid keyboard traps in any interactive AI demos. #### Contrast and readability - Present: - Modern blogs often meet contrast basics, but this must be confirmed. - Improve: - Verify 4.5:1 minimum contrast, adequate line height, and reasonable line length. #### Text resizing and reflow - Present: - Likely responsive layout. - Improve: - Test at 200% zoom and with prefers-reduced-motion; avoid clipping of any code or diagrams. #### Media and captions - Present: - Primarily text; no explicit media noted. - Improve: - Add captions/transcripts for any embedded talks or demos that might be linked later. #### Forms and interactions - Present: - Basic comment or newsletter forms may exist. - Improve: - Ensure clear labels, helpful error messages, adequate target sizes, and ARIA only when necessary. #### Standards reference - Map gaps to WCAG 2.2 AA criteria. - Focus on 1.4.x (contrast, resizing), 2.1.x (keyboard), 2.4.x (navigation), 3.3.x (input assistance). ### 🌍 DEIB Assessment #### Cultural breadth - Present: - Focused on the global WordPress ecosystem but told from one practitioner’s view. - Improve: - Add examples from non–English-speaking and emerging-market WordPress communities using AI. #### Inclusive language - Present: - Generally neutral; no overtly exclusive terms. - Improve: - Reduce insider jargon; define terms for newcomers to AI or WordPress. #### Neurodiversity support - Present: - Clear structure and recurring analogy help with comprehension. - Improve: - Use more subheadings, short lists, and consistent formatting; avoid long unbroken paragraphs. #### Representation - Present: - No explicit people imagery or detailed demographic references. - Improve: - When adding visuals, ensure diverse representation in imagery and examples. #### Psychological safety - Present: - Tone is opinionated but not attacking individuals; emphasizes welcoming newcomers. - Improve: - Link to community guidelines or codes of conduct in contexts where this essay is featured. ### ✅ Logical Validity #### Strong reasoning - Pattern recognition and induction: - The article argues inductively from multiple historical cases (mobile, Wix, Gutenberg, JAMstack) to predict AI will also be absorbed. This is strong as far as patterns go, but contingent on future conditions remaining similar. - Analogy: - The plumbing/house metaphor is effective: fixtures change, plumbing stays. It clarifies the distinction between backend infrastructure and the visible frontend. #### Fallacies - Potential hasty generalization: - Inferring that because WordPress survived past threats, it must also survive AI could overstate the guarantee. A fix would be to frame survival as “likely given current evidence” rather than certain. - Possible understatement of competitors: - Describing Wix’s share as a “rounding error” is rhetorically strong but may minimize valid use cases; acknowledging its niche strengths would strengthen the argument. #### Tone of voice - Tone: - Conversational, confident, and slightly combative toward “WordPress is dead” narratives, but ultimately inclusive and optimistic about AI and community openness. ### 🛡️ DARVO Analysis - Deny: - The article does not deny harms; it denies the *prediction* that AI will kill WordPress, presenting counterevidence instead. - Attack: - Mild rhetorical jabs at the “AI will kill WordPress” and “just vibe code everything” crowds, but not personalized attacks. - Reverse victim/offender: - No strong DARVO pattern. The author does not claim that critics are victims or that WordPress is persecuted; instead, they focus on agency: the community’s choice to welcome or resist AI. ## 🎯 Conclusion The article’s core claim is simple: AI doesn’t replace WordPress; it needs WordPress’s plumbing. History shows that every supposed existential threat has instead been absorbed. The real risk is social: if the WordPress community turns inward and gatekeeps AI users, it will squander an opportunity. Practical next steps include building robust AI integration points, creating welcoming pathways for AI-assisted developers, and treating AI as a collaborator that upgrades fixtures while the plumbing keeps running. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [{Title or entity}]({ARTICLE_URL}) by [[{Author or [MISSING]}]] via [[{Site or [MISSING]}]]. Published {DATE_OR_[MISSING]}. Accessed . > “Short quote, verbatim, ≤25 words.” Two lines: context and use. Cite data if relevant. [view highlight]({ARTICLE_URL}#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [{Title or entity}]({ARTICLE_URL}) > “Short quote, verbatim, ≤25 words.” Two lines: context and use. [view highlight]({ARTICLE_URL}#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] #### [Z2] 5–10-word present-tense claim - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Parent-Concept]] [[Related-Idea]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Short action — context/{ARTICLE_URL} #fleeting #inbox - [F2] Short action — context/{ARTICLE_URL} #fleeting #inbox - [F3] Short action — context/{ARTICLE_URL} #fleeting #inbox --- <!-- deep-read:sections end -->