Back and Forth  🔗 **Source:** [Back and Forth](https://nomad.blog/2026/06/26/back-and-forth/) > [!note]+ Document Notes > tags: [ai-assisted-development, wordpress-contribution, gutenberg, open-source-collaboration, release-leadership, design-feedback] > author: Anne McCarthy (agm) > source: nomad.blog > reference: https://nomad.blog/2026/06/26/back-and-forth/ > date created: 2026-06-26 > > # 🏷️ Title > Back and forth — Using AI as a communication device in WordPress contribution > > # 🧭 Table of Contents > - Summary > - Main Content (Notes) > - References > - Paraphrase > - Newsletter > - Action Items > - Hypotheses > - Methodology > - Questions > - Future Research > - Implications > - Learning Styles Assessment > - Accessibility Assessment > - DEIB Assessment > - Logical Validity > - DARVO Analysis > - Conclusion > - Refactor Appendix > - Template Library > > # 🔗 References (in-page) > - Three WordPress/Gutenberg 7.1 feature threads discussed: (1) inherited styles + "push to global" option, (2) attached images in the Inserter, (3) Media Editor Modal "call for testing" (free-form image cropper). > - Tools named: Claude (terminal + CraftAgents), `wp-env` dev environment, Cloudup (video sharing). > - Audience context: the recent AI Leaders graduates cohort met in Chicago. > > # 📝 Summary > **What happened:** WordPress release lead Anne McCarthy ("agm") describes a deliberate shift in how she uses AI on core/Gutenberg work: not to generate code or file competing PRs, but as a *communication device*. Her loop is — pull a developer's in-progress PR locally, use Claude (terminal + CraftAgents) to make the UX changes she wants to see, feel out the iteration, then share a short video or stills to communicate "what I think might work better." The devs who know the code best then run with the idea after design signs off. > > **Why it matters:** This reframes AI's role in open-source collaboration away from the much-criticized "flood of AI-generated code to review" and toward *intent communication*. It's a release-leadership time-management strategy: she must test everything yet spend limited time per item, and explicitly does not want to start PRs she can't follow up on or that create work for others. The "jankiness is by design" — the prototype's job is to convey a direction fast, not to be merge-ready. > > **Stakeholders:** WordPress/Gutenberg contributors (devs, designers), release leads, the AI Leaders graduates she's inspiring, and the broader open-source community wrestling with how to integrate AI sustainably. > > **Risks:** None material to the reader; the cautionary subtext is about *unsustainable* AI contribution (competing PRs, review burden) that this approach avoids. > > **Bottom line:** Used as a prototyping-for-communication tool rather than a code generator, AI can accelerate design/dev alignment and reduce review burden — a sustainable contribution pattern for someone whose leverage is judgment and coordination, not raw code output. > > # 📖 Main Content > <!-- deep-read:sections start --> ## 🗒️ Notes - **Core thesis:** "A big part of using AI is knowing when and how to." The shift is toward AI "as a communication device when going back and forth with developers and designers." - **The loop:** take their PR → use AI to make the changes she wants to see → tweak based on feel → share a video to communicate a better direction. Faster than "creating a competing PR," especially mid-feature. - **Division of labor:** the devs who know the code best and have time follow up and run with the idea after design passes. - **Why (release-lead framing):** she needs to test "literally everything" while being careful with time per item; doesn't want to start a PR that makes work for someone else or that she can't follow up properly. - **Continuity:** "this feels like a return to what I was doing 9–10 months ago with AI and it feels… right." Sustainability over volume. - **Process specifics:** Claude in terminal + CraftAgents, working the PR *locally* with explicit intent to NOT push or open a PR; relies on a pre-set dev environment (`wp-env`) — and tells newcomers to have Claude set one up and point it at docs. - **Example 1 — inherited styles / push-to-global (7.1):** the in-progress approach surfaced TWO options on every local block change (reset to global *and* push styles globally), redundant with the existing "apply globally" under Advanced. It "felt off"; she first flagged it for design, kept mulling, then prototyped an alternative. Design later approved; the dev is adjusting — "saved likely hours of back and forth." - **Example 2 — attached images in the Inserter (7.1):** initial PR's "attached images" section "immediately overwhelmed everything else," including the broader media-library button; terminology risk for most users. She offered an AI-built alternative that adds an "attached images" option at the top of the existing pattern and makes images bigger/easier to review. The same dev already had a PR moving that way; the discussion accelerated it. - **Example 3 — Media Editor Modal (call for testing):** a free-form image cropper in the Block Editor. As a heavy user of the image tools, she wanted it to "feel delightful," communicated via comment + stills (after struggling to upload the video to Cloudup). The feature "has evolved so much" since. - **"Jankiness by design":** "I'm not trying to have a code ready PR. I'm trying to communicate a way forward and this was a very fast way to do so." - **Open-source values coda:** the site is "built with WordPress, reflecting a belief in the power of open source, the open web, and the people who sustain it." # 📚 References (primary sources preferred) 1. **The post itself** — Anne McCarthy, nomad.blog, 2026-06-26 (primary). 2. **Gutenberg 7.1 PRs/threads** for inherited styles, attached-images Inserter, and the Media Editor Modal call-for-testing (primary; linked in-article but not enumerated in extracted text). 3. **`wp-env`** — WordPress local dev environment documentation (primary tooling reference). 4. **CraftAgents** + **Claude** — the AI tooling used (primary tooling reference). 5. **AI Leaders program** (Chicago cohort) — contextual audience. # 🗣️ Paraphrase (paragraph-by-paragraph) - Knowing *when/how* to use AI matters; reviewing volumes of AI-generated code is painful, so she's returned to using AI to communicate while iterating with devs/designers. - This mirrors what she did 9–10 months ago and feels like a sustainable way to contribute for this release cycle and her role. - She shares concrete examples, partly to inspire the recent AI Leaders graduates; it'll be nerdy and detailed. - Her process is simple: Claude in terminal + CraftAgents, working locally with no intent to push or PR; set up a dev env (e.g., `wp-env`) first. - Example 1: a 7.1 inherited-styles feature added a push-to-global option that appeared on every local change. - That redundancy with the existing Advanced "apply globally" felt off; she flagged it, then prototyped an alternative. - Design approved; the dev is adjusting — saving hours of back-and-forth and review wait. - Example 2: attached images were hard to find from the Inserter; the feature aims to surface attached images and support a newsroom-style upload/use flow. - The initial PR's attached-images section overwhelmed the rest; she proposed a simpler AI-built alternative with bigger images. - The jankiness is intentional — it's communication, not a merge-ready PR; the dev was already heading that way. - Example 3: a Media Editor Modal call-for-testing adds a free-form cropper; she communicated proposed changes via comment + stills. - The feature has evolved a lot since; go try it. # 📰 Newsletter (WordPress-focused, witty, with links) **Stop shipping AI code. Start shipping AI *intent*.** This week WordPress release lead Anne McCarthy ([nomad.blog](https://nomad.blog/2026/06/26/back-and-forth/)) made the case that the best place for AI in core contribution might not be the PR queue at all. Her move: pull a dev's in-progress PR, let Claude (terminal + CraftAgents) reshape the UX locally, record a quick — deliberately janky — video, and drop it in the thread as "here's what might work better." No competing PR. No extra review burden. Just a faster way to say what words can't. The payoff shows up across three Gutenberg 7.1 threads — inherited styles, attached images in the Inserter, and the Media Editor cropper — where a 60-second prototype reportedly saved *hours* of back-and-forth and design-review wait. The release-lead logic is the real lesson: when your job is to test everything but spend minutes per item, a throwaway prototype is leverage; a half-finished PR is a liability you've now handed to someone else. "Jankiness by design" might be the most honest three words written about AI tooling all month. For the AI Leaders crowd and anyone wondering how to contribute *sustainably*: communicate the direction, let the people who know the code best drive. # ✅ Action Items - **DevRel:** Package this "AI-as-communication-device" loop into a short contributor guide/video — it's a reusable onboarding pattern for new and AI-curious contributors. High priority. `#action/h1` - **OSPO:** Adopt "prototype-to-communicate, don't compete-PR" as an explicit norm in contribution guidelines to reduce review burden from AI-generated code. `#action/h2` - **Community:** Surface this to the AI Leaders graduates (Chicago cohort) as a worked example; invite them to share their own loops. `#action/h2` - **WordPress subteams:** - **Core / Core AI:** Document a sanctioned local-prototyping workflow (Claude + `wp-env`, "no push" intent) so contributors can replicate it safely. `#action/h1` - **Design:** Note the time saved when a prototype precedes design review; consider a lightweight "prototype-first" intake for in-progress features. `#action/h2` - **Documentation:** Add/point to `wp-env` quick-start that an agent can follow when asked to "set up the dev environment." `#action/h2` - **Training:** A learn.wordpress.org module on prototyping-for-communication with AI. `#action/h3` - **Core Performance / Mobile / Playground:** Playground is a natural host for shareable, janky-by-design prototypes without a local env — worth piloting. `#action/h2` - **Marketing / Support / Photos / TV / Polyglots / Accessibility / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins / Core Program Team:** Not directly actionable from this post — reason: the piece is a contribution-workflow narrative, not feature/policy news for these teams. - **The WPOCC:** A short talk/segment on sustainable AI contribution patterns would fit well. `#action/h3` - **FAIR:** Thematically aligned (sustaining contributors, healthy participation) but no concrete FAIR action here. Not applicable. # 🧪 Hypotheses (testable) 1. Prototyped UX communication (video/stills) shortens time-to-design-approval on in-progress PRs versus text-only comments. (Measure thread→approval latency.) 2. "Communicate, don't compete-PR" reduces reviewer load and duplicate-PR churn on a feature thread. 3. Contributors with a pre-set local dev env adopt AI-prototyping faster than those without (env friction is the limiting factor). 4. Janky/low-fidelity prototypes elicit faster, more candid feedback than polished ones (lower perceived sunk cost). 5. Release leads using this loop test more features per unit time than those filing their own PRs. 6. The pattern generalizes beyond WordPress to any large OSS project with separate design/dev review gates. # 📊 Methodology This is a **first-person practitioner reflection / methods narrative**, not a study. Evidence: three concrete, linked WordPress 7.1 examples with described outcomes ("design approved," "dev already had a PR in that direction," "saved likely hours"). Strengths: specific, reproducible workflow; named tools; honest about limits ("jankiness," failed Cloudup upload). Limits: outcomes are self-reported and qualitative (no measured time savings); single-practitioner perspective; selection of "wins" without counter-examples where the approach failed. # ❓ Questions - What's the failure mode — when does a janky prototype *mislead* devs or anchor design prematurely? - How is authorship/attribution handled when an AI-built prototype shapes a merged PR someone else authors? - Does this work only because she's a trusted release lead, or does it transfer to a brand-new contributor with no social capital? - Where's the line between "communicating intent" and "doing the design work" that the dev/designer should own? - What dev-env friction blocks newcomers from replicating step one (pull PR locally)? # 🔮 Future Research - A measured before/after on thread velocity for prototype-communicated vs. text-only feedback. - A contributor-experience study on whether low-fidelity AI prototypes lower the barrier for non-coding contributors (designers, PMs). - Tooling: a sanctioned "ephemeral prototype" path (e.g., via Playground) that removes local-env setup entirely. # 💡 Implications - **Practice:** Reframes AI value in OSS from *output* (code) to *alignment* (shared intent); a template for release leads and PMs. - **Policy (project governance):** Contribution guidelines could explicitly bless prototype-to-communicate and discourage low-effort AI PRs. - **Security:** Working strictly locally with "no push" intent sidesteps the supply-chain/review risk of AI-authored PRs — a quietly good safety posture. - **Education:** Strong onboarding artifact for AI Leaders / Training; teaches *judgment about when to use AI*, not just prompts. - **Funding/sustainability:** Directly addresses contributor burnout from review overload — a sustainability lever for the project. # 🧠 Learning Styles Assessment - **Visual:** Strong intent — the post centers on shared videos/stills/screenshots; the extracted text lacks the images, but the method is inherently visual. - **Aural:** N/A — text post; the *referenced* videos are aural/visual. - **Verbal (read/write):** Strong — clear, conversational prose; primary modality of the post itself. - **Kinesthetic:** Strong — it's a hands-on, do-this-yourself workflow (set up `wp-env`, pull a PR, prototype). - **Logical:** Moderate-strong — clear cause→effect reasoning (constraint → method → outcome) across three cases. - **Social:** Strong — the entire thesis is collaborative communication; invites comments. - **Solitary:** Moderate — replicable alone, but the value is in the back-and-forth. - **Naturalistic:** N/A. - **Reading level estimate:** ~Grade 9–10; conversational, with light jargon (PR, Inserter, global styles, `wp-env`) familiar to the WordPress audience. # 📊 Accessibility Assessment (WCAG 2.2 AA, 7 subcategories) - **Perceivable:** The post relies heavily on embedded images/videos to make its point; *text alternatives are critical here*. Cannot confirm alt text from extracted body — a genuine risk for a visual-first post. Recommend captions/transcripts on the shared videos. - **Operable:** Standard blog navigation; the embedded media (Cloudup/video) should expose keyboard-accessible controls. - **Understandable:** Clear, friendly language; WordPress jargon may need context for non-contributors, but the audience is targeted. - **Robust:** Depends on nomad.blog (WordPress) theme markup — generally robust. - **Text alternatives:** Likely gap — image-heavy argument needs descriptive alt/longdesc for screen-reader users to follow the UX comparisons. - **Time-based media:** The shared videos need captions/transcripts for AA conformance. - **Contrast/visual:** Theme-dependent; not assessable from text. # 🌍 DEIB Assessment - **Cultural breadth:** WordPress-contributor context; globally distributed OSS audience. - **Inclusive language:** Warm, inviting ("bear with me," "happy to explain anything in the comments"); explicitly lowers the barrier to ask questions. - **Neurodiversity support:** Offers multiple comprehension paths (prose + visuals + offer to explain); the "deeply nerdy and detailed" warning sets expectations kindly. - **Representation:** Centers a release lead modeling sustainable contribution; credits "wonderful contributions from everyone on the threads" and directs readers to them — good attribution ethic. - **Psychological safety:** Models humility ("felt off," "jankiness by design," admits a failed video upload), which makes experimentation feel safe for newcomers — a strong inclusion signal. # ✅ Logical Validity **Strong reasoning present:** The argument is cleanly structured — constraint (must test everything, limited time, don't burden others) → method (AI-prototype to communicate, not compete) → evidence (three cases with outcomes) → principle (sustainable contribution). Honest about limitations ("jankiness by design"), which strengthens credibility. **Fallacies (minor / soft):** - **Hasty generalization (mild)** — *located:* "saved likely hours of back and forth" and the broad framing that this is "the best use of time for all involved," drawn from a handful of self-selected successful examples. *Why:* sample is small and outcomes are self-reported wins; no counter-cases. *Fix:* qualify as "in these cases" (which she partly does with "for this release cycle and my role") or add a case where it didn't help. - **Appeal to feeling (mild)** — *located:* "it feels… right." *Why:* intuition substitutes for evidence on the central judgment. *Fix:* pair the feeling with the concrete time/burden metrics that justify it (she gestures at these, could make them explicit). **Tone of voice:** Reflective, generous, practitioner-honest. Invites scrutiny rather than asserting authority. # 🛡️ DARVO Analysis Not applicable to this source — reason: the post is a constructive, non-adversarial methods reflection with no accusation, defense, or victim/offender dynamic to analyze. # 🎯 Conclusion **Bottom line:** Anne McCarthy reframes AI in open-source contribution from a code-generation firehose into a precision *communication* instrument: prototype the change locally, show it in a short (intentionally rough) video, and let the people who own the code carry it forward. For a release lead optimizing for coverage and other people's time, that's higher-leverage than filing PRs — and it sidesteps the review-burden and supply-chain risks of AI-authored code. **Next steps (reader):** If you contribute to WordPress (or any large OSS project), try the loop once — set up `wp-env`, pull an in-progress PR, prototype a UX change with Claude *without* intending to push, and share it in the thread. Watch whether it shortens the design/dev back-and-forth. # 🧱 Refactor Appendix ## Literature Split Pad ### H1 — Strongest claims - "Increasingly I have read about and I hear from engineers how horrible it is to review AI generated code and just how much of it there is to review… I've found myself drawn to returning to using AI more as a communication device when going back and forth with developers and designers." — the thesis. `#atom/literature/h1` - "I'm not trying to have a code ready PR. I'm trying to communicate a way forward and this was a very fast way to do so." — the operating principle (jankiness by design). `#atom/literature/h1` ### H2 — Secondary - "I'm finding this is helping move work much faster than my creating a competing PR, especially when a feature is already underway." — the comparative claim. `#atom/literature/h2` - "This is especially helpful as the release lead when I both want to test literally everything and need to be careful with how much time I'm spending on each thing." — the release-lead constraint that motivates the method. `#atom/literature/h2` ### H3 — Supporting context - Process: Claude in terminal + CraftAgents, working the PR locally with explicit no-push/no-PR intent, on a pre-set `wp-env` dev environment. `#atom/literature/h3` - Worked outcome: design approved the inherited-styles alternative and the dev is adjusting — "saved likely hours of back and forth as well as waiting for design to review." `#atom/literature/h3` ## Atomic Split Pad (Zettel candidates) - **AI's highest-leverage role in OSS may be communicating *intent*, not generating code.** `#atom/zettel/z1` - **"Jankiness by design": a low-fidelity prototype's job is to convey a direction fast, not to be merge-ready.** `#atom/zettel/z1` - **Prototype-to-communicate beats compete-PR when a feature is already underway — it adds direction without adding review/ownership burden.** `#atom/zettel/z1` - **Sustainable contribution is judgment about *when* to use AI, not maximal output.** `#atom/zettel/z1` - **Working locally with explicit "no push" intent is a quiet supply-chain safety posture for AI tooling.** `#atom/zettel/z1` ## Fleeting Queue - Connects to the **transparency/trust-primitive** theme and to contributor-sustainability/burnout threads in OSS governance. `#atom/fleeting/f1` - Tooling idea: an ephemeral, env-free prototype path (WordPress Playground) to remove step-one friction for newcomers. `#atom/fleeting/f1` - Cross-link candidate: pairs with prior notes on AI-assisted review burden and on release-lead time management. `#atom/fleeting/f1` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Back and Forth.md|Back and Forth by nomad.blog]] ## Highlights - A big part of using AI is knowing when and how to. Increasingly I have read about and I hear from engineers how horrible it is to review AI generated code and just how much of it there is to review. As I mull that over and take it to heart, I’ve found myself drawn to returning to using AI more as a communication device when going back and forth with developers and designers working on a feature. I can take their PR, use AI to make the changes I want to see, tweak things based on how the iteration feels, and then share a video to communicate what I think might work better. I’m finding this is helping move work much faster than my creating a competing PR, especially when a feature is already underway. The devs who know the code best and have more time to follow up can then run with an idea after design has given things a pass. This is especially helpful as the release lead when I both want to test literally everything and need to be careful with how much time I’m spending on each thing. I don’t want to start a PR that creates more work for someone else and/or that I can’t follow up on properly for a feature in progress. ([View Highlight](https://read.readwise.io/read/01kw3d6zpsa56snz9bhxn5hkq5)) - Note: The thesis: AI as a communication device, not a code generator — faster than a competing PR mid-feature. - Tags: atom/literature/h1 - In many ways, this feels like a return to what I was doing 9-10 months ago with AI and it feels… right. I’m sure I’ll still contribute PRs here and there but it feels important to think about how best I can sustainably contribute in a way that’s best for the project. For this release cycle and my role in it, this has felt like the best use of time for all involved. ([View Highlight](https://read.readwise.io/read/01kw3d7cppg8bfge94a10rcxhj)) - Note: Sustainable contribution as judgment about when to use AI, not maximal output. - Tags: atom/literature/h2 - Design later reviewed it, said it looked good, and the dev working on the feature is in the process of adjusting the approach. Mind you there are loads of details to work out but this just saved likely hours of back and forth as well as waiting for design to review when I had an idea in mind that just might work. ([View Highlight](https://read.readwise.io/read/01kw3d7gx9xjxmwat6cgh9q7ka)) - Note: Worked outcome: a fast prototype precedes design approval and saves hours of back-and-forth. - Tags: atom/literature/h2 - You’ll notice there’s some jankiness but that’s by design. I’m not trying to have a code ready PR. I’m trying to communicate a way forward and this was a very fast way to do so. Amazingly, the same developer working on this feature [already had a PR in that direction](https://github.com/WordPress/gutenberg/pull/79336) and this discussion helped us move towards it. ([View Highlight](https://read.readwise.io/read/01kw3d785wvyykbkybte3dc9kz)) - Note: "Jankiness by design" — the operating principle: convey a direction fast, not a merge-ready PR. - Tags: atom/literature/h1