Elizafox

I figured it's time for me to make a clear, unambiguous stance on LLMs and “agentic AI.” I have been asked, so I want to make it clear.

My own personal opinion

I don't care about locally-run models, they can't really make production-level code anyway. I don't like the unethical business practises of OpenAI or Anthropic, though, and I don't like the “hyperscalers.” I don't think I need to say much about them, enough has already been said. I also saw first-hand working at Microsoft what AI is doing to the company (nothing good).

In light of all this, but being dissatisfied with a lot of “no AI” policies on grounds of vagueness, I have decided to take my own approach.

Policy on LLMs

It would be silly to say “no LLMs” because that's a vibe, not an actionable rule. It relies on people being honest, and not everyone is always honest about their usage. How do I enforce that? How can I tell? Does autocomplete in VSCode count or not? I generally don't like rules based on vibes, as I feel they can be abused. In my opinion, this could become a problem down the road, especially as projects scale beyond myself.

I have been in too many projects where subjective rules have been misused to force people out. Not to mention such a rule is entirely subjective, and opinions will differ wildly on what looks like LLM-generated code or not. Someone might also write code that just happens to look like Claude (plausible, given Claude has been trained off human code), and I don't want to discount this possibility.

If we don't want people coding based on vibes, we should also not make rules based on vibes.

Finally: I can't really stop someone who is determined enough to submit LLM code to my projects from doing so, if I can't distinguish it. There's little I can do about this.

In my view: there's a moral hazard in saying “no LLMs,” that could lead to more problems than it solves.

But there is a defense against slop. That is what I will aim to target.

You must be able to explain the contribution

I will now require contributors to be able to explain what their contribution does in detail, how it works, and the design decisions that went into it.

I don't want contributions where a contributor cannot explain how the contribution works, or who cannot defend it.

People who heavily rely on LLMs will find this requirement quite tedious, probably resorting to an LLM-generated description, which will be obvious immediately. Leading to my next rule...

No slop

I don't like slop. Whether it comes from a person or an LLM, a contribution ultimately reflects upon the human submitting it, even if they are using an LLM to automatically contribute (it reflects upon the operator of the LLM bot).

I have seen too much slop written by humans, so I mention that as well.

I demand quality in contributions. They must be readable, clear, as simple as possible (except where complexity is required), and must handle all obvious errors gracefully. I am not asking for bug-free submissions. Such a bar would be impossible to clear. What I am asking for is contributors to not make obvious mistakes and review what they write.

This rule also applies to all communications. Translation errors are excusable; however, outright slop in communications, including lazy reports and no-effort messages sent to maintainers, are not acceptable.

No automated PR's or issues

A human must review, submit, and sign off on all pull requests and issues. Descriptions and reports must be written by the human submitting them.

No agentic system may submit a contribution, issue, review, or other project communication on someone's behalf. All submissions must be deliberately initiated and controlled by the human submitting them.

All issues must include a commit hash tested as well as any affected versions, if relevant. If a tool was used to find the issue, the user must disclose that this was the case, and certify the issue affects supported versions.

Security issues for obsolete or unsupported versions will be summarily deleted without comment.

Rights to the contribution

Contributors must have the right to submit all material included in their contribution. Work originating from another person or project must be appropriately authorised, licensed, and attributed.

Steps to reproduce are required

I will now also require steps to reproduce. In the case of an exploit, minimal code to trigger the exploit is required.

Issues that do not include sufficient steps to reproduce the problem on either the main branch or the latest relevant supported release will be closed without comment.

For intermittent or nondeterministic issues (“heisenbugs”), provide sufficient information to reproduce the conditions under which the problem occurs.

Attestation

By submitting anything to my projects, you agree to the following attestation:

I personally reviewed this submission, understand its contents, and can explain and defend its technical and design decisions. The description and project communications associated with this submission were written by me, not autonomously generated or submitted by an agent.

Conclusion

I can't solve slop or stop Anthropic or OpenAI from existing. I can't make people determined to bend the rules behave. All I can do is try to raise the bar high enough where the lazy will hit their heads on it, but legitimate contributors will have no problem clearing it.

I hope with these rules, I have not imposed any undue burden to any legitimate contributor. I've aimed to strike a balance here. I want to make human contributors feel welcome, but freeze out automated slop contributions.