A compact for responsible use of AI tools

1

GHC Wiki has a sane policy on AI use: AI · Wiki · Glasgow Haskell Compiler / GHC · GitLab

There are 2 key points for me:

  • Contributors should only put forth contributions that they could have created without the support of AI tooling.

  • When large parts of a piece of code have been primarily AI generated it’s highly encouraged to explicitly label it as such in the source code.

In my projects and contributions I strive to uphold both.

That will cost me tempo and reputation. I will have less of my goals achieved and still be subject to potential penalties and drama.

Despite the mounting pressure,

  1. I refuse to join the “zero tolerance” / “no AI” camp.
  2. I will not contribute AI code that doesn’t match my capabilities and taste.
  3. I will not “go dark” and remove attribution marks from my commits or otherwise.
  4. I will label my repos according to the amount of “unsupervised AI effort” that went into them.

There is a range of effort from “I love artisanally crafting Haskell AST by pressing keys on my mechanical keyboard” to “I’m here only for the end result, if AI is able to do it, let it”. Both ends are luxury positions.

I like writing Haskell by hand, with all the formatting and type-setting. Unfortunately I don’t have enough spare time for this.

Without going into further details, my use of AI is not unlike “medical assistive devices”. When someone objects to AI use, this feels like someone objects to use of cochlear implants. Which is an attack on autonomy. “Studies show…” ends up with, or implies, “…therefore we don’t trust anyone (and, by extension, you) with using this tech”. Any policy that’s using such framework is bad and its authors should feel bad.

Since the advent of recent, more capable models, I have been unblocked on quite a few projects because AIs went in and found the issues (for a pretty penny). I’d say I’ve been unblocked too much and now have many projects stuck in “make it right” limbo.

I don’t contribute code I don’t “own” even if it seems working, passing tests, gets good grades from other AIs. I’m still the bottleneck.

Reviewing AI changes is way less pleasant than figuring it all out by yourself. Most of the time I don’t have this luxury and there’s no one else to delegate. But I still want my goals to be achieved, so I pinch my nose at all the code smells and let Claude Code do its thing in the background, only course-correcting it with a remote supervision.

Between not achieving my goals at all and achieving them by mopping up after AI, I choose the later. And this is not the choice I will tolerate to be forced on me.

In return, I commit to honesty and openness.

And then there are projects that are private, too inconsequential, or just to see LLMs squirm. I will tag them vibecoded to prevent anyone from getting silly ideas from those codebases. And that “anyone” includes AIs or their training sets. Label, label your projects and commits to give them a chance at avoiding getting high on their own supply.

I have a certain feeling of doom that Haskell’s “language immortality” status may be revoked as the senior and experienced maintainers switch to the greener, rustier pastures. A properly trained AIs of the near future can then lend us a chance of surviving the community crunch by carrying some of the maintenance burden. Publish, publish your projects, and let the AIs train on them.

13 Likes
2

I think the GHC policy is reasonable for a project of that size.

For the GHCup project I have decided to not accept LLM generated code/commits. It’s not for me to decide how people work and they may very well use LLMs to navigate the codebase, experiment and do whatever else. But to me, accepting LLM generated commits means:

  • I have to invest more time in reviews
    • I trust LLM generated code less than human written code and there’s increasing evidence that this is a healthy stance
  • the project’s developer experience is sub-par
    • If people resort to using LLMs to contribute to such a small (well, fairly) project, then I feel I have failed somewhere and need better design, better documentation, better CI
    • e.g. I use LLMs extensively for creating example jq expressions and then “reverse engineer” them… jq’s interface/language is so awful that the english-language interface of LLM prompts and verifying output is less stressful… but when actually coding, I have the opposite experience
  • as a project with a high risk of supply chain attacks (like all distros) it’s irresponsible to accept LLM generated code
    • although of course I can review everything in detail, it’s also a signal to my end users that my quality requirements are high (e.g. I found out that the mail server I’m using had claude-generated commits in the recent history… and it worries me)
  • the copyright situation around LLM generated code is very nebulous. It seems most projects simply don’t care about that problem, but I do

These are all specific points. And I don’t care if anyone else adopts them. I just want to make clear this is not an emotional stance, but has very specific reasons. I still welcome contributions, I still use LLMs myself (but probably quite differently from others) and I don’t have any intention to create social witch-hunts of vibe-coded projects. Anyone is free to do whatever they want. I have my own reasons.

13 Likes
3

I must say that I find this an absurd appeal to pity. Could deaf people hear if they simply spent some more time listening? Should AI subscriptions be covered by health insurance?

Perhaps a better analogy would be a car, but I still think AI has more negative impacts and a smaller positive impact on the world.

9 Likes
4

How about partially deaf? Yes, they may hear something under ideal conditions, which happen about never.

They are already covered by free tiers, subsidized use, and enterprise offerings.

Perhaps. And, yes, assisted mobility can be covered by health insurance.

1 Like