Maintaining Over Building  🔗 **Source:** [Maintaining Over Building](https://www.briancoords.com/maintaining-over-building/) > [!note]+ Document Notes > tags: [software-maintenance, vibe-coding-debt, wordpress-vs-vibe-coding, platform-stability, woocommerce, technical-debt] > author: Brian Coords > source: briancoords.com > reference: https://www.briancoords.com/maintaining-over-building/ > date created: 2026-07-27 20:20 > > > [!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: Maintaining over Building > <!-- 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 - [The article](https://www.briancoords.com/maintaining-over-building/) - [MacSparky — "Apple should just do one big thing a year"](https://www.macsparky.com/blog/2026/07/apple-should-just-do-one-big-thing-a-year/) — the stability argument Coords endorses - [WooCommerce Core Foundations post](https://woocommerce.com/posts/woocommerce-core-foundations/) — Woo's maintenance-mode quarter - [Neha Kalani tweet](https://x.com/thericebowlgirl/status/2081575149334335552) — team reverting from a vibecoded tool back to Linear ## 📝 Summary - **What happened.** A short first-person reflection from a Woo (Automattic) engineer on the discipline of maintaining decades-old software in the AI era. The thesis is a corrective to the "AI lets us ship features daily" mood: when software runs on millions of live sites, caution is not timidity — it's what makes software last. Coords admits maintenance can feel like drudgery next to building "the new and shiny," then argues that's exactly backwards, citing his own vibe-coded projects (90% abandoned on GitHub), a viral example of a team reverting from a vibecoded internal tool back to Linear because maintaining it ate their real work, and MacSparky's "one big thing a year, plus a thousand small fixes" stability argument. He grants vibe-coding will take low end market share (landing pages, small sites) but doubts it for publishing and e-commerce — and discloses Woo is spending the quarter in maintenance mode clearing its GitHub backlog. - **Why it matters.** It's a credible insider counterweight to the vibe-coding hype, from someone at the e-commerce platform most exposed to the "why not just vibe-code it" question. And it lands in a batch that already contains the MemberPress "vibe-coding hangover" argument and the wp2shell core-RCE — three angles on the same claim: *generating software and sustaining it are different jobs, and the second is where durability lives.* - **Key stakeholders.** Platform engineers weighing feature velocity against stability; WordPress/Woo users who feel the paper cuts; the vibe-coding vendors competing for the low end; and Woo itself, which is publicly framing a maintenance quarter as a virtue rather than a lull. - **Risks and tradeoffs.** It's short, anecdotal, and comes from a maintainer with an obvious stake in valorizing maintenance — the tweet and the 90%-abandoned figure are illustrations, not evidence. The "vibe-coding won't do complex e-commerce" line is a reasonable bet, not a demonstrated limit, and the piece is also soft marketing for a Woo event and blog post. But the core distinction is sound and the honesty (Woo *is* in cleanup mode) is disarming. - **Bottom line.** The durable idea: **maintenance is the hard, unglamorous, non-optional work that AI doesn't erase — it may even increase it, by making it trivial to generate more code that then has to be maintained.** For a mature platform, "do one big thing well and fix a thousand small things" is a stronger strategy than feature-per-day, and the vibe-coding market split (low-end churn, high-complexity durability) is the reasonable read. ## 📖 Main Content **The setup — maturity as constraint.** Coords opens on what it's like to work on software that's been around for decades. AI supercharges the ability to "execute random ideas," which creates a temptation to believe big platforms should ship features daily. His counter is grounded in the operating reality: when your code is "run, extended, modified, and personalized on millions of live websites," caution is mandatory. That's the whole argument in one frame — the cost of a mistake scales with the install base, and WordPress/Woo's install base is enormous. **The honest emotional admission.** He doesn't pretend maintenance is fun. It "can sometimes feel frustrating," like "just routine maintenance, not building the new and shiny," and small iterations take longer "because you have to triple-check everything before you ship." Naming the drudgery is what earns the turn: *that quality and care is what makes good software great. It's why something lasts.* The candor is the piece's rhetorical engine — he concedes the feeling before contesting the conclusion. **The self-implicating data point.** The line that gives the piece its credibility: *"90% of the stuff I've vibe-coded is sitting on GitHub, gathering dust."* He's not exempting himself. Vibe-coding is great at generation and bad at persistence, and he's Exhibit A. This is the same 90%-abandonment shape MemberPress cites for vibe-coded startups, arrived at from personal experience rather than vendor estimate — two independent roads to the same figure. **The external corroboration.** He anchors the point in a tweet that hit his timeline mid-conversation: a team that had built an internal tool by vibe-coding *went back to Linear* because maintaining their own tool "was taking away from their actual work's bandwidth." This is the concrete failure mode — vibe-coding doesn't just leave abandoned repos, it can create a maintenance tax that exceeds the value of the thing built. The build was cheap; the upkeep wasn't. **The market split — a reasonable bet, not a proof.** Coords draws the line explicitly: for "small websites and landing pages," vibe-coding will take market share from WordPress; for "something as complicated as publishing or e-commerce," he's "not so sure." This is the same low-end/high-end split the MemberPress piece makes, and it's the sensible read — but it's a prediction grounded in intuition about complexity, not a demonstrated boundary. The honest framing ("I'm not so sure") is better than false certainty. **The stability argument, borrowed.** He endorses MacSparky's framing: *"Pick one big thing. Do it really well. Spend the other eleven months making the thousand small things people actually touch every day feel solid."* Then his own gloss: new features are marketing, but "you can't ignore the paper cuts that accumulate over time. Your users certainly won't." This is the transferable strategic claim — feature velocity is a marketing metric; perceived quality is a retention metric, and they're often in tension. **The disclosure and the pitch.** He closes by stating Woo is spending the quarter in maintenance mode clearing its GitHub backlog (linking Woo's "Core Foundations" post), and plugs a WP Minute event about Woo's direction. The self-disclosure ("we're doing exactly this") strengthens the argument — he's not prescribing maintenance to others while shipping features himself. The event plug is mild content-marketing, appropriate to a personal blog and not distorting. **Contested and uncertain.** Whether vibe-coding genuinely can't handle complex e-commerce, or just can't *yet* (the piece asserts intuition); whether the 90%/Linear examples generalize or are selected; and whether "maintenance mode" is a durable strategy or a one-quarter narrative. The core distinction — generation ≠ sustainability — is sound; the boundary claims are bets. ## 🗒️ Notes Not a transcript; no timestamps. Dense notes, in document order. - **The frame.** Decades-old software + AI's ability to "execute random ideas" creates false pressure to ship daily; but code "run, extended, modified, and personalized on millions of live websites" demands caution. - **The cost-scales-with-install-base logic.** Caution isn't timidity — the blast radius of a mistake scales with the install base, and WordPress/Woo's is huge. (Cross-link: the wp2shell core-RCE in the same inbox is the extreme case of exactly this — one core bug, millions of sites.) - **The honest admission.** Maintenance "can feel frustrating," like "routine maintenance, not building the new and shiny"; small iterations take longer because you "triple-check everything before you ship." - **The turn.** "That quality and care… is what makes good software great. It's why something lasts." - **The self-implicating stat.** "90% of the stuff I've vibe-coded is sitting on GitHub, gathering dust." Generation is easy; persistence is the hard part. (Same shape as MemberPress's vibe-coded-startup abandonment figure, from personal experience.) - **The corroborating tweet.** A team reverted from a vibecoded internal tool back to Linear because maintaining it "was taking away from their actual work's bandwidth." The maintenance tax exceeded the tool's value. - **The market split.** Vibe-coding will take low-end share (small sites, landing pages); "for something as complicated as publishing or e-commerce, I'm not so sure." A reasonable bet, not a proof. - **The stability argument (borrowed, MacSparky).** "Pick one big thing. Do it really well. Spend the other eleven months making the thousand small things people actually touch every day feel solid." - **The retention gloss.** "New features are great for marketing… you can't ignore the paper cuts that accumulate over time. Your users certainly won't." Feature velocity = marketing metric; perceived quality = retention metric. - **The disclosure.** Woo is in maintenance mode this quarter, clearing its GitHub backlog (Core Foundations post). Practicing what it preaches. - **The pitch.** WP Minute event plug about Woo's direction — mild, appropriate content-marketing. ## 📚 References - [The article — Brian Coords](https://www.briancoords.com/maintaining-over-building/) - [MacSparky — one big thing a year](https://www.macsparky.com/blog/2026/07/apple-should-just-do-one-big-thing-a-year/) — the borrowed stability argument - [WooCommerce Core Foundations](https://woocommerce.com/posts/woocommerce-core-foundations/) — the maintenance-quarter primary source - [Neha Kalani tweet](https://x.com/thericebowlgirl/status/2081575149334335552) — the revert-to-Linear anecdote - [MemberPress — "WordPress Lost Market Share and Got Stronger"](https://memberpress.com/blog/wordpress-lost-market-share-got-stronger-heres-why/) — the vibe-coding-hangover argument this piece parallels (same inbox) - [WP Minute — What's New With Woo event](https://thewpminute.com/event/whats-new-with-woo/) ## 🗣️ Paraphrase - Working on decades-old software is distinctive: AI makes it easy to execute ideas quickly, tempting people to expect large platforms to ship features daily, but software running on millions of live sites demands caution. - That caution can feel like unglamorous maintenance rather than building something new, and small changes take longer because everything must be triple-checked before shipping. - But that care is what makes software durable, whereas most of the author's own vibe-coded projects sit abandoned on GitHub. - A timely example: a team abandoned a vibecoded internal tool and returned to Linear because maintaining their own tool consumed the bandwidth for their actual work. - Maintenance is hard, essential work that AI does not eliminate. - Vibe-coding will likely take market share from WordPress for small sites and landing pages, but the author doubts it for complex publishing or e-commerce. - He endorses the view that users want stability — do one big thing well each year and spend the rest of the time making the everyday details feel solid. - New features serve marketing, but accumulated small annoyances drive users away if ignored. - Woo is spending the quarter in maintenance mode clearing its GitHub backlog, and the author invites readers to a community event about Woo's direction. ## 📰 Newsletter **A Woo engineer just made the least glamorous and most important argument in WordPress right now: maintenance is the job, and AI doesn't change that.** Brian Coords' short post is a corrective to the mood that AI means big platforms should be shipping features daily. His counter is grounded in the thing that actually constrains mature software: when your code runs on *millions of live sites*, caution isn't timidity — a mistake's blast radius scales with your install base. (If you want the extreme version of that, look at the wp2shell core RCE from this same week: one bug, everyone exposed.) What makes the piece land is that he doesn't pretend maintenance is fun. It feels like drudgery. Small changes take three times as long because you have to triple-check before you ship. And then the turn: *that's exactly what makes software last.* He implicates himself too — "90% of the stuff I've vibe-coded is sitting on GitHub, gathering dust." Generation is easy. Keeping something alive is the hard part, and AI made generation cheaper without making maintenance cheaper. Arguably it made maintenance *worse*, by making it trivial to produce more code that someone now has to sustain. The example he cites is the whole thesis in one tweet: a team that vibecoded an internal tool went *back to Linear*, because maintaining their own tool was eating the bandwidth for their real work. The build was free. The upkeep wasn't. His market read is the sensible one, and he's honest that it's a bet: vibe-coding will take the low end — landing pages, five-page sites — but for real publishing and e-commerce, "I'm not so sure." That's the same split MemberPress argued from the market-share side this week, reached here from the maintainer's chair. The strategic line worth stealing is borrowed from MacSparky: *pick one big thing, do it really well, and spend the other eleven months making the thousand small things people actually touch every day feel solid.* Feature velocity is a marketing number. Perceived quality is a retention number. They pull against each other, and users feel the paper cuts even when the changelog looks impressive. And credit where due: he discloses that Woo is spending this quarter in exactly this mode — maintenance, clearing the GitHub backlog. He's not selling other people a discipline he's skipping. For the WordPress ecosystem, the takeaway is a reframe: **"maintenance mode" should be a stated strategy you're proud of, not a quiet gap between releases.** The plugins and platforms that outlast the vibe-coding wave will be the ones that treated the unglamorous work as the actual work. ## ✅ Action Items #### DevRel - Developer advocacy: make "maintenance as strategy" a first-class narrative — the ecosystem over-celebrates launches and under-celebrates the sustaining work that retains users. Coords' framing is a model. - Education: teach the generation-vs-sustainability distinction directly; the 90%-abandoned and revert-to-Linear examples are memorable teaching cases for why "I vibe-coded it in an afternoon" is the start of the cost, not the end. - Developer experience: invest in the tooling that lowers *maintenance* cost (tests, migrations, deprecation paths), since AI has lowered generation cost but not upkeep cost. - Developer marketing: reframe stability and paper-cut-fixing as marketable, not just features — "we made the thousand things you touch feel solid" is a real message. - Community management: none applicable beyond the narrative point. - Internal/external/cross-project: adopt "maintenance quarter" as a legitimate, announceable state rather than an apologetic one. #### OSPO - Policy & Governance: formalize maintenance-mode as a sanctioned project state with its own success metrics (backlog burndown, paper-cut closure) so it's fundable and defensible, not treated as stagnation. - License Compliance: none applicable to this source. - Security Management: **directly relevant** — the "cost scales with install base" logic is the security argument too. Maintenance capacity *is* security capacity; a backlog-clearing quarter is also a vulnerability-surface-reduction quarter. Pair this framing with the wp2shell response. - Software Inventory: a maintenance strategy needs an accurate backlog/inventory to burn down; if you can't see the debt, you can't prioritize it. - Developer Support: none applicable to this source. - Community Engagement: fund maintenance labor explicitly — it's the least-glamorous and most-load-bearing contribution, and the hardest to recruit volunteers for. - Strategic Alignment: report maintenance as a strategic investment with retention/security ROI, not as overhead. #### Community - Maintainers: **the core audience** — this validates the unglamorous work and gives language for defending it. "Triple-check before you ship" on a large install base is professionalism, not slowness. - Contributors: the highest-value contributions to mature projects are often maintenance, not features; frame first-time-contributor paths accordingly. - Sponsors: maintenance is the funding gap the whole ecosystem struggles with; this piece is an argument to close it. - Ecosystem: coordinate on shared maintenance burdens (deprecations, compatibility) rather than each project carrying them alone. #### WordPress - Core: the "one big thing + a thousand small fixes" cadence maps onto WordPress's own release debate — worth reading against the WP 7.1 "no blockbuster, many annoyances fixed" framing in the same inbox, which is exactly this strategy in practice. - Core Performance: paper-cut fixing and performance are the same retention argument; both are maintenance disciplines. - Core AI: relevant caution — AI lowers the cost of *adding* to core, which raises the maintenance burden; guard against feature-generation outpacing sustaining capacity. - **Core Program Team:** legitimize "maintenance release" as a first-class release type with its own success criteria. - Mobile / Playground / Photos / TV / Polyglots / Meta / Openverse: none directly applicable to this source. - Community: model maintenance-mode announcements as a norm (Woo's Core Foundations post is the template). - Training: a lesson on maintaining vs building — technical debt, deprecation paths, backwards compatibility — aimed at plugin developers. - Marketing: adopt the "we made things feel solid" message class alongside feature launches. - Support: paper-cut backlog closure is directly a support-load-reduction strategy; quantify it that way. - Design: UX paper cuts are the design-side of this argument; a maintenance quarter should include design-debt closure. - Documentation: maintenance work is under-documented relative to features; document the sustaining work too. - Hosting: stability over feature-velocity is what hosts' customers actually want; align messaging. - Tide: technical-debt and maintenance signals could become scored quality indicators. - Themes / Plugins: **strongly relevant** — the vibe-coding market split means theme/plugin developers competing at the low end face real pressure, while those handling genuine complexity (commerce, publishing) have a durable moat. Position accordingly, and treat maintenance as the moat. #### The WPOCC - Programs: a maintenance-focused fellowship or funded maintainer stipend addresses exactly the labor gap this piece names. - Projects: adopt announced maintenance quarters with public backlog burndown as a demonstrated practice. - Funding experiments: fund maintenance directly — it's the contribution type least served by existing incentives. ### FAIR - Technical independence: maintenance capacity is what keeps a platform independent and durable; a federated ecosystem still depends on someone sustaining shared core. - Policies and covenants: a covenant that values and funds maintenance, not just feature contribution, would address the structural under-incentive. - Productized governance artifacts: "maintenance quarter with public backlog burndown" is itself a reusable governance artifact. ## 🧪 Hypotheses 1. **Generation lowers, upkeep doesn't.** AI coding tools reduce time-to-first-version far more than they reduce total lifecycle maintenance cost, so the maintenance share of software TCO rises as AI adoption grows. 2. **Vibe-coded abandonment is high.** A large majority of vibe-coded personal/internal projects are abandoned within months (Coords' anecdotal 90%), materially higher than for conventionally-built equivalents. 3. **Maintenance tax can exceed build value.** For a nontrivial fraction of vibecoded internal tools, cumulative maintenance cost exceeds the value delivered, driving reversion to established tools (the Linear example). 4. **Complexity is the vibe-coding boundary.** Vibe-coding's market penetration is inversely related to domain complexity — high in landing pages, low in commerce/publishing — and the boundary is stable rather than closing quickly. 5. **Paper cuts drive churn.** Accumulated small UX defects predict user attrition better than absence of new features predicts it. 6. **Announced maintenance is defensible.** Publicly framing a maintenance period as strategy (vs staying silent) improves stakeholder/user perception rather than reading as stagnation. ### 📊 Methodology - **H1 (generation vs upkeep).** Instrumented lifecycle study: track time-to-first-version and cumulative maintenance hours for matched projects built with and without AI assistance. Prediction: AI compresses the first far more than the second, so maintenance's TCO share rises. The measurement challenge is attributing maintenance hours cleanly over a long horizon. - **H2 (abandonment rate).** Cohort analysis of public repos self-tagged or detectably vibe-coded vs conventionally built, matched on size and domain, measuring commit-activity decay. Confound: vibe-coded projects skew toward experiments, so match on stated intent where possible. - **H3 (maintenance tax).** Case-series of teams that adopted then abandoned vibecoded internal tools; reconstruct build cost vs cumulative maintenance cost and the reversion trigger. Qualitative but directly tests the Linear anecdote's generality. - **H4 (complexity boundary).** Track vibe-coding market share by application category (landing page → blog → publishing → commerce) over time; test whether the boundary is stable or moving. The interesting result is the *slope*, not the snapshot. - **H5 (paper cuts and churn).** Correlate a measured "paper-cut index" (minor UX defect count/severity) with retention across products, controlling for feature-release cadence. Coords' and MacSparky's claim predicts paper cuts dominate. - **H6 (announced maintenance).** Message experiment or before/after study of stakeholder sentiment around maintenance periods framed as strategy vs unframed. Woo's Core Foundations announcement is a natural case to track. ### ❓ Questions - Is the complexity boundary stable or closing? Coords bets vibe-coding can't do complex e-commerce; the honest question is whether that's a permanent limit or a "not yet." The answer determines Woo's actual exposure. - Does AI *increase* net maintenance? If generation is cheap and upkeep isn't, the ecosystem may be accumulating maintenance debt faster than it can service it — the opposite of the productivity story. - How much of "maintenance mode" is strategy vs narrative? Woo framing a cleanup quarter as foundations is smart and possibly also cover for a slower feature period. Both can be true; which dominates? - Are the 90% and Linear examples representative? Both are memorable illustrations from a maintainer motivated to valorize maintenance. What does the base rate actually look like? - What's the maintenance-funding mechanism? Everyone agrees maintenance matters and nobody wants to fund it. This piece names the value; it doesn't solve the incentive. - Does the WP 7.1 "many small fixes" release vindicate the thesis in real time? It's the same-week test case — a WordPress release explicitly framed as paper-cut fixing over blockbuster features. ### 🔮 Future Research - **Maintenance economics of AI-generated code.** The central open question: does cheap generation raise total maintenance burden, and by how much? This reframes the entire AI-productivity debate if the answer is "substantially." - **The vibe-coding complexity frontier.** Longitudinal tracking of where vibe-coding succeeds and fails by domain complexity, to distinguish a stable boundary from a moving one. - **Maintenance as fundable work.** Mechanisms that make sustaining labor attractive to fund and to volunteer for — the ecosystem's chronic gap. - **Paper-cut science.** A rigorous link between minor-defect accumulation and churn would turn "fix the small stuff" from folk wisdom into a measured strategy. - **Announced-maintenance as strategy.** Whether publicly valorizing maintenance changes contributor recruitment, user retention, and perception — testable across projects adopting the framing. ### 💡 Implications - **Practice.** The reframe worth adopting: treat maintenance as the work, not the gap between work. On a large install base, "triple-check before you ship" is professionalism, and generation speed is a trap if it outruns your capacity to sustain what you generate. For anyone using AI to build: the afternoon it took to make the thing is the smallest cost it will ever have. - **Policy.** Maintenance should be a sanctioned, funded, announceable state with its own success metrics (backlog burndown, defect closure), not treated as stagnation. This is directly a security posture too — maintenance capacity is vulnerability-surface-reduction capacity, which ties this piece to the wp2shell response in the same inbox. - **Security.** The "cost scales with install base" logic *is* the security argument. A platform on millions of sites cannot move fast and break things, because "things" are other people's businesses. A maintenance quarter is also a hardening quarter. - **Education.** Two teachable moves: the generation-vs-sustainability distinction (why "I vibe-coded it" is the start of the cost curve), and the marketing-metric-vs-retention-metric tension (feature velocity vs perceived quality). Both generalize past WordPress to any software strategy. - **Funding models.** The piece names the ecosystem's hardest funding problem without solving it: maintenance is the most load-bearing and least-incentivized contribution. Pooled maintainer stipends and funded maintenance quarters are the interventions this argument supports — the WPOCC/FAIR-shaped answer to a gap the market under-serves. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Roughly Flesch-Kincaid Grade 8–9; standard. Very short (~450 words), plain, conversational. Genuinely accessible — no jargon beyond "vibe-coding," which the context defines. The one prerequisite is knowing what vibe-coding and technical debt are. #### 👀 Visual learners - Present: an embedded tweet provides one concrete visual anchor. - Improve: the argument has an implicit 2×2 (complexity × vibe-coding fit) that a small diagram would make instantly graspable; none is offered. #### 🔊 Aural learners - Present: nothing; text only, though it points to an upcoming live event. - Improve: the conversational register would read well aloud; the event is the aural companion. #### 🗣️ Verbal learners - Present: strong — memorable, quotable lines ("90% of the stuff I've vibe-coded is sitting on GitHub, gathering dust"; the borrowed "thousand small things people actually touch") carry the argument efficiently. - Improve: little to fault for the length; the borrowed MacSparky quote does heavy lifting, which is fine but means the sharpest line isn't his. #### 🧩 Kinesthetic learners - Present: implicitly actionable (adopt maintenance mode; clear a backlog) and self-demonstrated (Woo is doing it). - Improve: no concrete "how to run a maintenance quarter" scaffold; the Core Foundations link partially fills this. #### 🧠 Logical learners - Present: a clean core argument (cost scales with install base → caution is rational → maintenance is the durable work) supported by two illustrations and a borrowed strategic principle. - Improve: the illustrations are anecdotes, and the "vibe-coding can't do complex e-commerce" claim is asserted; a logical reader will note the honest hedge ("I'm not so sure") is doing the work a demonstration would. #### 🧑‍🤝‍🧑 Social learners - Present: sociable and current — sparked by a coworker chat and a timeline tweet, ending in a community-event invitation. - Improve: well-served; the piece is essentially a conversation-starter with a built-in next venue. #### 🧘‍♀️ Solitary learners - Present: short, self-contained, reflective — easy to absorb alone. - Improve: no self-assessment of one's own build-vs-maintain balance; a prompt would extend it. #### 🌿 Naturalistic learners - Present: genuinely strong — the whole frame is lifecycle and sustainability ("why something lasts," "paper cuts that accumulate over time"). Software as a living system that must be tended, not just built, is the piece's native metaphor. - Improve: the ecological framing is implicit; naming it (software as ecosystem requiring maintenance to persist) would sharpen the already-present instinct. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: clean blog structure, clear heading, well-formed paragraphs and blockquotes. - Improve: the embedded tweet's accessibility depends on the third-party embed; a text fallback of the quoted tweet (which the article does include inline) is the right call and is present. Maps to WCAG 2.2 AA 1.1.1 Non-text Content. #### Keyboard navigation - Present: standard content page. - Improve: the Twitter embed iframe is the usual keyboard-focus wildcard; the inline text quote mitigates it. Maps to WCAG 2.2 AA 2.1.1 Keyboard. #### Contrast and readability - Present: site theming, meets baseline. - Improve: nothing content-specific. Maps to WCAG 2.2 AA 1.4.3 Contrast (Minimum). #### Text resizing and reflow - Present: prose reflows cleanly. - Improve: the tweet embed can be a reflow weak point at high zoom; text fallback helps. Maps to WCAG 2.2 AA 1.4.10 Reflow. #### Media and captions - Present: not applicable — no audio/video in the post (the event is external). - Improve: none. #### Forms and interactions - Present: standard comment form, labeled. - Improve: none notable. #### Standards reference - Aggregate: a clean, accessible short post. The only mild surface is the third-party Twitter embed, adequately mitigated by the inline text quote. No substantive barriers. ### 🌍 DEIB Assessment #### Cultural breadth - Present: the software-maintenance theme is universal; no region-specific assumptions. - Improve: the frame of reference (WordPress/Woo, Silicon-Valley tooling like Linear, US tech-blog culture) is Western-tech-centric, appropriate to audience but not broadened. #### Inclusive language - Present: plain, neutral, professional throughout; no loaded or exclusionary framing. - Improve: little to fault; "vibe-coding" is used descriptively, not pejoratively. #### Neurodiversity support - Present: short, single-thesis, well-structured, low cognitive load — genuinely easy to process. - Improve: little needed; the brevity and clarity are accommodations in themselves. #### Representation - Present: cites a range of voices (a coworker, a woman developer via the tweet, MacSparky) rather than a single authority. - Improve: the perspectives are all within the same professional tech milieu; the users who feel the "paper cuts" are spoken about, not heard from. #### Psychological safety - Present: notably good — the self-implication ("90% of my vibe-coded stuff is abandoned") and the validation of maintainers' often-devalued work create safety for the audience most likely to feel unseen. It's a generous piece toward the people doing unglamorous work. - Improve: minimal; the tone is humble and inclusive throughout, with no side to demonize (even vibe-coding is granted its legitimate low-end niche). ### ✅ Logical Validity #### Strong reasoning - **Cost-scales-with-install-base.** The foundational argument — caution is rational because a mistake's blast radius scales with millions of live sites — is valid and correctly identifies why mature-platform velocity *should* differ from a startup's. It's the load-bearing claim and it holds. - **Generation ≠ sustainability.** Distinguishing the ease of building from the difficulty of maintaining is a real and important separation, and the self-implicating 90% figure makes it credible rather than preachy. - **Self-consistency (disclosure).** Stating that Woo is *itself* in maintenance mode closes the do-as-I-say gap — the argument is strengthened by the author practicing it, and the honesty is disarming. - **Honest hedging.** "For something as complicated as publishing or e-commerce, I'm not so sure" correctly marks a prediction as a prediction rather than overclaiming a demonstrated limit. #### Fallacies - **Anecdotal evidence.** The two supports — his own 90%-abandoned projects and one team's revert-to-Linear tweet — are illustrations, not evidence. **Weakness:** both are selected, memorable, and from a maintainer motivated to valorize maintenance; the base rate is unknown. **Fix:** present them as illustrative and note they're not systematic — which the casual register half-does but doesn't state. - **Asserted boundary.** "Vibe-coding won't do complex publishing/e-commerce" is intuition, not demonstration, and the complexity frontier may be moving. **Weakness:** the claim is load-bearing for Woo's competitive position and rests on a feeling. **Fix:** frame explicitly as a bet with a falsification condition (what would change his mind). The "I'm not so sure" hedge partly covers this. - **Appeal to authority (mild, borrowed).** The strategic core is MacSparky's quote, endorsed rather than independently argued. **Weakness:** the sharpest line is imported and its own support isn't examined. **Fix:** minor — endorsing a well-put external argument is legitimate, but the piece leans on it for its thesis. - **Undisclosed-until-the-end interest (disclosed).** The piece is partly promotion for a Woo event and blog post, and the author works at Woo. **Weakness:** the maintenance-is-virtuous framing aligns with Woo's current narrative need. **Mitigating:** he discloses the Woo affiliation and the maintenance quarter explicitly, so this is transparent standpoint rather than hidden interest. **Fix:** none needed; the disclosure is present. #### Tone of voice - Humble, conversational, and self-implicating — the register of a practitioner thinking out loud rather than pronouncing. The "90% of my stuff is gathering dust" admission sets a generous, non-preachy tone. - Measured on the contested claim — "I'm not so sure" is a deliberate refusal to overclaim, and it reads as honesty rather than hedging-for-cover. - Warm toward the audience it's defending (maintainers) without being hostile to the alternative (vibe-coding gets its legitimate niche). No side is demonized, which is rare and makes the argument more persuasive. - Lightly promotional at the close (the event plug), but transparently so and appropriate to a personal blog. ### 🛡️ DARVO Analysis - **Deny:** No DARVO pattern present. There is no accusation in play and nothing being denied — it's a reflective argument, not a defense against a charge. The author's stance toward the opposing view (vibe-coding) is to *grant* it a legitimate niche, the opposite of denial. - **Attack:** Not present. Vibe-coding and its advocates are not attacked — vibe-coding is credited with genuine value at the low end, and the author implicates his own vibe-coded projects rather than others'. No party is disparaged. - **Reverse victim/offender:** Not present. No role reversal, no victim framing, no grievance. If anything the author positions *maintainers* (himself included) as under-appreciated rather than wronged, which is advocacy for a devalued role, not a DARVO reversal. - **Emotional cues and rhetoric:** The persuasion runs on self-implication, concession, and a borrowed strategic principle — humble rather than combative. Applying the DARVO frame here is a category error; the frame targets defensive responses to accusation, and this is an unprompted, generous reflection. The honest finding is absence, and the piece's real (mild) weaknesses are evidentiary — anecdote and an asserted boundary — logged under Fallacies. ## 🎯 Conclusion - **Bottom line.** The durable idea: **maintenance is the hard, unglamorous, non-optional work that AI doesn't erase — and may increase, by making it trivial to generate more code that then has to be sustained.** Generation and sustainability are different jobs; the second is where durability lives, and on a platform running millions of sites, "triple-check before you ship" is professionalism, not slowness. - **The strategic line to keep.** Borrowed from MacSparky but correctly chosen: do one big thing well, and spend the rest of the time making the thousand small things people actually touch feel solid. Feature velocity is a marketing metric; perceived quality is a retention metric; they pull against each other, and users feel the paper cuts even when the changelog looks impressive. - **What's a bet, not a proof.** "Vibe-coding won't handle complex publishing/e-commerce" is intuition, honestly flagged as such, and the complexity frontier may be moving. The 90%-abandoned and revert-to-Linear examples are memorable illustrations from a maintainer motivated to make this case — keep them as illustrations, not data. - **Read it in cluster.** This is the maintainer's-chair version of the argument MemberPress makes from the market-share side and wp2shell demonstrates from the security side, all in the same inbox: generating software is cheap now, and *sustaining* it — safely, on a huge install base — is the whole game. The three together are a stronger case than any one alone. - **The residue.** For the WordPress ecosystem specifically: make "maintenance mode" a stated strategy you're proud of, fund the sustaining work that no one volunteers for, and treat the vibe-coding market split as a moat — the projects handling real complexity, maintained with real care, are the ones that outlast the wave. ## 🔄 Refactor Appendix — Maintaining over Building > 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] Generation is cheap; sustaining software is the hard part > [!quote] ID:rw_pending > Meanwhile 90% of the stuff I've vibe-coded is sitting on GitHub, gathering dust. **Context & use**: - The self-implicating data point - The whole thesis in one self-aware line: AI made building cheap without making maintenance cheap. Credible because he's Exhibit A rather than pointing at others. Same 90%-abandonment shape as the MemberPress vibe-coding-hangover figure, reached from personal experience — two independent roads to the same number. **Tags**: #xref #share #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H2] Caution scales with install base, not timidity > [!quote] ID:rw_pending > when your software is run, extended, modified, and personalized on millions of live websites, you still have to be cautious. **Context & use**: - The opening frame - The load-bearing argument: a mistake's blast radius scales with the install base, so mature-platform velocity *should* differ from a startup's. This is also the security argument (cross-link the wp2shell core-RCE: one bug, millions of sites) — maintenance capacity is vulnerability-surface capacity. **Tags**: #xref #share **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H3] One big thing well, plus a thousand small solid fixes > [!quote] ID:rw_pending > Pick one big thing. Do it really well. Spend the other eleven months making the thousand small things people actually touch every day feel solid. **Context & use**: - Borrowed from MacSparky, endorsed as the strategy - The transferable cadence: feature velocity is a marketing metric, perceived quality is a retention metric, and they pull against each other. Read against the WP 7.1 "no blockbuster, many annoyances fixed" release in the same inbox — this strategy in live practice. **Tags**: #xref #share **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Cheap generation raises the maintenance bill, it doesn't lower it **Claim** (one sentence, Courtney's voice): Lowering the cost of producing software increases the total burden of maintaining it, because every cheaply-generated artifact still has to be sustained by someone. **Evidence pointer**: [[#H1]] > [!quote] > Maintenance isn't glamorous, but it's hard, essential work that doesn't disappear because of AI. **Scope & conditions**: Holds wherever generated artifacts persist and require upkeep — code, content, infrastructure, documentation. The cheaper generation gets, the more artifacts exist, and maintenance is the constraint that doesn't scale down with generation cost. Breaks for genuinely disposable artifacts (a one-off script, a throwaway landing page) where no maintenance is ever required — which is exactly the low-end niche where vibe-coding legitimately wins. The distinction *is* the boundary: does the thing need to persist? **Links**: - [[Technical debt]] — because extends - [[Total cost of ownership]] — because applies-in - [[Vibe-coding hangover]] — because evidence-for - [[Disposable vs durable software]] — because contrasts on persistence <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Three-source cluster in the same inbox on the same claim from different chairs: Coords (maintainer), MemberPress (market-share), wp2shell (security). "Generating software is cheap; sustaining it safely on a huge install base is the game." Synthesis-note candidate. — #fleeting #inbox #xref - [F2] The WP 7.1 release ("no blockbuster, many annoyances fixed") is this thesis in live practice — a same-week test case. Worth linking the WPBeginner/WP Minute 7.1 notes to this one. — #fleeting #inbox #xref - [F3] "Maintenance capacity is vulnerability-surface capacity" — a maintenance quarter is also a hardening quarter. Pair with the wp2shell response framing. Good line for OSPO/security writing. — #fleeting #inbox #articleseed - [F4] The ecosystem's chronic gap named again: maintenance is the most load-bearing, least-incentivized contribution. WPOCC/FAIR pooled-maintainer-stipend argument. Recurs across the whole batch. — #fleeting #inbox #articleseed - [F5] Open empirical question worth an article: does cheap AI generation RAISE net maintenance burden across a codebase/ecosystem? If yes, it reframes the entire AI-productivity story. — #fleeting #inbox #articleseed ### → Things 3 (max 2 actions) - [ ] Draft the three-source synthesis note (Coords + MemberPress + wp2shell): generation is cheap, sustaining safely at scale is the game — for the WordPress/AI wiki — #things - [ ] Add "maintenance capacity = vulnerability-surface capacity" to the security/OSPO notes, linked to the wp2shell response — #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Maintaining Over Building.md|Maintaining Over Building by Brian Coords (Woo/Automattic)]] ## Highlights - Working on software that's been around for decades is interesting. With AI super-charging your ability to execute random ideas, it's tempting to believe that large platforms should be moving faster and shipping features daily. The truth is, when your software is run, extended, modified, and personalized on millions of live websites, you still have to be cautious. ([View Highlight](https://read.readwise.io/read/01kyjmwae1jw00qqdcg6esn8gj)) - Note: [H2] The load-bearing argument: a mistake's blast radius scales with the install base, so mature-platform velocity SHOULD differ from a startup's. "Run, extended, modified, and personalized on millions of live websites" — caution is rational, not timid. THIS IS ALSO THE SECURITY ARGUMENT. Cross-link the wp2shell core-RCE in the same inbox: one bug, millions of sites exposed — the extreme case of exactly this logic. "Maintenance capacity is vulnerability-surface capacity" — a maintenance quarter is also a hardening quarter. Good line for OSPO/security writing. Read against the WP 7.1 release framing ("no blockbuster, many annoyances fixed") in the same inbox — that's this thesis in live practice, same week. And the MacSparky "one big thing well + a thousand small solid fixes" strategy Coords endorses is the cadence version: feature velocity is a marketing metric, perceived quality is a retention metric, and they pull against each other. - Tags: atom/literature/h2, platform-stability - That quality and care, however, is what makes good software great. It's why something lasts. Meanwhile 90% of the stuff I've vibe-coded is sitting on GitHub, gathering dust. ([View Highlight](https://read.readwise.io/read/01kyjmvvcdkabfbt5cvmqny1z7)) - Note: [H1] The whole thesis in one self-aware line: AI made building cheap without making maintenance cheap, and he's Exhibit A — "90% of the stuff I've vibe-coded is sitting on GitHub, gathering dust." Credible precisely because he implicates himself rather than pointing at others. Same 90%-abandonment SHAPE as the MemberPress vibe-coding-hangover figure (also in this inbox), reached from personal experience rather than vendor estimate — two independent roads to the same number. GENERAL PRINCIPLE (P1): cheap generation RAISES the maintenance bill, it doesn't lower it — every cheaply-generated artifact still has to be sustained by someone. The distinction is persistence: does the thing need to last? Disposable one-offs are exactly the low-end niche where vibe-coding legitimately wins. THREE-SOURCE CLUSTER on the same claim from different chairs: Coords (maintainer), MemberPress (market-share), wp2shell (security). Generating software is cheap; sustaining it safely on a huge install base is the game. - Tags: vibe-coding-debt, atom/literature/h1, atom/zettel/z1