AI policy

• March 9, 2026
• Collective „Neutral Language Council”, @andrea

Motivation

There’s no denying that AI is drastically reshaping how our society does… well, a lot of things. Most recently, the rise of coding agents is driving a massive transition in how software is being developed.

And we’re terrified of many aspects of this transformation. Tech giants are wasting massive amounts of electricity and water, disrupting ecosystems and communities. They’re exploiting vulnerable people for labour required to manually train their models. They’re wasting unimaginable wealth, which was stolen surplus value in the first place, on technologies that are used for misinformation, warfare, further consolidation of economic and political power, and consolidation of the means of production. Generative AI models are prone to hallucinations and often produce code that’s overengineered, overcomplicated, inefficient, unmaintainable, insecure and inconsistent. The list of complaints can be long, but let’s try to keep this document short.

At the same time, those new tools that we’ve been handed are genuinely impressive and can be very useful. LLMs are really good at processing huge amounts of data, finding patterns and applying them to repetitive tasks. Entire categories of workflows can be sped up by large factors, if only an agentic tool is applied to them correctly. For example, we’ve seen first-hand how much technical debt can be repaid with this boost. Addressing technical debt is difficult to get prioritised even in huge companies with VC funding and full-time employees – and it’s even harder in a project created by volunteers after hours for the sake of activism and mission. We can accomplish a lot, if we use the right tools the right way. So it wouldn’t be the smartest decision to just pretend like those impressive new tools don’t exist or that they’re pure evil.

That’s why we’d like to attempt to find balance between reaping the benefits of this innovation, and our moral concerns. We’d like to stay in the loop, monitor the developments in the industry, and hopefully (as much as a small collective can, compared to the tech giants) nudge those developments in the right direction. We’d like to be transparent about how we try to navigate those dilemmas.

Just like there’s no ethical consumption under capitalism, there can’t be ethical use of generative AI. In this crazy, complex world, we’re forced to choose our battles.

Goals

What’s the point of writing down this AI policy?

• Clarity for contributors. We don’t want the (current or potential) contributors to be confused about what tools they’re allowed to use, or what do we consider best practices in this brand new way of developing software. We also don’t want to get spammed by pull requests full of AI slop, even if they’re being submitted with the purest of intentions. We want to make it simple: here’s what we believe, and if you’re onboard, you’re welcome to be a part of our efforts.
• Transparency for users. Nobody wants to listen to AI-generated music or see sloppy “art”. It’s not fair to people to feed them AI slop content, and it’s even less fair to feed them slop while not even labelling it as such. We’ve all been on social media, we know how bad it can get. That’s why we believe it’s important to reassure people who are using Pronouns.page that both the content they see, and the code and infrastructure that deliver it, are going to remain high quality, safe, secure, and created primarily by humans, for humans.
• Inspiration for other projects and companies. It’s really distressing how many things that we’ve been paying for and expecting good quality in return for our money or data, can now be full of hidden slop that was automatically generated by a stochastic machine with no regard for things like safety or human well-being. The tech industry seems to have collectively agreed that, for example, it’s okay to release software that’s full of known security vulnerabilities, simply because of… how little effort it took to create. If you’re creating something for people to use, and especially if you’re selling it, you owe them a disclosure of how that thing was created and what level of quality they can expect. With this AI policy we’re hoping to set a more general expectation that other projects, especially commercial products, will have to be transparent about their AI use, or risk losing customers.

Values

• Human-centric approach. This project is made by humans, for humans. AI should be regarded as just one of the tools in our toolbox.
• Authenticity. This website highlights neogrammar as it’s used by actual speakers in their daily lives – it’s not something that LLMs would even have enough training data on. We’re a living community – not a random string generator.
• Maintainability. Writing code is easy, especially for an LLM. The hard part is making sure that whatever changes you might need to make to your code a year from now don’t become a logistical nightmare.
• Complete mental model. We don’t want a codebase that no one actually understands. Cognitive debt is a danger hiding in the shadows of LLMs.
• Privacy, safety and security. If we don’t care about getting those aspects right, why even bother creating this project?
• Sustainable pace. AI makes a lot of things way faster – but we see value in actually slowing down and reassessing whether we do the right thing and in the right way.
• Simplicity. Principles like KISS, DRY or YAGNI have been great pieces of advice for developers for decades – and in the times when implementing ideas is cheap, they’re even better advice now.

Policies

No useless AI features

No, we don’t need a chat bot. No, nobody wants a ✨ button to fill out their profile for them. We’re not a big tech company that needs to artificially build up the AI hype so that their stocks go up. We’re not a startup that hopes to build a silly wrapper over the ChatGPT API and rake in billions in VC money. We’re activists building a project that the nonbinary community can actually use and where our allies can get educated.

Whenever a good use case for a user-facing AI-powered feature demonstrates itself, we’ll evaluate it closely – and if we determine that its value outweighs the costs and risks, we might implement it. But we’re definitely not going to shove AI in our users’ faces.

Human-created content (blog posts, translations, etc.)

All that you see on our website has been created primarily by humans. No one prompted a chat bot with “write me a blog post about what it’s like to be nonbinary” and then published it pretending as if there’s any valuable perspective in “their” post.

What contributors may use AI for are things like spellchecking, proofreading, formatting, preliminary research, brainstorming ideas, etc. Basically, if it’s something for which in the past you’d use a tool for (eg. thesaurus), a friend (eg. brainstorm, feedback), or professional services (eg. proofreader), then it’s generally okay to use AI for making your text better; but if you’re hiring a clanker ghost-writer to write a post for you, then better go publish it elsewhere (our recommendation is /dev/null).

When translating stuff, keep in mind that the kind of content we create here is not something that LLMs would be good at – they have neither enough training data on neogrammar, nor the authentic lived experience of the queer community. While you might automate translation of things like a “Set up multi-factor authentication” button (as long as you properly review it), things change whenever a human, queer context is needed (say, entries in the Terminology Dictionary, or FAQ explaining our daily struggles). Remember that localisation is more than just translation – your local perspective is more valuable than anything a machine translation can ever provide.

No AI in moderation or user support

Our moderation system is automatically flagging suspicious content using regular expressions and keywords, as well as relying on human users reporting accounts. This is covering our needs perfectly fine – although we’re of course open to implementing something more sophisticated, if need arises. But there is absolutely no reason to feed our database to a third-party LLM, and we will never do that.

Moderation decisions are made by humans, with more than one moderator required to ban an account. A machine can never be held accountable, so it should never make important decisions. Our moderation remains human-centric.

No one wants to talk to a bot when they contact user support – so even though it leaves us with more work (and not of the exciting kind), and even though it means you might get a reply within a week or so rather than within seconds, we will not outsource user support to machines.

Respect privacy, care about security

We collect as little personal data as possible to provide our services, so by design we don’t really have to worry about an LLM accidentally getting unauthorised access to sensitive data – but you still have to be wary of any ways an LLM might get access to our production database, logs, env vars, etc. Research best practices and follow them.

Do not install any agentic software on the project servers!

{ 
    "permissions": {
        "deny": [
            "Read(.env*)",
            "Edit(.env*)",
            "Read(*.sqlite)",
            "Edit(*.sqlite)"
        ]
    }
}

Mindful choice of models

We don’t impose any concrete restrictions on which foundation models, chatbots or agentic tools our contributors are allowed to use. However, we ask them to be mindful of the tradeoffs involved. There is no perfect AI provider or model. As users, we need to weigh quality, speed, availability and cost on one hand, and moral considerations on another.

We urge our contributors to, whenever possible, chose for lower environmental impact, open and unbiased training data, high model factuality and honesty, as well as at least partial alignment with organisations and governments involved in the model’s creation on issues like anti-imperialism and anti-capitalism. A useful resource could be a research report by Gemeente Amsterdam in which they compare various models by some of those criteria.

Prefer specialist models over general models. For example, when working on Nuxt code, Nuxt’s chat bot will give you better results than ChatGPT, as it’s more likely to say “no, you can’t do that” instead of making something up, and will give you links to GitHub issues and documentation sites specific to the framework. Similarly, DeepL will be more fit for translations than a general model.

Be skeptical. Be cautious. No “vibe coding”.

In a way, generative AI is magic. Treat it accordingly. No genie makes wishes come true without any strings attached.

Always – but especially when it comes to safety, security and personal data – be critical of what a magical black box tells you. Verify claims you put in blog posts. Review the code that autocomplete suggests. Don’t let a neural network think for you.

We’d like to introduce a distinction between “agentic coding” and “vibe coding”. One is using coding agents as tools that speed up specific parts of software development – the other is trusting that simply giving the computer instructions in natural language, without validating or understanding the generated code, will result in production-ready code. Vibe coding might be good for quick prototypes or playing around and learning – but it’s not an acceptable approach for any serious project.

Prefer sources over bot chats, prefer bot chats over agents

More often than not, it’s way faster to just ask a chat bot whether technical question you might have, than digging through the library documentation or responses on StackOverflow. But it also happens all the time that an LLM gives you a completely wrong answer because it got trained on outdated version of a library, or just blatantly hallucinates a method argument that doesn’t exist, or neglects to mention a simple solution from the first result on Google and instead guides you through a complicated fix that doesn’t end up actually addressing the issue.

It’s tempting to use one convenient tool for everything. But it’s also very important to learn when to use it, and when to revert to the old, proven ways. Sometimes putting two keywords into a search engine and reading the summary of the first result might help you not just more accurately, but also more quickly than having to “engineer” a prompt and wait for a random string generator to waste a lot of water to give you personalised, verbose instructions.

We need to be honest here: we can’t really give any simple advice on when to use which kind of tool. Recognising what tool is best for what purpose in each particular use case is something that comes with experience – and also something that will probably change between when we write it and when you read it.

But in general, we’d recommend building up from the basics, not the other way around. Especially if you want to learn anything, and not just type wishes into a magic black box. Documentation, books, message boards etc. are always your friend. If you need more complex reasoning or a performance boost, an LLM chat will likely be very helpful – but be mindful of caveats. And if you need a machine to do things for you, and not just tell you things, look into coding agents – but again, be skeptical of the output it produces and data it has access to.

Short iteration cycles

Don’t ask a coding agent to just “generate this complex feature” for you. In our experience, the quality of its output drops disproportionately as the complexity of the codebase and feature increases. At the same time, the less effort you put into actually working with the code, the less you end up understanding what it’s actually doing.

Instead of treating AI as some kind of magical, infallible programmer that can do anything (it can’t), treat it as a junior developer with a narrow focus, but a huge talent to complete boring, repetitive tasks very fast. Or as a senior developer you can brainstorm ideas with, but ultimately going with your own judgment and experience.

Nobody likes being asked to review a massive pull request with thousands of line changes. It’s a good practice to split larger features into multiple PRs, so that the reviewer can wrap their head around each of them separately, see the dependencies more clearly, and catch issues more easily thanks to reduced mental overhead. If that’s what works for code written by humans, there are even more reasons to apply that same policy to code generated by machines.

If you decide to use coding agents in your work, make sure that you’re the one actually understanding the task, planning and reviewing the work done. Ask the agent one thing at the time, review and understand its output, revise the prompts as needed, and commit often – whenever the code is in an acceptable state. Use Git and diff tools to see the incremental changes made since the last commit. And when the entire feature is finished, push and create the PR.

Code review and testing

We’ve always been doing code reviews and testing major change on a separate staging server before they reach production environment. But those processes also slow things down and require significant effort, so considering the type of the project and the size of our team, we don’t require a review for every single commit – it would be an overkill for things like making a button bigger or adding a new Markdown file to the blog directory. Instead, we’re using our judgement to request a review from team mates whenever our changes carry potential risk or could benefit from an exchange of ideas. And of course, any changes proposed by external contributors have to go through a pull request process.

That’s no different for commits that involved AI in a smaller or larger capacity. If you’re a trusted contributor submitting a minor, low-risk change that you’d reviewed and tested yourself, then a formal code review is a luxury that we probably can’t afford, as nice as it might be to get every line of code meticulously reviewed. But if there’s any reason for your changes to need a second or third pair of eyes, err on the side of caution.

The bar is automatically high for any code that touches authentication, authorisation, security, or sensitive data.

Code is a liability. Mental model is an asset.

Just because an AI can quickly generate a lot of text or many pretty images, doesn’t mean anyone wants to read and look at any of it; doesn’t mean there’s any value in the slop it created. In the same way: yes, AI models can generate thousands of lines of code in a blink of an eye – but that doesn’t mean it’s a good idea to include all those lines in the codebase.

Great programmers treat code as liability. Someone will have to maintain that code for the foreseeable future. The less of it (while still accomplishing the goals) the better. Simpler systems are easier to understand, reason about and maintain; less prone to bugs and vulnerabilities.

What actually matters is the mental model of the system – something that can only be created in our heads when we actually work on the system ourselves.

It’s crucial that you understand the code you commit and that you keep our codebase understandable by other humans. Remember that you’re still responsible for the code you commit – whether you typed it by hand or “just” approved Copilot’s suggestion.

Don't turn AI into a dependency

We don't intend to become dependent on any particular provider, nor on generative AI in general. If they have an outage (which already happens way more often than would be acceptable of any serious business in the past) or decide to drastically hike the prices (which will have to happen at some point, if any of them is to become profitable), our website will not go down, nor will we be held hostage.

Do not integrate AI into any critical workflows. Again, it's just a tool. If your power drill breaks down, you can always just fall back to using a screwdriver. But if for some asinine reason your front door cannot be opened without your power drill working fine, then you're definitely doing something wrong.

Enjoy the learning opportunities

The tech industry is facing a crisis of its own making: they’re not hiring junior developers anymore, hoping to replace them with AI, only to realise in a few years that… this is where seniors come from.

They make it harder for juniors to gain valuable experience… Contributing to open source, while not a great way to pay your bills, remains a great way to learn while also, hopefully, making the world a better place. If you’re up for, that’s amazing! But please, please, don’t waste that opportunity on delegating all the learning to a bot!

Automate boring tasks. Enjoy the fun ones.

Contributing to open source projects is definitely hard labour – but it’s not a “job”. There are no KPIs to reach, no mandatory meetings to attent, no bosses nagging you about deadlines. You get to chose what’s important to you. Choose wisely.

Don’t let AI suck the fun out of programming. Don’t jump on the bandwagon that’s heading straight to burnout. Delegate the boring stuff to the machine, while you enjoy developing your passion and helping your community.

Future re-evaluation

This policy is indented as a living document – reflecting the rapidly changing world. We’re hoping to keep it updated with new findings and revised opinions.