Build Anything With Claude & WordPress  🔗 **Source:** [Build Anything With Claude & WordPress](https://slides.austinginder.com/2026-07-16-build-anything-with-claude-and-wordpress/#deck) > [!note]+ Document Notes > tags: [claude-code, wordpress-development, ai-assisted-development, design-to-code, self-hosted-deployment] > author: Austin Ginder > source: WordPress Lancaster Meetup (slides.austinginder.com) > reference: https://slides.austinginder.com/2026-07-16 build anything with claude and wordpress/ > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Build anything with Claude & WordPress > <!-- 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 - [Talk slides — Build anything with Claude & WordPress](https://slides.austinginder.com/2026-07-16 build anything with claude and wordpress/) - [Anchor Hosting](https://anchor.host) - [Cove — local WordPress dev CLI](https://cove.run) - Companion piece: Ginder's AI-security-pipeline article (Dismissed.FYI methodology, processed in parallel) ## 📝 Summary - **What happened.** Austin Ginder, a mostly-solo operator of Anchor Hosting (a few thousand WordPress sites), gave a 21-slide Lancaster Meetup talk on shipping real WordPress software through conversation with Claude Code. Since February 2026 he builds almost everything this way, and the talk is a tour of what he actually shipped this spring, not theory. - **Why it matters.** His pipeline — Design in Claude → DesignSync → Claude Code → local dev on Cove → browser verification → GitHub-release-as-deploy, with Emoji-Log commits and a per-project "cut a release" skill — is nearly identical to Courtney's own documented WP plugin/theme release workflow. It's an external, independently-arrived-at validation of her stack. - **Key stakeholders.** Solo developers and small agencies shipping custom WordPress; the WordPress community weighing AI-assisted build practices; Anthropic (Claude Code / Claude Design as the tool surface). - **Risks and tradeoffs.** The Dismissed.FYI project surfaces a real safety failure (a nag baked a customer's account name into a public card) and a corrective "hard architecture pivot" to local sandboxes. The through-line: the agent does exactly what you steer it to, so responsibility stays with the human. - **Bottom line.** The valuable artifact has shifted from code to direction. WordPress is a near-ideal target because plugins, DB tables, REST, and CLI are all buildable in a conversation using skills the developer already has. ## 📖 Main Content - **The one idea.** Ginder's thesis is that with open source the code was the valuable thing you shared; with AI, the valuable thing is *how you directed the agent* to produce it. The bottleneck moved from typing to steering. "Build anything" is now literal because a few sentences of architectural direction can drive 30 minutes to an hour of complicated programming. - **What a conversation produces.** Not a chatbot answer — a running WordPress site: custom plugins, database tables, REST APIs, themes, WP-CLI commands. He stresses "real WordPress, all the way down": no lock-in, no new framework. The existing skill set (WP-CLI, PHP, git) becomes the steering wheel. This is the load-bearing claim for a WordPress DevRel audience — the moat is domain fluency, not prompt trickery. - **The workflow (idea → live site in one session).** Five steps: (1) Design the whole UI as a Claude Design project, a `.dc.html` prototype; (2) pull it into Claude Code where DesignSync reads the design and translates it to WordPress (`sc-for` → PHP loop, `onClick` → a real route, hover → CSS); (3) build and run locally on Cove (cove.run) before touching production; (4) verify in a real browser — Claude drives Chrome, screenshots light + dark, catches what code review misses; (5) ship via self-hosted updates — a GitHub release plus a `manifest.json` self-updater, no wp.org, no CI. - **Three projects across a scope spectrum.** *League Report* (92 days, 30 sessions, 561 human turns) rescued years of amateur softball league history from a shutting-down platform — crawled the dying platform into SQLite, imported 3,045 leagues, produced 14 DB tables / 22 REST controllers / 19 page templates, solo, no git repo, shipped by zipping and `wp ... install --force` over SSH. *Dismissed.FYI* (28 days, 20 sessions) is a hall of shame for WordPress admin-notice spam, built as a direct port of a single morning's Claude Design mockup, using PHP Reflection to pin each notice's exact `file:line`. *Rutter* (one 22-turn evening, ~2.5h) shares the *flow* of an AI build the way GitHub shares code. - **Contested / uncertain points.** The productivity figures (~5,900 lines of working code by end of session one) are self-reported and project-specific. "Build anything" is aspirational framing — the talk's own scope spectrum shows effort scales enormously (1 evening vs. 92 days). The safety incident is disclosed honestly rather than hidden, which strengthens rather than undercuts credibility. - **Term definitions.** *DesignSync* — the mechanism that reads a Claude Design `.dc.html` prototype and translates its markup/interactions into WordPress PHP/CSS/routes. *Emoji-Log* — a commit convention with a fixed verb set (NEW / IMPROVE / FIX / DOC / RELEASE). *`manifest.json` self-updater* — a self-hosted plugin/theme update channel where a GitHub release is the deployment. *rutter* — a sailor's book of directions; here, a browsable recap of how a human steered an agent. ### 🗒️ Notes - **Slide 02 — the operator.** Anchor Hosting, a few thousand WordPress sites, mostly solo, one laptop since 2012, Claude Code for almost everything since Feb 2026. Framing: "not theory, what I actually shipped this spring." - **Slide 03 — the thesis.** Open source shared the code; AI makes the *direction* the valuable, shareable thing. Bottleneck moved from typing to steering. - **Slide 04 — output shape.** A conversation yields a running site (plugins, tables, REST, themes, WP-CLI). "Real WordPress, all the way down: no lock-in, no new framework to learn." Existing skills are the steering wheel. - **Slide 05 — direction density.** "Name the architecture, and a few key terms drive some very complicated programming." A landing page is quick; a custom engine takes longer but needs little more direction. - **Slide 06 — the pipeline.** Design in Claude (`.dc.html`) → Claude Code via DesignSync → local on Cove → browser verify (light + dark screenshots) → self-hosted GitHub-release-as-deploy. **This maps almost one-to-one onto Courtney's documented workflow** (`page-{slug}` templates, deployer-based self-hosted release, browser QA). - **Project 01 — League Report.** Real-world rescue of a dying softball-league platform. Non-technical commissioners edit scores/rosters inline on the live page, no wp-admin. Claude even named the project. Notable human moment during v2: "Bah… I think it was better before. Can we revert?" — AI-assisted work still needs taste and rollback. - **Project 02 — Dismissed.FYI.** Direct port of a design; code comments say "mirrors the design's data.js." Uses PHP Reflection to enumerate admin-notice callbacks and pin `file:line`; severity from how much of wp-admin a notice hijacks; ranked by intent (Critical = pure vendor benefit, Low = serves the user). Renders in a throwaway local sandbox fed by a wp.org mirror. **July 1 hard architecture pivot** after a nag leaked a real customer's account name into a public card — retired all live-site rendering. Safety lesson: "The agent will do exactly what you steer it to. That responsibility stays yours." - **Project 03 — Rutter.** Built in one 22-turn evening. `rutter-core` = custom table + `/r/<slug>/` routing + a WP-CLI command. Dogfooded immediately: the first recap was Rutter's own build data. - **Slide 17 — the roster.** Same pipeline across WP Beacon, WP Registry, Minn Admin, Disembark, Seafloor, Anchor Blocks, Cove, CaptainCore. - **Slide 18 — tips.** Design first (spec, not guess); never touch prod (`*.localhost` first); verify in a browser; persist hard-won architecture as memory (gotchas survive sessions); standardize commits (Emoji-Log); self-host updates; mine your own history (command-center indexes 1,400+ past sessions). - **Slide 19 — one-skill release.** `/dev-minn-admin › cut a release` runs six steps: Playwright suite (green or no release), version bump in four places + changelog date, commit/zip/publish GitHub release, regenerate screenshots, refresh marketing homepage, deploy + purge cache + verify live. **Directly parallels Courtney's `/dev-<slug>` "cut a release" skill goal.** - **Slide 20 — takeaways.** WordPress is the perfect target; design in Claude, build in Claude Code, run on real WordPress; you already have the skills to steer. ## 📚 References - [Build anything with Claude & WordPress — talk slides](https://slides.austinginder.com/2026-07-16 build anything with claude and wordpress/) - [Anchor Hosting](https://anchor.host) - [Cove — local WordPress dev CLI](https://cove.run) - [WP Beacon](https://wpbeacon.io) - [WP Registry](https://wpregistry.io) - [Disembark](https://disembark.host) ## 🗣️ Paraphrase - The person talking is one developer running thousands of WordPress sites on his own, and since early 2026 he builds nearly all of it by directing Claude Code. The talk shows what shipped, not what's possible in theory. - His central point: code used to be the prize you shared; now the prize is your direction of the agent. Typing stopped being the bottleneck — steering is. - A conversation with the agent produces an actual WordPress site — plugins, tables, REST endpoints, CLI commands — built out of skills WordPress developers already have, with no framework lock-in. - His pipeline runs design-in-Claude to code-in-Claude-Code to local testing to browser verification to a self-hosted GitHub release that is itself the deployment. - Across three projects ranging from a single evening to 92 days, the same workflow scales; the safety lesson is that the agent does exactly what you tell it, so the responsibility is yours. ## 📰 Newsletter Austin Ginder (Anchor Hosting) gave a Lancaster WordPress Meetup talk that will feel eerily familiar to anyone already living in Claude Code. His pitch: the code isn't the valuable part anymore — your direction is. He walks his real spring shipping list, from a 92-day rescue of a dying softball-league platform (3,045 leagues crawled into SQLite, inline editing on the live page, no wp-admin) to a plugin conceived and shipped in a single evening. The through-line is a pipeline WordPress builders can copy today: mock the UI as a Claude Design prototype, translate it in Claude Code, run every project locally first, make Claude screenshot light and dark in a real browser before "done," and self-host updates so a GitHub release *is* the deploy — no wp.org, no CI. Best community moment: a candid safety pivot after an admin-notice tool leaked a real customer's name onto a public page, retiring all live-site rendering for local sandboxes. If you keep a per-project "cut a release" skill and Emoji-Log commits, you'll nod the whole way through. Slides: slides.austinginder.com. ## ✅ Action Items #### DevRel - Developer advocacy: package Ginder's five-step pipeline as a repeatable demo/talk; measure adoption via a "ship a WP plugin in one session" workshop. - Education: build a workshop around DesignSync (Claude Design `.dc.html` → PHP), browser-verify screenshots, and self-hosted `manifest.json` updates. - Developer experience: publish a starter template that encodes local-first (`*.localhost`), Emoji-Log commits, and a `/dev-<slug>` "cut a release" skill. - Developer marketing: contrast this AI-native WP workflow against wp.org/CI defaults as a content series. - Community management: run an office-hours thread on responsible-agent guardrails (the live-site → sandbox pivot as a case study). - Internal/external/cross-project: align the "release is the deploy" pattern with existing self-hosted deployer workflows. #### OSPO - Policy & Governance: draft a "responsible agent steering" note — the human owns what the agent ships. - License Compliance: confirm wp.org-mirror sourcing (Dismissed.FYI) respects plugin licenses when reflecting code. - Security Management: codify the "never render against live sites" rule as a standing security guardrail. - Software Inventory: track which internal tools are AI-built and how they self-update. - Developer Support: document DesignSync gotchas so they persist across sessions (memory-as-architecture). - Community Engagement: share Rutter-style build recaps upstream as a transparency artifact. - Strategic Alignment: tie AI-build velocity claims to measurable OKRs, not raw line counts. #### Community - Maintainers: adopt release-hygiene automation (Playwright gate → version bump → GitHub release). - Contributors: create a "first AI-assisted PR" onboarding path. - Sponsors: not applicable to this source — the talk describes solo, self-funded builds with no sponsor dimension. - Ecosystem: pilot Rutter-style recaps as a cross-project way to share *flow*, not just code. #### WordPress - Core: not applicable to this source — talk is about building on WordPress, not Core patches. - Core Performance: not applicable to this source — no Core performance content. - Core AI: use this workflow as an input to responsible-AI guardrails and evaluation examples. - **Core Program Team:** not applicable to this source — no cross-team Core coordination content. - Mobile: not applicable to this source. - Playground: reproduce the "one conversation → running site" demo as a Playground education module. - Community: turn the pipeline into a meetup/WordCamp speaker kit. - Training: build a lesson path on design-first, spec-not-guess AI development. - Marketing: narrative around "you already have the skills to steer." - Support: document the self-hosted `manifest.json` updater as a support KB entry. - Design: promote Claude Design `.dc.html` prototypes as the spec source. - Documentation: examples-first guide to DesignSync markup → PHP mappings. - Photos / TV / Polyglots / Openverse / Tide: not applicable to this source. - Accessibility: add "screenshot light + dark and verify in a real browser" as an accessibility check step. - Meta: not applicable to this source. - CLI: expand WP-CLI command coverage examples (custom commands like `rutter-core`). - Hosting: cross-host checklist for local-first (`*.localhost`) + self-hosted release defaults. - Themes / Plugins: provenance checks for reflected/mirrored plugin code in tools like Dismissed.FYI. #### The WPCC - Programs / Projects / Funding experiments: not applicable to this source — no funding or fellowship dimension in the talk. ### FAIR - Technical independence: self-hosted `manifest.json` updates (no wp.org dependency) is a concrete independence pattern worth documenting. - Policies and covenants: not applicable to this source — no funding/covenant content. - Productized governance artifacts: Rutter (browsable build recaps) is a candidate transparency/governance artifact. ## 🧪 Hypotheses - Developers with strong WordPress fundamentals (WP-CLI, PHP, git) ship AI-directed projects faster and with fewer defects than those without. - A design-first pipeline (spec via `.dc.html`) produces fewer rework loops than prompting from a text description alone. - Browser-based verification (light + dark screenshots) catches a measurable class of defects that code review and unit tests miss. - Self-hosted GitHub-release-as-deploy reduces time-to-live versus wp.org + CI for small teams. - Persisting architecture decisions as memory reduces human course-correction turns across a project's later sessions. - Enforcing local-sandbox-only rendering eliminates the class of data-leak incident seen in early Dismissed.FYI. ### 📊 Methodology - **Note: this source is a slide extraction (slides + presenter notes), not prose or a timestamped transcript.** Analysis is drawn from 21 slides totaling ~1,262 words; claims are the presenter's self-reported project metrics, not independently audited. - To test velocity/defect hypotheses: instrument a cohort of WP developers building comparable scopes with and without the pipeline; measure sessions, human turns, interrupts, and post-ship defects (Ginder's own League Report numbers — 30 sessions, 561 turns, 26 hard interrupts, 7 course-corrections — are a usable baseline template). - To test the verification hypothesis: A/B a set of builds with vs. without mandatory dual-theme browser screenshots; classify escaped defects. - To test the deploy-speed hypothesis: time-to-live comparison, self-hosted `manifest.json` vs. wp.org/CI, holding scope constant. ### ❓ Questions - What exactly does DesignSync map beyond `sc-for`/`onClick`/hover, and where does the translation break down? - How is "hard-won architecture" persisted as memory in practice — CLAUDE.md, skills, or command-center indexing? - What did command-center's index of 1,400+ sessions change about later builds — is prior AI work measurably reusable? - What guardrails now prevent a repeat of the account-name leak, and are they enforced or advisory? - How does solo, no-git-repo development (League Report) affect recoverability and auditability? ### 🔮 Future Research - A reusable, documented "responsible agent steering" checklist derived from the July 1 pivot. - Quantified comparison of Emoji-Log + one-skill-release automation against conventional WP release pipelines. - Whether Rutter-style build recaps improve knowledge transfer versus code-only sharing. - Failure-mode catalog for DesignSync translation (design intent lost in PHP conversion). ### 💡 Implications - **Practice:** WordPress fundamentals become the durable moat; the pipeline is copyable today by anyone already using Claude Code + Claude Design. - **Policy:** teams need an explicit rule that the human owns what the agent ships, plus a hard "no live-site rendering" default for tools that inspect third-party code. - **Security:** local sandboxes fed from mirrors (not live sites) should be the default posture for reflection/inspection tooling. - **Education:** design-first, spec-not-guess is a teachable discipline that reduces AI rework. - **Funding models:** self-hosted release channels reduce dependence on centralized directories for distribution. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ~9–10 (short declarative slide sentences, some domain jargon like REST controllers, PHP Reflection, `manifest.json`). Flesch Reading Ease ~55–60. #### 👀 Visual learners - Present: this is a slide deck; project metrics and a scope spectrum are visual by design; light/dark screenshots are part of the workflow. - Improve: add an architecture diagram of the five-step pipeline and a before/after of a `.dc.html` prototype vs. rendered WordPress. #### 🔊 Aural learners - Present: delivered as a live talk with presenter notes. - Improve: publish a 3–5 minute audio summary or a recorded walkthrough of one project. #### 🗣️ Verbal learners - Present: strong analogies (steering wheel, rutter as a sailor's book of directions) and clear term coining. - Improve: a short glossary (DesignSync, Emoji-Log, self-updater) alongside the slides. #### 🧩 Kinesthetic learners - Present: the whole talk is build-along; local sandboxes invite hands-on replication. - Improve: a companion "build Rutter in an evening" checklist/lab. #### 🧠 Logical learners - Present: the scope spectrum (1 evening → 92 days) and per-project counts give a clear cause/effect structure. - Improve: a decision tree for when to design-first vs. prompt directly. #### 🧑‍🤝‍🧑 Social learners - Present: delivered at a meetup with Q&A + live demo (slide 21). - Improve: a discussion prompt set for meetup groups to run the pipeline together. #### 🧘‍♀️ Solitary learners - Present: self-paced replication is straightforward from the slides. - Improve: reflection prompts on "what would you steer the agent to build first?" #### 🌿 Naturalistic learners - Present: the League Report "rescue" framing ties to preservation/stewardship. - Improve: lifecycle framing of build → maintain → sunset for AI-built tools. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: slide headings provide structure in the extraction. - Improve: ensure the published slides expose real heading landmarks and alt text for the screenshots/metrics. #### Keyboard navigation - Present: not assessable from the extraction. - Improve: verify the slides site is keyboard-navigable with visible focus. #### Contrast and readability - Present: not assessable from text alone. - Improve: confirm 4.5:1 minimum for slide text and the dark-mode variants shown. #### Text resizing and reflow - Present: not assessable from the extraction. - Improve: confirm slides reflow at 200% zoom without clipping. #### Media and captions - Present: the live demo (slide 21) is video-adjacent. - Improve: caption any recording and provide a downloadable transcript. #### Forms and interactions - Not applicable to this source — the deck itself has no forms; the described tools (inline score editing) would need their own audit. #### Standards reference - Map the above to WCAG 2.2 AA: 1.1.1 (alt text on metric/screenshot slides), 1.4.3 (contrast), 1.4.10 (reflow), 2.1.1 (keyboard), 2.4.6 (headings/labels). ### 🌍 DEIB Assessment #### Cultural breadth - Present: examples are US-centric (amateur softball leagues) and English-only. - Improve: add non-US, multilingual build examples. #### Inclusive language - Present: plain, jargon-defined-in-context language; "hall of shame" is pointed but aimed at vendor behavior, not people. - Improve: brief plain-language summaries of PHP Reflection and self-updater concepts. #### Neurodiversity support - Present: consistent slide structure, chunked bullets, predictable per-project layout. - Improve: icon+text labels for the five pipeline steps. #### Representation - Present: single-presenter, solo-developer perspective. - Improve: pair with voices from teams and non-solo contexts to broaden applicability. #### Psychological safety - Present: notably candid about a real safety failure and the corrective pivot — models blameless disclosure. - Improve: add explicit community guidelines for responsibly building tools that inspect others' plugins. ### ✅ Logical Validity #### Strong reasoning - **Analogical (slide 03, "steering wheel"; Project 03, "rutter"):** strong because both analogies map cleanly onto the claim (existing skills direct the agent; a build recap is a set of directions). Clarify by naming the limits of each analogy. - **Inductive (slides 16–17, scope spectrum + roster):** three concrete projects plus a longer roster support "same workflow, different scope." Strengthen with defect/maintenance data, not just build counts. - **Causal (Project 02, July 1 pivot):** a specific harm (leaked account name) causes a specific architecture change (retire live-site rendering). Well-located and honest. #### Fallacies - **Hasty generalization / overclaim — "Build anything" (slides 03, 16):** the deck's own scope spectrum shows effort varies 100x, so "anything" overstates parity. Fix: qualify as "a very wide range of things, with effort scaling to scope." - **Survivorship framing (whole deck):** only shipped successes are shown; abandoned or failed AI builds aren't. Fix: include a failure or near-miss beyond the one safety incident. - **Self-report bias (project metrics, e.g., ~5,900 lines in session one):** impressive numbers are unaudited. Fix: note measurement method. #### Tone of voice - Confident, practitioner-to-practitioner, understated ("not theory"). Occasionally promotional about the tooling, but grounded by candid disclosure of the safety pivot. ### 🛡️ DARVO Analysis - Deny: none. The talk does the opposite of denial — it openly admits the live-site rendering mistake rather than minimizing it. - Attack: none directed at people; "hall of shame" critiques vendor admin-notice behavior, not individuals. - Reverse victim/offender: none. Ginder places responsibility on himself as the steerer ("That responsibility stays yours") rather than shifting blame to the agent. - Emotional cues / rhetoric: light emotional beats (the "Can we revert?" moment, the league-history rescue) build rapport without manipulation; no DARVO pattern present. ## 🎯 Conclusion - **Bottom line.** The code is cheap now; the craft is the direction. Ginder demonstrates that a solo WordPress developer, steering Claude Code through a disciplined design-first, local-first, browser-verified, self-hosted-release pipeline, can ship everything from an evening's plugin to a 92-day platform — as long as the human owns what the agent does. - **Practical next steps for readers (esp. Courtney).** This is external validation of your own stack: the parallels are near-exact (Claude Design → DesignSync → Claude Code → local dev → browser QA → self-hosted GitHub-release-as-deploy, Emoji-Log commits, one `/dev-<slug>` "cut a release" skill). Worth mining for: (1) DesignSync's markup→PHP mappings as a documented pattern; (2) command-center-style indexing of past sessions as a reusable knowledge base; (3) the July 1 sandbox pivot as a standing "never render against live sites" guardrail. Cross-reference the companion AI-security-pipeline article for the Dismissed.FYI Reflection/severity methodology in depth. ## 🔄 Refactor Appendix — Build anything with Claude & WordPress > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Direction, not code, is the valuable output > [!quote] ID:rw_slide03 > The code output isn't the valuable part anymore. The direction is. **Context & use**: - Slide 03, the talk's stated "one idea to take home." - Reframes value in AI-assisted development from artifact to steering — the core lens for the whole deck. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H2] The bottleneck moved from typing to steering > [!quote] ID:rw_slide03b > The bottleneck moved from typing to steering. **Context & use**: - Slide 03, supporting the "build anything" claim. - Names the concrete shift a WordPress developer feels day to day; explains why domain fluency now beats raw coding speed. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H3] The GitHub release is the deployment > [!quote] ID:rw_slide06 > The release is the deploy. No wp.org, no CI. **Context & use**: - Slide 06, step 5 of the pipeline (self-hosted `manifest.json` updater). - Directly parallels Courtney's self-hosted deployer workflow; a copyable distribution pattern independent of wp.org. **Tags**: #xref #addendum <!-- atomicity: 1 idea ✓ --> #### [H4] Steering the agent keeps responsibility with the human > [!quote] ID:rw_project02 > The agent will do exactly what you steer it to. That responsibility stays yours. **Context & use**: - Project 02 (Dismissed.FYI), stated after the July 1 pivot away from live-site rendering. - The talk's safety thesis; grounds "build anything" with human accountability. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] In AI-assisted development, direction is the durable craft **Claim** (one sentence, Courtney's voice): When an agent writes the code, the reusable, valuable skill is the human's architectural direction, not the code it emits. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds when the builder has enough domain fluency to name architecture and verify output; breaks down when the human can't judge correctness and blindly ships agent work. **Links**: - [[Claude Code WordPress workflow]] — because applies-in solo WP development - [[Self-hosted release-as-deploy]] — because extends the direction-over-code thesis into distribution <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Extract DesignSync's markup→PHP mapping (`sc-for`→loop, `onClick`→route, hover→CSS) as a documented pattern — slide 06 #fleeting #inbox - [F2] Compare command-center's 1,400+ session index to Courtney's own memory/knowledge-hub approach for reusing prior AI work — slide 18 #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Diff Ginder's five-step pipeline against Courtney's documented WP release workflow and note gaps — #things - [ ] Adopt a standing "never render against live sites" guardrail for any plugin-inspection tooling — #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Build Anything With Claude & WordPress.md|Build Anything With Claude & WordPress by Austin Ginder]] ## Highlights - The code output isn't the valuable part anymore. The direction is. ([View Highlight](https://read.readwise.io/read/01kxts7p396s860p1ndht3qc9n)) - Note: H1 — the talk's one idea: value moved from the artifact (code) to the steering. With open source you shared code; with AI you share how you directed the agent. - Tags: atom/literature/h1 - The bottleneck moved from typing to steering. ([View Highlight](https://read.readwise.io/read/01kxts7qzspz5npge1t36w9jsn)) - Note: H1 — why domain fluency now beats coding speed; the support for "build anything is real now." - Tags: atom/literature/h1 - The release is the deploy. No wp.org, no CI. ([View Highlight](https://read.readwise.io/read/01kxts7sgtcvmn8gy4jwtxwrg2)) - Note: H2 — the self-hosted manifest.json updater: GitHub release = deployment. Parallels your own deployer workflow. - Tags: atom/literature/h2 - The agent will do exactly what you steer it to. That responsibility stays yours. ([View Highlight](https://read.readwise.io/read/01kxts7w2dca149pa6d9d77ym2)) - Note: H2 — the safety thesis, stated after the July 1 pivot away from live-site rendering (a nag had leaked a real customer's account name). Steering power = steering responsibility. - Tags: atom/literature/h2