{"slug": "your-ai-policy-doesn-t-have-to-apply-to-you", "title": "Your AI Policy Doesn't Have to Apply to You", "summary": "Stdlib, an open-source project, has not adopted an AI-use policy despite drafts from December 2025, citing discomfort with publishing rules it won't follow itself. The project's co-maintainer Philipp Burckhardt participated in METR's randomized trial on AI's effect on open-source developers, and contributor Karan Anand described using the codebase as a prompt. The blog argues that disclosure of AI assistance, not gating, is the key responsibility, and that contributors are accountable for understanding what they submit.", "body_md": "# Your AI Policy Doesn't Have to Apply to You\n\nNot applying your own rules to yourself isn't always hypocrisy. Sometimes it's just correct.\n\nA confession: stdlib doesn't have an AI-use policy.\n\nIt isn't for lack of trying. There's an open RFC proposing guidance on AI usage—citations to prior art, disclosure requirements, a carve-out for \"good first issue\" [1]—and a draft PR with the policy text, both of which are from December 2025.\n\nBoth are still open. Both are still drafts.\n\n[[2]](#fn2)It's not because AI usage is hypothetical here, either. We've had stdlib core contributors participating in [METR's randomized trial](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/?ref=blog.stdlib.io) on AI's effect on experienced open-source developers since 2025. Philipp Burckhardt, one of stdlib's co-maintainers, wrote up [his experience](https://blog.stdlib.io/reflection-on-the-metr-study-2025/) on the project blog, including which tools he uses and how his workflow changed. [3] More recently, Karan Anand described\n\n[using the codebase itself as the prompt](https://blog.stdlib.io/the-codebase-is-the-prompt/).\n\nSo: we use these tools, we've said so in public, and (beyond some check boxes in our PR template) we still haven't codified what we expect from anyone else. We've gotten stuck, and one of the sticking points has been an obvious one—discomfort with publishing a rule we're not going to hold ourselves to.\n\nThis is a real objection. It's also, I've come to think, the wrong one, and we're not the only project stalling out on it. The question isn't *whether* AI is being used on this project. It's whether there's anything written down that a contributor can read.\n\nPlenty of projects got past this. Melissa Weber Mendonça keeps a running catalog of what's been published; [4] Kate Holterhoff's RedMonk survey was up to eighty-six policies as of April 2026, dimensionalized by stance and primary concern;\n\nCHAOSS's AI-alignment working group runs a companion list with an incident-and-discussion layer.\n\n[[5]](#fn5)\n\n[[6]](#fn6)Given the scope of the discourse around AI usage in open source, this is a strikingly small corpus—and a young one. [7] Nobody is late to a settled consensus here. As James Fredley put it, after a tier-by-tier read from the primary documents: \"there is no single industry-wide standard yet.\"\n\n[[8]](#fn8)What the policies themselves agree on is narrower than it first looks. Stance splits three ways—permissive, ban, undecided—and the stated concerns split at least three ways again: code quality, licensing liability, and ethics. Where they *do* line up is on something small and specific: **contributors are responsible for understanding what they submit.** Sean McLellan's case for the `Assisted-by:`\n\nGit trailer states the reasoning plainly—using `Co-authored-by:`\n\nclaims shared authorship, and with it *accountability*. A tool can't hold up its end of that bargain. [9] The trailer itself is one lightweight implementation; the claim underneath it is what travels.\n\nAccountability is what the trailer is *for*; *responsibility* is what the policies actually ask of you. Part of that is legal clarity—the human is the sole *author* of the commit, whatever helped them write it. But what responsibility looks like in practice depends on the author's relationship to the project.\n\nTwo mechanisms tend to get bundled together here. **Disclosure** is a record-keeping rule—the `Assisted-by:`\n\ntrailer, the [AI-assistance section of our own PR template](https://github.com/stdlib-js/stdlib/blob/fd17bfa9bc99c1abbd3d99e882cb18bddab42c08/.github/PULL_REQUEST_TEMPLATE.md?plain=1&ref=blog.stdlib.io#L37-L55)—and what it produces is provenance: *what helped write this*. Everyone takes part in that one. **Gating** is a permission rule: who may use these tools, on what, with how much latitude. What follows is an argument about the gate, not the disclosure.\n\nA maintainer who merges a bad change is still there in three months when it breaks. They wrote the module it broke, or reviewed it, and they will be the one bisecting at midnight to find out why the build went red. Responsibility, for them, isn't a claim. It's a structural fact about where they're standing.\n\nAn infrequent contributor who submits a bad change usually isn't there. Not out of bad faith—that's simply what infrequent means. Whatever *I take responsibility for this* means when they sign off on their PR, it can't mean quite the same thing as it does for a maintainer. The position it's said from is different.\n\nSo a policy that says *you're responsible for what you submit* is asking two structurally different things of two structurally different people, while looking like it asks one thing of everyone. That's roughly where our hypocrisy objection came from. It's also, it turns out, where the objection comes apart.\n\n## The word for it\n\nThere's a word for a rule that behaves this way, and I'm going to use it even though it's unfamiliar, because the precise word does work the familiar ones don't.\n\nA rule can be **defeasible**: correct as a default, and *properly overridden* when the situations it applies to genuinely differ. The everyday version is *the speed limit is 45, except for the ambulance.* The rule holds. The exception is principled. The exception doesn't retroactively invalidate the rule.[[10]](#fn10)\n\nThe open-source policy version goes something like this:\n\nThere's a naïve consistency heuristic: *don't require of others what you wouldn't do yourself*. It's correct for most governance choices. Don't require signed commits if you don't sign yours. Don't require test coverage your codebase doesn't have.\n\nBut it's *defeasible* where the situations genuinely differ, and AI-use policy is the clean case. A maintainer using AI owns the fallout, holds the project's mental model, and can recognize when the output is wrong. A first-time contributor using AI may be offloading understanding to the tool—producing work they can't fully vouch for—and has no accountability chain yet. Those are different situations. Different rules are warranted.\n\nThe distinction comes down to what's underneath the rule. *Because I own the fallout in a way you don't* is principled. *Because I said so* isn't. The trust ledger is what makes the difference legible, and it's why \"just be consistent\" is worse advice than it sounds.\n\nThe naïve-consistency rule is itself defeasible. That's the whole thing. It's a good default, it does honest work most of the time, and this is one of the situations where the exception is warranted rather than merely convenient.\n\nGhostty's `AI_POLICY.md`\n\nlays out the usual disclosure-and-human-in-the-loop rules for contributions, and then closes with this:[[11]](#fn11)\n\nThese rules apply only to outside contributions to Ghostty.\n\nMaintainers are exempt from these rules and may use AI tools at their discretion; they've proven themselves trustworthy to apply good judgment.\n\nTwo sentences. The first says *this policy is for you, the contributor, not for me.* The second says *why.* And the why isn't brash authority—it's a claim about accumulated context. *They've proven themselves.* You can agree with it, or push back on it, or ask what the proving consisted of.\n\nSo: you (potential contributor) can weigh and evaluate the claim. Naming the asymmetry on the page—rather than writing a symmetric-sounding rule and then quietly not applying it to yourself—is the move. It's two sentences. It's been shipped, in public. Just like [a good CONTRIBUTING.md](https://blog.stdlib.io/do-you-want-contributors/), the honest accounting is a kindness.\n\n## \"You're just formalizing hierarchy\"\n\nThere's a critique here I too feel the pull of, and it might be part of what keeps projects like ours from making the move. *You're building a hierarchy where maintainers get one rule and contributors get another.*\n\nThe hierarchy is already there, and has been the whole time—and it's not just maintainers vs. contributors, there are often tiers of trust (maintainers is just a useful shorthand). A maintainer with three years of context on a codebase reads a stranger's PR differently from how they read their own or one of a long-time contributor. The maintainer/reviewer knows what's load-bearing, what's under active refactor, which review objections are terminal versus fixable. None of that is malicious; most of it isn't even conscious. It's what accumulated context does. Call it a \"trust ledger\" (a term I'll return to in a subsequent post).\n\nWhat a written policy does is convert an existing asymmetry from **invisible-and-unchallengeable** into **visible-and-contestable**. That's an accountability gain, not a hierarchy invention. Writing it down is what makes it something you can be held to.\n\nIf you've been sitting on a policy because the *but-I-don't-hold-myself-to-this* objection kept stopping you: note it, acknowledge that it does ethical work worth respecting in most contexts, *and* it doesn't apply here in the way it feels like it does. The situations genuinely differ. Different rules are principled when the difference has a reason you can be held to.\n\nI'm not saying every project should ship one; whether it's right for a given project depends on more than fits in a piece this size. What I *am* saying is that this particular reason for stalling—the hypocrisy-avoidance reason, the one that stopped us—is dissolvable.\n\nTake it, if it's useful. Ours has been open since December; I'm hoping this is a step towards closing it out.\n\n[stdlib](https://github.com/stdlib-js/stdlib?ref=blog.stdlib.io) is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.\n\nIf you've enjoyed this post, give us a star 🌟 on [GitHub](https://github.com/stdlib-js/stdlib?ref=blog.stdlib.io) and consider [supporting](https://opencollective.com/stdlib?ref=blog.stdlib.io) the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!\n\n## Acknowledgments\n\nThis work was supported in part by the National Science Foundation under [Award No. 2449410](https://www.nsf.gov/awardsearch/showAward?AWD_ID=2449410&HistoricalAwards=false&ref=blog.stdlib.io).\n\nDisclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.\n\nstdlib-js/stdlib issue\n\n[#9347](https://github.com/stdlib-js/stdlib/issues/9347?ref=blog.stdlib.io), \"[RFC]: Add guidance concerning AI usage\"—proposing disclosure of AI assistance in pull requests and issues, excluding`good first issue`\n\nwork from AI-assisted resolution (per the draft PR's rule 5: \"these issues are intended to help newcomers learn about the project and gain experience with the mechanics of contributing\"), and ruling out model output posted as comments on GitHub or Zulip. Opened December 24, 2025.[↩︎](#fnref1)stdlib-js/stdlib pull request\n\n[#9459](https://github.com/stdlib-js/stdlib/pull/9459?ref=blog.stdlib.io)—the companion draft PR adding the policy text, opened December 31, 2025; still a draft as of this writing.[↩︎](#fnref2)Philipp Burckhardt,\n\n[\"Using AI in the development of stdlib,\"](https://blog.stdlib.io/reflection-on-the-metr-study-2025/)Numerical Bits, July 17, 2025—a reflection on stdlib's participation in METR's[\"Impact of Early-2025 AI on Experienced Open-Source Developer Productivity\"](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/?ref=blog.stdlib.io)study, in which two stdlib core contributors worked randomized project issues under AI-allowed and AI-disallowed conditions—a snapshot from early 2025; both the models and the surrounding tooling have changed considerably since.[↩︎](#fnref3)Melissa Weber Mendonça,\n\n—a community-sourced catalog framed simply as \"a list of policies by different open source projects about how to engage with AI-generated contributions.\" Roughly 100 project rows as of August 2026, plus separate sections for ongoing discussions and adjacent references.`open-source-ai-contribution-policies`\n\n[↩︎](#fnref4)Kate Holterhoff,\n\n[\"The Generative AI Policy Landscape in Open Source,\"](https://redmonk.com/kholterhoff/2026/02/26/generative-ai-policy-landscape-in-open-source/?ref=blog.stdlib.io)RedMonk, February 26, 2026 (with rolling edits through April 12, 2026). The dimensionalized cross-section—stance, primary concern, disclosure requirement, adoption date—of the same underlying corpus Melissa's catalog and CHAOSS's list track from different registers. Companion[visualization site](https://oss-ai-policies.netlify.app/?ref=blog.stdlib.io).[↩︎](#fnref5)CHAOSS AI Alignment Working Group,\n\n[\"Awesome LLM Policy,\"](https://github.com/chaoss/wg-ai-alignment/blob/main/moderation/README.md?ref=blog.stdlib.io)live PR-editable catalog with a nine-part taxonomy—including*discussion*threads and*incident evidence*as first-class categories alongside finished policy artifacts.[↩︎](#fnref6)The adjacent body of work is about as short as the list of trackers. Sviatoslav Sydorenko's\n\n[EuroPython 2026 reference gist](https://gist.github.com/webknjaz/1819dd466cc908ff09e2ed4d934455eb?ref=blog.stdlib.io)collects the maintainer-side tooling and files both Holterhoff's RedMonk piece and the CHAOSS list under \"Surveys of the policy landscape\"; the three trackers each reference the other two.[↩︎](#fnref7)James Fredley,\n\n[\"Assisted-by: How open source projects are drawing the line on AI contributions,\"](https://allthingsopen.org/articles/open-source-ai-contributions-assisted-by-git-trailer-standard?ref=blog.stdlib.io)All Things Open, May 11, 2026. A tier-by-tier read from the primary documents—QEMU, Gentoo, and NetBSD at the total-ban end; LLVM, Fedora, the Linux Kernel, Apache, OpenInfra, OpenTelemetry, and Rocky Linux across the permissive-with-disclosure middle—arguing that`Assisted-by:`\n\nis settling in as the de facto convention over`Co-authored-by:`\n\n, which \"implies legal personhood.\" Fredley is chair of the Apache Grails PMC.[↩︎](#fnref8)Sean McLellan,\n\n[\"Assisted-by git trailer: provenance for AI-assisted commits,\"](https://www.baristalabs.io/blog/ai-assisted-commits-need-provenance-trailer?ref=blog.stdlib.io)Barista Labs, June 20, 2026. Key line: \"Co-authorship says this entity shares authorship and accountability.\" Pulled into stdlib's own trailer discussion by Athan Reines' ([comment](https://github.com/stdlib-js/stdlib/issues/9347?ref=blog.stdlib.io#issuecomment-5052552276)on issue[#9347](https://github.com/stdlib-js/stdlib/issues/9347?ref=blog.stdlib.io))—not necessarily the line's original point of entry into OSS AI-policy discourse, just where this piece's thread of it traces back to.[↩︎](#fnref9)The term has a longer life outside software. H. L. A. Hart,\n\n[\"The Ascription of Responsibility and Rights,\"](http://www.jstor.org/stable/4544455?ref=blog.stdlib.io)*Proceedings of the Aristotelian Society, New Series*49 (1948–1949): 171–194, is the canonical statement of the legal version—rules that hold unless a specific exception overrides them. John L. Pollock,[\"Defeasible Reasoning,\"](https://doi.org/10.1207/s15516709cog1104_4?ref=blog.stdlib.io)*Cognitive Science*11, no. 4 (1987): 481–518, formalizes the everyday version: how people reason with rough-and-ready rules that new information can*defeat*, and what it takes for an override to count.[↩︎](#fnref10)Ghostty,\n\n(fetched 2026-08-03). Iterated in public via PR`AI_POLICY.md`\n\n[#8289](https://github.com/ghostty-org/ghostty/pull/8289?ref=blog.stdlib.io)(initial disclosure rules, August 2025) and PR[#10412](https://github.com/ghostty-org/ghostty/pull/10412?ref=blog.stdlib.io)(hardened into the standalone policy, January 2026).[↩︎](#fnref11)", "url": "https://wpnews.pro/news/your-ai-policy-doesn-t-have-to-apply-to-you", "canonical_source": "https://blog.stdlib.io/your-ai-policy-doesnt-have-to-apply-to-you/", "published_at": "2026-08-12 14:01:46+00:00", "updated_at": "2026-08-12 14:26:21.527453+00:00", "lang": "en", "topics": ["ai-policy", "ai-ethics", "developer-tools"], "entities": ["stdlib", "METR", "Philipp Burckhardt", "Karan Anand", "Melissa Weber Mendonça", "Kate Holterhoff", "RedMonk", "CHAOSS"], "alternates": {"html": "https://wpnews.pro/news/your-ai-policy-doesn-t-have-to-apply-to-you", "markdown": "https://wpnews.pro/news/your-ai-policy-doesn-t-have-to-apply-to-you.md", "text": "https://wpnews.pro/news/your-ai-policy-doesn-t-have-to-apply-to-you.txt", "jsonld": "https://wpnews.pro/news/your-ai-policy-doesn-t-have-to-apply-to-you.jsonld"}}