Andreas, Assuming we actually need to have an explicit LLM policy, because people ask for it: I think the LLM policy should be "see general contribution policy (e.g. the text from the last email); PS: We strongly encourage clear attribution of LLM usage where applicable; this helps everyone to know what to look out for."
Aren't we all adults, can't we expect a basic level of common sense? Do we need to drown in legislation, policies, ...? PS: for the "were LLMs used during this creation?" I'd also suggest to have either a checkbox, or yes/no toggle on the MR creation page. Or maybe just in the MR creation template (so that it's not tied to some GitLab customization needs). Best, Moritz On Wed, 15 Jul 2026 at 18:57, Andreas Klebinger via ghc-devs < [email protected]> wrote: > > I think we could do with a much shorter policy, that doesn't even > mention LLMs/AI > > I agree that brevity and maybe simplicity could be improved. > > But being explicit about LLMs/AI is not unnecessary. People have been > asking, and will keep asking, what our policy in this respect is. > Pointing them to a document that doesn't acknowledge the thing they are > asking about in any way will not be as helpful. > > > What I'm trying to convey is that LLMs are not special in the ability to > produce poor code. > > The goal of attributing LLM involvement is not to mark a contribution as > bad. If I thought such MRs are categorically worse I would > argue for a blanket ban instead of being onboard with this policy. > > I do agree with what you put into your condensed version. But personally I > do want to see (mostly) LLM generated code to be marked > as such. And the topic of LLMs to be explicitly addressed so we can point > people at the policy instead of repeating the same discussion > over and over again. > > On 15/07/2026 12:01, Moritz Angermann via ghc-devs wrote: > > Andreas, > > I should probably not have dealt in extremes to try to make my point. > What I'm trying to convey is that LLMs are not special in the ability to > produce poor code. They _do_ lower the bar, but LLMs are fundamentally > orthogonal to the problem we face with them. As such I mostly question the > necessity for large parts of the policy. Especially as I question the > enforceability of the policy, and what value does a policy without teeth > have? > > From the interactions you had with me, you might know that I deeply value > simplicity over (unnecessary) complexity. And this policy as it grows to > me becomes increasingly complex. I think we could do with a much shorter > policy, that doesn't even mention LLMs/AI, ... and sets the general > expectations that would cover much more than just the challenges with LLMs. > > I've taken the part from the policy that I consider very valuable and > modified it slightly below. I would like us to set a frame that transcends > LLM and similar concerns, and focuses on the outcome we want, not on the > particulars. > > Best, > Moritz > > *Basic principles of GHC Development:* > > - > > We want to nurture the community of passionate volunteers who maintain > and develop GHC, their motivation, their relationships, and their > enjoyment. > - > > We want to build software that is the province of humans, where it is > understood and developed by a community of people. > - > > We want to build a code base that we can be proud of: well structured, > well documented, even beautiful. > > *Collaboration* > > - > > Human conversation. In offering a contribution to GHC you are > becoming a valued part of a community of living, breathing people. You are > offering your work for free, and members of the community are likewise > offering their work to you for free, to review and improve your MR, and to > help you to learn your way around the code base. > > They should treat you with respect, and you should treat them likewise. > You are expected to enter a direct conversation with a human reviewer, and > be able to fully motivate, explain and stand behind the contributions you > offer. They want to talk to you. > > - > > Supporting contributors. We aspire to nurture a mutually-supportive > community of human beings who contribute to GHC. GHC is a large code base, > which can be intimidating. Many GHC experts hang out on ghc-devs mailing > list, or the Matrix channel, and IRC, and are happy to help. Here's a > list of channels > <https://gitlab.haskell.org/ghc/ghc/-/wikis/mailing-lists-and-irc>. > - > > *No Right to Reviews*. Your contribution to GHC may not be > automatically reviewed. There is only a small pool of active reviewers, and > it is often best to reach out to people through the mailing list, irc, > matrix, ... and find reviewers this way. We very much look forward to > having you as a reviewer as well. Contributions that fail to enlist a > reviewer or sheperd may be closed as-is after a reasonable timeframe (e.g. > 3mo). *Always be sure that your MRs meet your own expectations on MRs > you'd like to review.* > - > > *Bad actors and poor quality contributions.* In the rare case where > contributions to GHC are of sloppy, and poor quality, we reserve the right > to ignore and eventually ban aspiring contributors. > > > > On Wed, 15 Jul 2026 at 15:44, Simon Peyton Jones < > [email protected]> wrote: > >> Thanks for your feedback Iavor. >> >> The only bit I have some reservations about is the bit that any LLM use >>> needs to be clearly indicated, as often the LLM use tends to be a bit >>> "blurry", and I generally tend to think of the code as something I did, >>> even if I happened to use an LLM for some bit. >> >> >> I have clarified that section (P4). I never intended to cover "any LLM >> use", so I have made that more explicit. I intended NOT to require >> declaration of use of LLMs to help you find your way around the code base, >> draw diagrams etc. Just declare if the material you are asking others to >> review was LLM-generated, even if (P2) you take full responsibility for >> every line. Doing so is not a weakness; it just provides context. >> >> I hope that may address your unease. >> >> Simon >> >> On Wed, 15 Jul 2026 at 09:26, Iavor Diatchki <[email protected]> >> wrote: >> >>> Hello, >>> >>> I like the document Simon has written because it established >>> expectations and it does so with nuance. I also might be in the minority, >>> but it doesn't seem overly long to me. I view such documents as guidelines, >>> rather than law, and as such I am not worried about it being "weaponized": >>> if we have disagreements we should still discuss them directly rather then >>> appealing to the document, as an arbiter if truth. >>> >>> Here are a few of my experiences with LLMs so far: >>> * I find them very useful for refactoring code >>> * For generating new code, I am still experimenting with the amount of >>> guidance to give the LLM. My impression is that I tend to be a lot more >>> controlling than other folks using them (I don't really try to "one shot" >>> things). I do this because I find it a lot easier to review the code as it >>> is being written, then doing it all at once after the fact. >>> * For complex features, I find working on a plan with an LLM to be >>> pretty handy: it's a bit like having a fancy rubber duck, to clarify my >>> thinking and try to think of all possibilities >>> * I've had some good luck with having the LLM find bugs in the code >>> * I also find them a pretty handy tool for getting familiar with a new >>> code base. I've used them to sketch architecture diagrams, pointing to >>> important modules, and it is pretty convenient to be able to ask questions >>> about where to look for things in the code >>> >>> On the more negative side: >>> * It is important to clearly scope your work, as LLMs make it easy to >>> make giant PRs, even if you do it a little bit at a time. I just did this >>> on a project (not on purpose!), and now we have a giant PR that I am the >>> only person who understands. I was too focused on implementing the >>> features, and not thinking of how it would be reviewed, which is a mistake >>> (in retrospect an obvious one) >>> * We've had issues with "drive by PRs" where a new contributor dumps a >>> bunch of code. Some of my colleagues try to review those, but I am inclined >>> to just delete them unless I can get some engagement from the contributor >>> and get a sense that they know what they did (which hasn't happened yet) >>> >>> >>> I think that most of my experiences are aligned with the proposed GHC >>> policy. The only bit I have some reservations about is the bit that any LLM >>> use needs to be clearly indicated, as often the LLM use tends to be a bit >>> "blurry", and I generally tend to think of the code as something I did, >>> even if I happened to use an LLM for some bit. Not so much opposed to this >>> I just wouldn't know what to label. >>> >>> More long term, I think as a community, it would be useful to focus on >>> getting more folks to be able to and comfortable to review code. >>> Traditionally, I think we've encouraged new contributors to implement some >>> small feature, and then have somebody experienced review their code. I >>> wonder if this might work the other way around too, where a new contributor >>> reviews a PR of an experienced contributor (perhaps in addition to another >>> review). >>> >>> Anyway, I hope this helps! >>> >>> Cheers, >>> Iavor >>> >>> >>> >>> >>> >>> On Wed, Jul 15, 2026, 8:01 AM Moritz Angermann via ghc-devs < >>> [email protected]> wrote: >>> >>>> After having another lively debate with Julian about this topic, and >>>> getting a general notion I'm not being well understood, let me share the >>>> following: >>>> Julians argument is mostly that he doesn't want to spend his time >>>> reviewing LLM generated code. I don't even disagree with the fundamentals >>>> here, but I think this can be easily extended, in that we don't want to >>>> review poor, sloppy, or similar code however one arrives at that (I've >>>> tried to make this point by using various approaches so far, but I feel >>>> this is not being understood) and is completely orthogonal to LLM use. I've >>>> tried to outline what my expected outcome of a LLM ban or similar >>>> policy would be and why I am so vehemently against a policy that tries to >>>> classify LLMs as something special. Maybe it's worth sharing here as well: >>>> >>>> LLM ban policy: >>>>> 1. a person who reads the policy and adheres to the policy -> Opens a >>>>> MR -> no one other than him can truly tell if it's a LLM free MR. >>>>> 2. a person who reads the policy and would adhere to the policy, but >>>>> isn't 100% sure he might not for a fraction of the MR end up using LLMs -> >>>>> won't open a MR. >>>>> 3. a person who doesn't read the policy -> Opens a MR -> no one other >>>>> than him can truly tell if it's a LLM free or not MR. >>>>> 4. a person who reads the policy, but still doesn't care and uses LLMs >>>>> -> Opens a MR -> will lie about using LLMs. >>>>> 5. person who reads the policy, but thinks they might get away with >>>>> LLM use -> Opens a MR -> maybe mentioned they use LLMs when pressed. >>>>> (1) is the MR you want. >>>>> (2) is maybe the person you'd be ok to still review the MR, because >>>>> they used an LLM to maybe help them translate some native language to >>>>> english. >>>>> (3) is the person you probably don't want, but can't tell from the >>>>> outside. >>>>> (4) is the person you probably don't want, but still can't tell from >>>>> the outside. >>>>> (5) is the person you probably don't want, and might find out later. >>>>> Person (3), and (4) probably don't care in the slightest even if told >>>>> they submitted LLM MRs. >>>>> Person (5) will feel ashamed if called out. >>>>> Reviewers still have to deal with (3), (4), (5). >>>>> And there will be people in group (3), and (4), who consider this a >>>>> challenge even. To use LLMs and see if they can fool the reviewers to not >>>>> notice. >>>> >>>> >>>> And I _really_ _really_ think we want people especially from group (1) >>>> and (2). >>>> >>>> I honestly think >>>> > code may be reviewed if you find a reviewer >>>> >>>> is enough to codify that it is on the submitter to find someone to >>>> review their code. I still don't know where this notion of every MR >>>> submitted must be reviewed comes from. And I think that's a >>>> self-sabotaging approach. >>>> >>>> Even extending it to: >>>> > if you submit a LLM PR, you should find a potential reviewer before >>>> doing so >>>> >>>> I find it questionable, because (as illustrated above) I feel it >>>> discourages contributions from the people we _do_ want contributions from, >>>> and encourages those whom we'd rather not have contributions for. It also >>>> starts segregating contributors into "pure" and "impure" people and creates >>>> a class system with an implied hierarchy. >>>> >>>> I think we could probably also coupled this with a policy that MRs that >>>> haven't been reviewed, or found a shepherd > 3mo will be auto-closed. Or >>>> some other deadline. It is always on the submitter to engage with the >>>> community to find someone to review their contributions. This is part of >>>> partaking in the community and collaborating with others. Throwing code >>>> over the wall and not engaging with the project is the core issue we seem >>>> to address? Or are we trying to address a more ideological (LLMs are >>>> fundamentally bad for humanity) issue? If so, please let's be clear about >>>> this and call this out that GHC as a project sees LLMs as fundamentally >>>> detrimental to humanity and as such enacts a policy to ban LLM >>>> contributions in any form whatsoever. >>>> >>>> Ultimately this is all about social credit. If someone asks me to >>>> review their code, I may do so if I know them personally, from IRC, maybe >>>> matrix, or discourse, reddit, or 𝕏, ... or I may not. Maybe someone whom I >>>> trust refers that MR to me for review. They are basically putting their >>>> own social credit with me on the line for someone else. If I end up >>>> feeling they made me review a sloppy, poorly written, and barely understood >>>> MR, I'll think twice the next time they ask me to review something. >>>> Similarly if I end up reviewing someone's MR and find it of exceptionally >>>> poor quality, I will likely hold it against them the next time I end up >>>> being asked to review their MR. The inverse of course works as well, if I >>>> review a MR of stellar quality, I'm more likely to be inclined to review >>>> another MR by the same person. This is the same concept as how we deal >>>> with this in other circles as well: academia, hiring, ... >>>> >>>> >>>> But then again, maybe this all isn't about the technical questions and >>>> collaboration on a technical project, but trying to use technical arguments >>>> to achieve a socio-economic change; all I'm asking then is that we are >>>> going to be absolutely frank about it. >>>> >>>> In the end I'll remain highly sceptical about any policy that states >>>> vague goals that can not be properly enforced (and proven), because at that >>>> point they become easily weaponized. >>>> >>>> Best, >>>> Moritz >>>> >>>> On Wed, 15 Jul 2026 at 06:08, Simon Peyton Jones via ghc-devs < >>>> [email protected]> wrote: >>>> >>>>> Thanks for taking the time to write, Simon. >>>>> >>>>> I have updated my draft >>>>> >>>>> - Under "A human conversation", mention that in human interactions >>>>> it's fine to include LLM quotes.. That said, and speaking for myself >>>>> at >>>>> least, if I'm conversing with a human, say Robert, I really do want it >>>>> to >>>>> be Robert not Claude. If written interaction is hard, I'd be happy to >>>>> hop >>>>> on a call with Robert, or communicate in some other way that allows us >>>>> to >>>>> communicate well. >>>>> - Under (P1) bring out your point about draft MRs. (I suggest >>>>> explicitly saying "Not ready for review" in the Description.) >>>>> - Under (P2) bring out your point about tickets having looser >>>>> criteria. I also added a para about asking for help. >>>>> >>>>> I intended the tenor of the document to be positive: working in >>>>> partnership with other members of the Haskell community, and developing a >>>>> code base of which we can be proud. About LLMs I know that not everyone >>>>> will agree, and I think we need to find a way to disagree agreeably, >>>>> without knee-jerk reactions of fear or anger, just with a recognition that >>>>> other, equally thoughtful, people may hold different views to ours. >>>>> >>>>> For this reason the policy deliberately neither says "LLM bad" nor >>>>> "LLM good", although I know that members of our community hold both views. >>>>> Rather it focuses on outcomes: the effect on reviewers, on our human >>>>> conversations, and on the code base. That may satisfy no one fully, but I >>>>> hope it may be at least acceptable to most. >>>>> >>>>> Instead of trying to discourage contributions that involve LLMs, I >>>>>> think this project should rather try to welcome creative use of LLMs for >>>>>> the benefit of this project and all Haskell users. >>>>> >>>>> >>>>> My intent was NOT to discourage contributions that *involve *LLMs. >>>>> The intent (for the reasons above) is to be neutral on "involvement". >>>>> The >>>>> draft does indeed express a strong preference that code and documentation >>>>> are written by you -- but it's only a strong preference. If you >>>>> forensically review and hone every line, that's fine: you are taking full >>>>> responsibility. What no one wants (I'm sure including you) is pages of >>>>> machine-generated code or documentation that no one understands. >>>>> >>>>> thanks again >>>>> >>>>> Simon >>>>> >>>>> On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Simon, >>>>>> >>>>>> here are my comments on the policy document: >>>>>> >>>>>> > In particular, you must not use AI-generated text in a direct >>>>>> conversation with a human reviewer. >>>>>> >>>>>> I think this is too restrictive. A contributor may easily reach the >>>>>> limits of their understanding during a code review, and I think it's ok >>>>>> to >>>>>> resort to using an LLM then. I think it's fair to require that they >>>>>> clearly >>>>>> mark the LLM-generated part of their response though. >>>>>> >>>>>> > P1: Write MRs that are easy to review >>>>>> >>>>>> I fully agree with this, and apologize that some of my MRs have not >>>>>> been easy to review! I do want to point out though that MRs marked as >>>>>> "Draft" should not be held to the same standards as a "ready" / non-draft >>>>>> MR. I frequently open draft MRs mainly to get the CI results. Sometimes I >>>>>> still get detailed reviews on these MRs, and then feel sorry that a >>>>>> reviewer wasted their time on this. >>>>>> >>>>>> > P2: Full responsibility >>>>>> >>>>>> > You must understand, and be able to explain, every line of code, >>>>>> and every sentence of documentation. Every line! >>>>>> >>>>>> I think that's a good goal, but even for MRs, maybe too strict a >>>>>> requirement. Where do you draw the line? Is the contributor expected to >>>>>> understand every (pre-existing) function they used? To what extent? >>>>>> Strictness and performance characteristics too? >>>>>> >>>>>> For bug reports, I think GHC should be more lenient, and instead >>>>>> require that LLM use is clearly signalled. >>>>>> >>>>>> > P3: Strong preference for human authorship >>>>>> >>>>>> > We strongly prefer human-written code >>>>>> >>>>>> I understand that it's "good exercise" to write code by hand. >>>>>> >>>>>> But I've always been pretty bad and extremely slow to write code. And >>>>>> now that recent models have become so good at producing code, I was >>>>>> relieved that I can now contribute without being so limited by my >>>>>> code-writing skills. I already realize that some core contributors have >>>>>> much disdain for LLM-generated code. If the GHC project decides to >>>>>> devalue >>>>>> contributions of LLM-generated code with this language, I think this will >>>>>> reduce my motivation to contribute. >>>>>> >>>>>> > Writing it yourself forces you to think about every line; and it >>>>>> imposes a cost on you if you write 1000 lines instead of 100. >>>>>> >>>>>> IMHO contributing to GHC is already quite onerous and "costly", >>>>>> especially for newcomers. Just think of the flaky CI system and recent >>>>>> GitLab performance. Instead of trying to impose additional costs on >>>>>> contributors, I think it would be better to try to reduce the cost of >>>>>> reviewing and maintenance! For example, I think GHC should try using LLMs >>>>>> for "first-line" code review. LLMs are already very capable at debugging. >>>>>> How about investing in fuzzing or better automated testing, so bugs are >>>>>> discovered before they make it into a release? >>>>>> >>>>>> > We strongly prefer human-written documentation. >>>>>> >>>>>> Documentation generated by recentish models like Claude Opus 4.8 has >>>>>> indeed been quite bad. Claude Fable 5 is already much better at this. >>>>>> >>>>>> I think the main incentive resulting from this policy is to include >>>>>> _less_ documentation in contributions. In a world where LLMs are very >>>>>> capable of making sense of large code bases, maybe that's not much of a >>>>>> drawback. >>>>>> >>>>>> --- >>>>>> >>>>>> Overall, I feel that much of the recent discussion about LLMs in GHC >>>>>> and Haskell has been driven by fear and anger. I think many Haskellers >>>>>> are >>>>>> very proud of their skill to produce high-quality code, and as LLMs get >>>>>> better and better at this, this skill is becoming "less special". >>>>>> >>>>>> Instead of trying to discourage contributions that involve LLMs, I >>>>>> think this project should rather try to welcome creative use of LLMs for >>>>>> the benefit of this project and all Haskell users. >>>>>> >>>>>> Sorry for the bad wording here and there. I did not use an LLM to >>>>>> write these comments, and it took me an embarrassingly long time. >>>>>> >>>>>> Cheers, >>>>>> Simon >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list -- [email protected] >>>>>> To unsubscribe send an email to [email protected] >>>>>> >>>>> _______________________________________________ >>>>> ghc-devs mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>> _______________________________________________ >>>> ghc-devs mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> > _______________________________________________ > ghc-devs mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > ghc-devs mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
