Not applying your own rules to yourself isn't always hypocrisy. Sometimes it's just correct.
A confession: stdlib doesn't have an AI-use policy.
It 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.
Both are still open. Both are still drafts.
[2]It's not because AI usage is hypothetical here, either. We've had stdlib core contributors participating in METR's randomized trial on AI's effect on experienced open-source developers since 2025. Philipp Burckhardt, one of stdlib's co-maintainers, wrote up his experience on the project blog, including which tools he uses and how his workflow changed. [3] More recently, Karan Anand described
using the codebase itself as the prompt. So: 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.
This 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.
Plenty 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;
CHAOSS's AI-alignment working group runs a companion list with an incident-and-discussion layer.
[5] [6]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."
[8]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:
Git trailer states the reasoning plainly—using Co-authored-by:
claims 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.
Accountability 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.
Two mechanisms tend to get bundled together here. Disclosure is a record-keeping rule—the Assisted-by:
trailer, the AI-assistance section of our own PR template—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.
A 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.
An 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.
So 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.
The word for it #
There'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.
A 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]
The open-source policy version goes something like this:
There'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.
But 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 off 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.
The 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.
The 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.
Ghostty's AI_POLICY.md
lays out the usual disclosure-and-human-in-the-loop rules for contributions, and then closes with this:[11] These rules apply only to outside contributions to Ghostty.
Maintainers are exempt from these rules and may use AI tools at their discretion; they've proven themselves trustworthy to apply good judgment.
Two 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.
So: 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, the honest accounting is a kindness.
"You're just formalizing hierarchy" #
There'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.
The 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).
What 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.
If 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. I'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.
Take it, if it's useful. Ours has been open since December; I'm hoping this is a step towards closing it out.
stdlib 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.
If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!
Acknowledgments #
This work was supported in part by the National Science Foundation under Award No. 2449410.
Disclaimer: 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.
stdlib-js/stdlib issue
#9347, "[RFC]: Add guidance concerning AI usage"—proposing disclosure of AI assistance in pull requests and issues, excludinggood first issue
work 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.↩︎stdlib-js/stdlib pull request
#9459—the companion draft PR adding the policy text, opened December 31, 2025; still a draft as of this writing.↩︎Philipp Burckhardt,
"Using AI in the development of stdlib,"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"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.↩︎Melissa Weber Mendonça,
—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
↩︎Kate Holterhoff, "The Generative AI Policy Landscape in Open Source,"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. Companionvisualization site.↩︎CHAOSS AI Alignment Working Group,
"Awesome LLM Policy,"live PR-editable catalog with a nine-part taxonomy—includingdiscussionthreads andincident evidenceas first-class categories alongside finished policy artifacts.↩︎The adjacent body of work is about as short as the list of trackers. Sviatoslav Sydorenko's
EuroPython 2026 reference gistcollects 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.↩︎James Fredley,
"Assisted-by: How open source projects are drawing the line on AI contributions,"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 thatAssisted-by:
is settling in as the de facto convention overCo-authored-by:
, which "implies legal personhood." Fredley is chair of the Apache Grails PMC.↩︎Sean McLellan,
"Assisted-by git trailer: provenance for AI-assisted commits,"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' (commenton issue#9347)—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.↩︎The term has a longer life outside software. H. L. A. Hart,
"The Ascription of Responsibility and Rights,"Proceedings of the Aristotelian Society, New Series49 (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,"Cognitive Science11, no. 4 (1987): 481–518, formalizes the everyday version: how people reason with rough-and-ready rules that new information candefeat, and what it takes for an override to count.↩︎Ghostty,
(fetched 2026-08-03). Iterated in public via PRAI_POLICY.md
#8289(initial disclosure rules, August 2025) and PR#10412(hardened into the standalone policy, January 2026).↩︎