Defensive Data Design  🔗 **Source:** [Defensive Data Design](https://make.wordpress.org/core/2026/08/04/defensive-data-design/) > [!note]+ Document Notes > --- > tags: [wordpress-core, ai-agent-safety, ux-defaults, data-design, product-design] > author: Matt Mullenweg > source: Make WordPress Core (make.wordpress.org) > reference: https://make.wordpress.org/core/2026/08/04/defensive-data-design/ > date created: 2026-08-14 00:00 > --- > > [!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. > # 🏷️ Title: Defensive Data Design > ## 🧭 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 > - Not applicable to this source — the post contains no outbound links. > ## 📝 Summary > - **What happened.** A short post on Make WordPress Core lays out design principles for making software defaults safer as AI agents take on more direct actions within WordPress (and software generally). > - **Why it matters.** As agentic AI tooling (including WordPress's own Core AI initiatives and the newly-launched official browser extension) gains the ability to act on a user's behalf, the cost of a wrong or destructive action rises. This post frames a defaults-first design philosophy: make safe actions easy and destructive actions hard. > - **Key stakeholders.** WordPress Core contributors/designers (implementers); end users and site owners (protected by safer defaults); AI agents/tooling built on top of WordPress (the actors these defaults are meant to constrain). > - **Risks and tradeoffs.** None stated explicitly — this is a principles list, not an implementation plan, so there's no discussion yet of tradeoffs (e.g., added friction for legitimate power users, or the engineering cost of implementing reversibility everywhere). > - **Bottom line.** A concise, actionable checklist for defensive UX/data design in an agent-driven future: reversible-by-default, hard-to-destroy, transparent, and plainly explained. > ## 📖 Main Content > - The core framing question: "As we go into a world where agents will be doing more things, how can we make the defaults as safe (and secure) as possible?" > - Ten specific design principles follow, covering: reversibility (trash vs. delete, draft vs. publish), visibility of changes, legibility of underlying data, actionable/copyable error messages that explain *why* not just *what*, graceful failure that minimizes harm, treating all input as potentially hostile (not just unreliable), using available UI space to show information directly, and plain, natural (even fun) language throughout. > ### 🗒️ Notes > - Not a transcript — a short principles post; dense notes without timestamp subheadings, per template. > - The list reads as a preemptive design response to agentic AI risk: several items (hard-to-delete, reversible, visible changes) specifically address the failure mode of an AI agent taking an unintended destructive action faster than a human would. > - One item stands out as AI-specific rather than general UX practice: "have a copy-to-clipboard next to [error messages], so people can put into search/AI/whatever" — an explicit acknowledgment that users now routinely hand error text to AI tools for help. > ## 📚 References > - Not applicable to this source — no external references or citations in the post itself. > ## 🗣️ Paraphrase > - The post asks how software defaults should change as AI agents take on more autonomous action, then answers with ten principles: make destructive actions harder than reversible ones, keep changes visible and undoable, make underlying data legible, write error messages that explain the reason and are easy to copy elsewhere (including into AI tools), fail in ways that limit harm, treat all input as potentially hostile, use available screen space to show information rather than hide it behind clicks, and keep language plain and human. > ## 📰 Newsletter > - **Quick hit for WordPress Core watchers.** Matt Mullenweg posted a short but sharp design checklist for the agentic-AI era: trash should be easy, deleting should be hard; drafts should be easy, publishing should be hard; error messages should explain *why*, not just *what*, and should be copy-pasteable straight into an AI tool. It's a preview of the design thinking likely to shape how WordPress Core and the new AI-native browser extension handle agent-driven actions going forward. > ## ✅ Action Items > #### DevRel > - Developer advocacy: N/A — this is an internal design-principles post, not a developer-facing announcement. > - Education: could inform guidance for plugin/theme developers building agent-facing features on defaults and reversibility. > - Developer experience: directly relevant — these principles could become review criteria for any WordPress feature that exposes actions to AI agents. > - Developer marketing: N/A. > - Community management: N/A. > - Internal/external/cross-project: N/A. > #### OSPO > - Policy & Governance: N/A. > - License Compliance: N/A. > - Security Management: directly relevant — "assume everything is not just unreliable, but actually hostile" is a security-by-design principle worth folding into any AI-agent-facing WordPress security guidance. > - Software Inventory: N/A. > - Developer Support: N/A. > - Community Engagement: N/A. > - Strategic Alignment: N/A. > #### Community > - Maintainers: relevant as a design-review lens for any Core feature touching agent-facing actions. > - Contributors: N/A. > - Sponsors: N/A. > - Ecosystem: N/A. > #### WordPress > - Core: directly relevant — this is a Core blog post proposing design principles likely to shape upcoming Core AI feature reviews. > - Core Performance: N/A. > - Core AI: directly relevant — the primary intended audience for these defaults. > - Core Program Team: N/A. > - Mobile: N/A. > - Playground: N/A. > - Community: N/A. > - Training: N/A. > - Marketing: N/A. > - Support: relevant — clearer, more actionable error messages (per the "why not just what" principle) could reduce support burden. > - Design: directly relevant — this is fundamentally a UX/design-systems post. > - Documentation: N/A. > - Photos: N/A. > - TV: N/A. > - Polyglots: N/A. > - Accessibility: tangentially relevant — plain language and legible data presentation overlap with accessibility goals. > - Meta: N/A. > - CLI: N/A. > - Hosting: N/A. > - Tide: N/A. > - Openverse: N/A. > - Themes: N/A. > - Plugins: relevant — plugin authors building agent-facing features should consider these defaults. > #### The WPOCC > - Programs: N/A. > - Projects: N/A. > - Funding experiments: N/A. > ### FAIR > - Technical independence: N/A. > - Policies and covenants: N/A. > - Productized governance artifacts: N/A. > ## 🧪 Hypotheses > - H1: WordPress features implementing these defensive-design defaults (harder-to-delete, reversible-by-default) will show measurably fewer support tickets related to accidental data loss than features that don't. > - H2: Error messages that explain "why" and include a copy-to-clipboard action will reduce time-to-resolution for AI-assisted troubleshooting compared to traditional error messages. > ### 📊 Methodology > - H1: comparative support-ticket analysis across WordPress Core features before/after adopting reversible-by-default patterns. > - H2: user study timing troubleshooting tasks with and without copy-to-clipboard, explanation-inclusive error messages, using an AI assistant to resolve the error. > ### ❓ Questions > - Which specific upcoming WordPress Core AI features will these principles apply to first, and will they be codified as formal review criteria? > - How do these defensive-design defaults interact with performance/complexity costs (e.g., is full reversibility always feasible at As we go into a world where agents will be doing more things, how can we make the defaults as safe (and secure) as possible? Some points to consider: * Putting something in the trash should be easy; deleting should be very hard. * Proposing a draft should be easy; publishing to the world should be hard. * Changes should be reversible and visible wherever possible. * How can we show the data behind the object in a way that makes it more legible and understandable, not less? * Error messages should be how you’d describe it to a friend. And have a copy-to-clipboard next to it, so people can put into search/AI/whatever. * If you error out, say the *why* not just the what. * Fail gracefully, in a way that minimizes harm or exposure. * Assume everything (networking / formatting / structure) is not just unreliable, but actually hostile. * Use the space you have, don’t make people click when you could have shown them something directly. * Plain language, make it obvious, natural. (And also fun.), Defensive Data Design, Matt Mullenweg, 01kzytab1djns86qm42mzt83xh.