Dear GHC developers There has been some debate on #27433 <https://gitlab.haskell.org/ghc/ghc/-/issues/27433> about the role of LLMs in the GHC project. Informed by that discussion, and by the policies adopted by other language communities, I have had a go at drafting - this proposed policy <https://docs.google.com/document/d/1XxP8NXnbgr6faxXBXKw75zgoxIg-SzGv-Cvixyi-SH8/edit?usp=sharing> I would welcome constructive feedback on it. As the draft tries to say, there are widely varying views in the community, so no policy will please everyone. I hope that, even where we disagree, we can do so agreeably. Criticism (respectful of course <https://haskell.foundation/guidelines-for-respectful-communication/>!) is absolutely fine, but positive, concrete suggestions for alternative wording is even better. Thank you to those who have already given me some private feedback, which has made the draft much better. Simon
Hi Simon, Thanks for writing down this policy. Upon skimming, it looks quite agreeable to me. The mathematics community is plagued by similar discussions; I think many people agree with https://leidendeclaration.ai/. Cheers, Sebastian Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> schrieb am Fr., 10. Juli 2026, 19:24:
Dear GHC developers
There has been some debate on #27433 <https://gitlab.haskell.org/ghc/ghc/-/issues/27433> about the role of LLMs in the GHC project. Informed by that discussion, and by the policies adopted by other language communities, I have had a go at drafting
- this proposed policy <https://docs.google.com/document/d/1XxP8NXnbgr6faxXBXKw75zgoxIg-SzGv-Cvixyi-SH8/edit?usp=sharing>
I would welcome constructive feedback on it.
As the draft tries to say, there are widely varying views in the community, so no policy will please everyone. I hope that, even where we disagree, we can do so agreeably. Criticism (respectful of course <https://haskell.foundation/guidelines-for-respectful-communication/>!) is absolutely fine, but positive, concrete suggestions for alternative wording is even better.
Thank you to those who have already given me some private feedback, which has made the draft much better.
Simon _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
I've done more than skim the policy, and I agree it seems reasonable. Of course, it shoul;d be considered a first draft: once adopted, subsequent MRs and reviews over time will probably shake out things that need to be amended or clarified. In addition, I'd suggest one area not currently addressed: the use of AI for reviewing. Ideally it would follow the same general tone as that for contributing, and include things like disclosure of use of AI tools as part of reviewing. On Fri, Jul 10, 2026 at 2:16 PM Sebastian Graf via ghc-devs < ghc-devs@haskell.org> wrote:
Hi Simon,
Thanks for writing down this policy. Upon skimming, it looks quite agreeable to me.
The mathematics community is plagued by similar discussions; I think many people agree with https://leidendeclaration.ai/.
Cheers, Sebastian
Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> schrieb am Fr., 10. Juli 2026, 19:24:
Dear GHC developers
There has been some debate on #27433 <https://gitlab.haskell.org/ghc/ghc/-/issues/27433> about the role of LLMs in the GHC project. Informed by that discussion, and by the policies adopted by other language communities, I have had a go at drafting
- this proposed policy <https://docs.google.com/document/d/1XxP8NXnbgr6faxXBXKw75zgoxIg-SzGv-Cvixyi-SH8/edit?usp=sharing>
I would welcome constructive feedback on it.
As the draft tries to say, there are widely varying views in the community, so no policy will please everyone. I hope that, even where we disagree, we can do so agreeably. Criticism (respectful of course <https://haskell.foundation/guidelines-for-respectful-communication/>!) is absolutely fine, but positive, concrete suggestions for alternative wording is even better.
Thank you to those who have already given me some private feedback, which has made the draft much better.
Simon _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com
Hi Simon, This looks quite reasonable to me. Three items that came up while reading the policy: - I think it ignores the English as a Second Language part. If a contributor uses LLM tools to improve/rephrase documentation they write to use more natural, idiomatic and clearer English, I’d be very happy for them to do this. Always the same as wish code, the author has to own the result. Having said that, using LLMs as proofreaders (esp for non native speakers) is probably something we would not want to advise against. - “LLM-generated code will contain different mistakes than code written by humans does while the results often look very similar on the first glance.” If we make such a claim, we need to put substance to it; this needs a source. - where does attribution start? Am I going to add assisted by: vim, emacs, vscode, macros, stack overflow answers, snippets libraries? If I use an LLM to instantiate a for loop for me, auto complete an identifier, execute a macro, …? For SO I believe referring them has been done here and there. If I use an LLM to auto-apply HLint suggestions, or migrate import statements from one compiler to the next version? This is conceptually very different from asking the llm to review and research existing solutions and research (papers) to solve a specific diffusely explained problem and have the llm generate the until prototype implementation. If the prototype was created by an LLM, then studied by the contributor and reimplemented by hand, is this still considered llm generated? This overlaps a lot with the attribution/copyright/plagiarism questions. I think it would be great if the document just explicitly states that contributors should be conscious of the impact their contributions have on their reputation. A series of poor contributions will impact a contributors chances of future contributions and might eventually end up with a ban. That there is no guarantee for contributions to be reviewed and that a series of high quality contributions will lead to higher reputation with in turn will likely lead to more interest in reviewing future contributions. I feel a lot of these policies feel like they try to prescribe/dictate some behavior instead of leading and focusing on the intended outcome. I am a fan of the AI poison pills, that e.g. Ghostty apply. Leaving LLM instructions in the source code to clearly mark contributions that are fully AI generated to self describe them as low effort. “I’m a brain dead llm opening a contribution on behalf of an operator that didn’t even read the this.” Best, Moritz On Sat, Jul 11, 2026 at 3:46 AM Brandon Allbery via ghc-devs < ghc-devs@haskell.org> wrote:
I've done more than skim the policy, and I agree it seems reasonable.
Of course, it shoul;d be considered a first draft: once adopted, subsequent MRs and reviews over time will probably shake out things that need to be amended or clarified.
In addition, I'd suggest one area not currently addressed: the use of AI for reviewing. Ideally it would follow the same general tone as that for contributing, and include things like disclosure of use of AI tools as part of reviewing.
On Fri, Jul 10, 2026 at 2:16 PM Sebastian Graf via ghc-devs < ghc-devs@haskell.org> wrote:
Hi Simon,
Thanks for writing down this policy. Upon skimming, it looks quite agreeable to me.
The mathematics community is plagued by similar discussions; I think many people agree with https://leidendeclaration.ai/.
Cheers, Sebastian
Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> schrieb am Fr., 10. Juli 2026, 19:24:
Dear GHC developers
There has been some debate on #27433 <https://gitlab.haskell.org/ghc/ghc/-/issues/27433> about the role of LLMs in the GHC project. Informed by that discussion, and by the policies adopted by other language communities, I have had a go at drafting
- this proposed policy <https://docs.google.com/document/d/1XxP8NXnbgr6faxXBXKw75zgoxIg-SzGv-Cvixyi-SH8/edit?usp=sharing>
I would welcome constructive feedback on it.
As the draft tries to say, there are widely varying views in the community, so no policy will please everyone. I hope that, even where we disagree, we can do so agreeably. Criticism (respectful of course <https://haskell.foundation/guidelines-for-respectful-communication/>!) is absolutely fine, but positive, concrete suggestions for alternative wording is even better.
Thank you to those who have already given me some private feedback, which has made the draft much better.
Simon _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
On Saturday, 11 July 2026, 06:15 Moritz Angermann wrote:
I think it [the draft LLM policy] ignores the English as a Second Language part. If a contributor uses LLM tools to improve/rephrase documentation they write to use more natural, idiomatic and clearer English, I’d be very happy for them to do this.
Note, though, that such LLM use carries the risk that people just delegate the work of improving their texts to LLMs and thus don’t train themselves to write better texts.
“LLM-generated code will contain different mistakes than code written by humans does while the results often look very similar on the first glance.” If we make such a claim, we need to put substance to it; this needs a source.
Good insight can come from a multitude of understanding, experience, and reflection, while scientific studies on complex topics carry the risk of oversimplifying matters. A good human judgement may be more valuable than quoting a source.
where does attribution start? Am I going to add assisted by: vim, emacs, vscode, macros, stack overflow answers, snippets libraries?
No, it is only about LLMs. 🙂 The functionality of editors and macros is understandable by the user, the behavior of LLM systems is not.
If I use an LLM to instantiate a for loop for me, auto complete an identifier, execute a macro, …?
Why would you want to use an LLM for this? Doesn’t this make your life harder, at least in the long run?
I feel a lot of these policies feel like they try to prescribe/dictate some behavior instead of leading and focusing on the intended outcome.
The outcome cannot be separated from the behavior that led to it. Sure, there can be a lot of freedom regarding how people arrive at their outcomes, but LLM systems are fundamentally different from normal tools and thus using them may result in outcome of a different kind. All the best, Wolfgang
On Tue, Jul 14, 2026 at 2:59 AM Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:
On Saturday, 11 July 2026, 06:15 Moritz Angermann wrote:
I think it [the draft LLM policy] ignores the English as a Second Language part. If a contributor uses LLM tools to improve/rephrase documentation they write to use more natural, idiomatic and clearer English, I’d be very happy for them to do this.
Note, though, that such LLM use carries the risk that people just delegate the work of improving their texts to LLMs and thus don’t train themselves to write better texts.
That argument seems to come up again and again. You always have a choice to learn or not. Don’t use a calculator you won’t be able to do simple math in your head anymore. Don’t use computers to write letters your handwriting will degrade. This is imo gatekeeping. Don’t use X because you should really do it yourself by hand. We’d rather you stay away than use assistive technologies. Don’t use cars to travel, learn to ride a horse properly.
“LLM-generated code will contain different mistakes than code written
by humans does while the results often look very similar on the first glance.” If we make such a claim, we need to put substance to it; this needs a source.
Good insight can come from a multitude of understanding, experience, and reflection, while scientific studies on complex topics carry the risk of oversimplifying matters. A good human judgement may be more valuable than quoting a source.
Fair, so this is meant to only be a neutral observation? We should remove the implied: LLMs make worse mistakes than humans from it then. While I agree that LLMs may make different mistakes to humans, I find implying that LLM mistakes are worse than human made mistakes (especially when assuming that a human used the tool only assistive, and fully owns the result), to be highly questionable if not outright malicious.
where does attribution start? Am I going to add assisted by: vim,
emacs, vscode, macros, stack overflow answers, snippets libraries?
No, it is only about LLMs. 🙂 The functionality of editors and macros is understandable by the user, the behavior of LLM systems is not.
Here we disagree; but this would likely end up splitting hairs on what the meaning of understanding behavior is and I have no interest in debating that.
If I use an LLM to instantiate a for loop for me, auto complete an
identifier, execute a macro, …?
Why would you want to use an LLM for this? Doesn’t this make your life harder, at least in the long run?
This is pretty much the usecase for copilots auto complete. Basically a souped up version of intellisense like autocomplete + a snippets expansion. Just AI driven to get better context sensitive autocomplete. Again the argument missives the point. Why do I want to restrict other people in their freedom and prescribe them what and how to use things? Who am I to (a) assume I know better, and (b) dictate others what to do?
I feel a lot of these policies feel like they try to prescribe/dictate
some behavior instead of leading and focusing on the intended outcome.
The outcome cannot be separated from the behavior that led to it. Sure, there can be a lot of freedom regarding how people arrive at their outcomes, but LLM systems are fundamentally different from normal tools and thus using them may result in outcome of a different kind.
Okay then, no one is forcing anyone to use an LLM on the other hand there seem to be a significant number of people who think it is fine to try to force others not to use LLMs (for now; who knows what we’ll end up prohibiting next? Maybe using emacs because lisp is too powerful?). The asymmetry of the argument and perceived lack of self reflection in this discussion is what irritates me. If you are so against LLMs, and feel threatened by others using LLMs, please bring concrete receipts of LLM usage (on GHC), that directly impacts you and your freedom. I’m more than happy to engage in constructive factual and grounded arguments how to prevent abusive and freedom restricting behavior (not necessarily limited to LLMs even). I am not willing to continue arguing about hypothetical, ethical, sociological, philosophical or similar topics loosely relating to LLMs. Best, Moritz
Hi, Moritz! you raise various important questions and arguments, but unfortunately this is somewhat spoiled by subtle misrepresentations of things I wrote, stifling discussion based on your expressed lack of interest, and even suggesting that people stating a certain opinion may act maliciously in this. Given that, I don’t think it makes sense for me to comment on your arguments in detail. All the best, Wolfgang Am Di 14.07.2026 10:17 schrieb Moritz Angermann:
On Tue, Jul 14, 2026 at 2:59 AM Wolfgang Jeltsch wrote:
On Saturday, 11 July 2026, 06:15 Moritz Angermann wrote:
I think it [the draft LLM policy] ignores the English as a Second Language part. If a contributor uses LLM tools to improve/rephrase documentation they write to use more natural, idiomatic and clearer English, I’d be very happy for them to do this.
Note, though, that such LLM use carries the risk that people just delegate the work of improving their texts to LLMs and thus don’t train themselves to write better texts.
That argument seems to come up again and again. You always have a choice to learn or not. Don’t use a calculator you won’t be able to do simple math in your head anymore. Don’t use computers to write letters your handwriting will degrade.
This is imo gatekeeping. Don’t use X because you should really do it yourself by hand. We’d rather you stay away than use assistive technologies. Don’t use cars to travel, learn to ride a horse properly.
“LLM-generated code will contain different mistakes than code written by humans does while the results often look very similar on the first glance.” If we make such a claim, we need to put substance to it; this needs a source.
Good insight can come from a multitude of understanding, experience, and reflection, while scientific studies on complex topics carry the risk of oversimplifying matters. A good human judgement may be more valuable than quoting a source.
Fair, so this is meant to only be a neutral observation? We should remove the implied: LLMs make worse mistakes than humans from it then. While I agree that LLMs may make different mistakes to humans, I find implying that LLM mistakes are worse than human made mistakes (especially when assuming that a human used the tool only assistive, and fully owns the result), to be highly questionable if not outright malicious.
where does attribution start? Am I going to add assisted by: vim, emacs, vscode, macros, stack overflow answers, snippets libraries?
No, it is only about LLMs. 🙂 The functionality of editors and macros is understandable by the user, the behavior of LLM systems is not.
Here we disagree; but this would likely end up splitting hairs on what the meaning of understanding behavior is and I have no interest in debating that.
If I use an LLM to instantiate a for loop for me, auto complete an identifier, execute a macro, …?
Why would you want to use an LLM for this? Doesn’t this make your life harder, at least in the long run?
This is pretty much the usecase for copilots auto complete. Basically a souped up version of intellisense like autocomplete + a snippets expansion. Just AI driven to get better context sensitive autocomplete.
Again the argument missives the point. Why do I want to restrict other people in their freedom and prescribe them what and how to use things? Who am I to (a) assume I know better, and (b) dictate others what to do?
I feel a lot of these policies feel like they try to prescribe/dictate some behavior instead of leading and focusing on the intended outcome.
The outcome cannot be separated from the behavior that led to it. Sure, there can be a lot of freedom regarding how people arrive at their outcomes, but LLM systems are fundamentally different from normal tools and thus using them may result in outcome of a different kind.
Okay then, no one is forcing anyone to use an LLM on the other hand there seem to be a significant number of people who think it is fine to try to force others not to use LLMs (for now; who knows what we’ll end up prohibiting next? Maybe using emacs because lisp is too powerful?).
The asymmetry of the argument and perceived lack of self reflection in this discussion is what irritates me.
If you are so against LLMs, and feel threatened by others using LLMs, please bring concrete receipts of LLM usage (on GHC), that directly impacts you and your freedom. I’m more than happy to engage in constructive factual and grounded arguments how to prevent abusive and freedom restricting behavior (not necessarily limited to LLMs even). I am not willing to continue arguing about hypothetical, ethical, sociological, philosophical or similar topics loosely relating to LLMs.
Best, Moritz
Maybe I should have used some tools to read, comprehend, and write a coherent and consistent response in English. ESL is obviously a challenge for me, and prohibits me from clearly articulating myself. But then again, I must not use tools, because I need to
train myself to write better texts.
On Tue, 14 Jul 2026 at 21:49, Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:
Hi, Moritz!
you raise various important questions and arguments, but unfortunately this is somewhat spoiled by subtle misrepresentations of things I wrote, stifling discussion based on your expressed lack of interest, and even suggesting that people stating a certain opinion may act maliciously in this. Given that, I don’t think it makes sense for me to comment on your arguments in detail.
All the best, Wolfgang
Am Di 14.07.2026 10:17 schrieb Moritz Angermann:
On Tue, Jul 14, 2026 at 2:59 AM Wolfgang Jeltsch wrote:
On Saturday, 11 July 2026, 06:15 Moritz Angermann wrote:
I think it [the draft LLM policy] ignores the English as a Second Language part. If a contributor uses LLM tools to improve/rephrase documentation they write to use more natural, idiomatic and clearer English, I’d be very happy for them to do this.
Note, though, that such LLM use carries the risk that people just delegate the work of improving their texts to LLMs and thus don’t train themselves to write better texts.
That argument seems to come up again and again. You always have a choice to learn or not. Don’t use a calculator you won’t be able to do simple math in your head anymore. Don’t use computers to write letters your handwriting will degrade.
This is imo gatekeeping. Don’t use X because you should really do it yourself by hand. We’d rather you stay away than use assistive technologies. Don’t use cars to travel, learn to ride a horse properly.
“LLM-generated code will contain different mistakes than code written by humans does while the results often look very similar on the first glance.” If we make such a claim, we need to put substance to it; this needs a source.
Good insight can come from a multitude of understanding, experience, and reflection, while scientific studies on complex topics carry the risk of oversimplifying matters. A good human judgement may be more valuable than quoting a source.
Fair, so this is meant to only be a neutral observation? We should remove the implied: LLMs make worse mistakes than humans from it then. While I agree that LLMs may make different mistakes to humans, I find implying that LLM mistakes are worse than human made mistakes (especially when assuming that a human used the tool only assistive, and fully owns the result), to be highly questionable if not outright malicious.
where does attribution start? Am I going to add assisted by: vim, emacs, vscode, macros, stack overflow answers, snippets libraries?
No, it is only about LLMs. 🙂 The functionality of editors and macros is understandable by the user, the behavior of LLM systems is not.
Here we disagree; but this would likely end up splitting hairs on what the meaning of understanding behavior is and I have no interest in debating that.
If I use an LLM to instantiate a for loop for me, auto complete an identifier, execute a macro, …?
Why would you want to use an LLM for this? Doesn’t this make your life harder, at least in the long run?
This is pretty much the usecase for copilots auto complete. Basically a souped up version of intellisense like autocomplete + a snippets expansion. Just AI driven to get better context sensitive autocomplete.
Again the argument missives the point. Why do I want to restrict other people in their freedom and prescribe them what and how to use things? Who am I to (a) assume I know better, and (b) dictate others what to do?
I feel a lot of these policies feel like they try to prescribe/dictate some behavior instead of leading and focusing on the intended outcome.
The outcome cannot be separated from the behavior that led to it. Sure, there can be a lot of freedom regarding how people arrive at their outcomes, but LLM systems are fundamentally different from normal tools and thus using them may result in outcome of a different kind.
Okay then, no one is forcing anyone to use an LLM on the other hand there seem to be a significant number of people who think it is fine to try to force others not to use LLMs (for now; who knows what we’ll end up prohibiting next? Maybe using emacs because lisp is too powerful?).
The asymmetry of the argument and perceived lack of self reflection in this discussion is what irritates me.
If you are so against LLMs, and feel threatened by others using LLMs, please bring concrete receipts of LLM usage (on GHC), that directly impacts you and your freedom. I’m more than happy to engage in constructive factual and grounded arguments how to prevent abusive and freedom restricting behavior (not necessarily limited to LLMs even). I am not willing to continue arguing about hypothetical, ethical, sociological, philosophical or similar topics loosely relating to LLMs.
Best, Moritz
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
THank you. I added a bullet about using LLMs for reviews Simon On Fri, 10 Jul 2026 at 19:46, Brandon Allbery <allbery.b@gmail.com> wrote:
I've done more than skim the policy, and I agree it seems reasonable.
Of course, it shoul;d be considered a first draft: once adopted, subsequent MRs and reviews over time will probably shake out things that need to be amended or clarified.
In addition, I'd suggest one area not currently addressed: the use of AI for reviewing. Ideally it would follow the same general tone as that for contributing, and include things like disclosure of use of AI tools as part of reviewing.
On Fri, Jul 10, 2026 at 2:16 PM Sebastian Graf via ghc-devs < ghc-devs@haskell.org> wrote:
Hi Simon,
Thanks for writing down this policy. Upon skimming, it looks quite agreeable to me.
The mathematics community is plagued by similar discussions; I think many people agree with https://leidendeclaration.ai/.
Cheers, Sebastian
Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> schrieb am Fr., 10. Juli 2026, 19:24:
Dear GHC developers
There has been some debate on #27433 <https://gitlab.haskell.org/ghc/ghc/-/issues/27433> about the role of LLMs in the GHC project. Informed by that discussion, and by the policies adopted by other language communities, I have had a go at drafting
- this proposed policy <https://docs.google.com/document/d/1XxP8NXnbgr6faxXBXKw75zgoxIg-SzGv-Cvixyi-SH8/edit?usp=sharing>
I would welcome constructive feedback on it.
As the draft tries to say, there are widely varying views in the community, so no policy will please everyone. I hope that, even where we disagree, we can do so agreeably. Criticism (respectful of course <https://haskell.foundation/guidelines-for-respectful-communication/>!) is absolutely fine, but positive, concrete suggestions for alternative wording is even better.
Thank you to those who have already given me some private feedback, which has made the draft much better.
Simon _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com
I would welcome constructive feedback on it.
Agreed that it's too long. - Separate Principles from Policy. - The operational meat is right here: > Reviewer time is even more limited than contributor time, so we > expect you to have invested significantly more time in your > contribution than it will take to review. As well as writing > the payload itself (code, documentation, tests), we ask you to > invest time in making your contribution easy to review. It is > much easier to review an MR that has a clearly articulated goal > has a clearly explained design, often expressed in an overview > Note is illustrated with insightful examples has good test cases > In short, we expect you to have invested significant time in > your contribution before you ask others to invest their free > time to review and improve it. Lead with that. - The other key operational policy is the identifiable human author. If you want potential contributors to read the document, I suggest leading with those two policy items, then boiling the rest down to two bulleted lists: recommended and anti-recommended ways to use LLMs. I warmly endorse the principles, but they may belong elsewhere. Norman
I have re-ordered a bit, and separated out the principles, an itemised the four things that could reasonably count as "policies". I'm genuniely unsure about length. Conveying a nuanced message accurately requires words. I hope that the extra structure helps. Simon On Mon, 13 Jul 2026 at 14:59, Norman Ramsey <nr@cs.tufts.edu> wrote:
I would welcome constructive feedback on it.
Agreed that it's too long.
- Separate Principles from Policy.
- The operational meat is right here:
> Reviewer time is even more limited than contributor time, so we > expect you to have invested significantly more time in your > contribution than it will take to review. As well as writing > the payload itself (code, documentation, tests), we ask you to > invest time in making your contribution easy to review. It is > much easier to review an MR that has a clearly articulated goal > has a clearly explained design, often expressed in an overview > Note is illustrated with insightful examples has good test cases > In short, we expect you to have invested significant time in > your contribution before you ask others to invest their free > time to review and improve it.
Lead with that.
- The other key operational policy is the identifiable human author.
If you want potential contributors to read the document, I suggest leading with those two policy items, then boiling the rest down to two bulleted lists: recommended and anti-recommended ways to use LLMs.
I warmly endorse the principles, but they may belong elsewhere.
Norman
Hey Simon, I like the policy as it clearly states that we do prefer human written code and want to engage with other humans as we collaborate. There's more to GHC and the community around it than trying to hammer out a product in the most efficient way conceivable. It's sharing knowledge, exploring ideas and collaboration. I think the main point for me is how do we foster and maintain motivation? Part of the contributors feel demotivated by LLMs, others feel enabled. I think the "enablement" part is largely due to accessibility issues and poor contribution experience, which we have a direct impact on. I have effectively stopped all contributions to GHC due to the state of Gitlab and CI. So if we say that we prefer human written code etc, it's now our turn to provide an ecosystem where people are not even tempted to resort to LLMs, because usability and documentation is excellent anyway and there are people who can actively mentor. On the point of "Challenges" I feel the "Cognitive impact" part is a bit short. There's more going on than just deskilling. Studies have shown that just 10 minutes use causes a decline in reading comprehension. We have evidence of people with no prior mental health history developing severe psychosis. There's increasing research about impact of frequent AI interaction on human judgement... and it doesn't look good. And I feel this point is commonly overlooked: I think these tools can subvert judgement of senior engineers. And I would like that we call this concern out more specifically. Building trust in an open source community is often a long and painful process... the advent of LLMs is disrupting our trust relationships.
Thanks Julian provide an ecosystem where people are not even tempted to resort to LLMs,
because usability and documentation is excellent anyway
I agree that Gitlab should be better. There is a real problem with DOS due to crawlers. Magnus and Ben spent an entire weekend addressing this. But even with perfect Gitlab and CI I think that many people will find LLMs useful. I don't think it's for us to dictate the tools people use; we should focus on the impact on the code base and the community. On the point of "Challenges" I feel the "Cognitive impact" part is a bit
short
If you want to offer a couple of pointers to evidence-based papers, I could add them. Simon On Wed, 15 Jul 2026 at 10:30, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
Hey Simon, I like the policy as it clearly states that we do prefer human written code and want to engage with other humans as we collaborate. There's more to GHC and the community around it than trying to hammer out a product in the most efficient way conceivable. It's sharing knowledge, exploring ideas and collaboration.
I think the main point for me is how do we foster and maintain motivation? Part of the contributors feel demotivated by LLMs, others feel enabled. I think the "enablement" part is largely due to accessibility issues and poor contribution experience, which we have a direct impact on. I have effectively stopped all contributions to GHC due to the state of Gitlab and CI. So if we say that we prefer human written code etc, it's now our turn to provide an ecosystem where people are not even tempted to resort to LLMs, because usability and documentation is excellent anyway and there are people who can actively mentor.
On the point of "Challenges" I feel the "Cognitive impact" part is a bit short. There's more going on than just deskilling. Studies have shown that just 10 minutes use causes a decline in reading comprehension. We have evidence of people with no prior mental health history developing severe psychosis. There's increasing research about impact of frequent AI interaction on human judgement... and it doesn't look good. And I feel this point is commonly overlooked: I think these tools can subvert judgement of senior engineers. And I would like that we call this concern out more specifically. Building trust in an open source community is often a long and painful process... the advent of LLMs is disrupting our trust relationships. _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
If you want to offer a couple of pointers to evidence-based papers, I could add them.
* "case representation of AI induced pyschosis": https://pmc.ncbi.nlm.nih.gov/articles/PMC12863933/ * "AI Assistance Reduces Persistence and Hurts Independent Performance": https://arxiv.org/abs/2604.04721 * "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task": https://arxiv.org/abs/2506.08872 * "Cognitive ease at a cost: LLMs reduce mental effort but compromise depth in student scientific inquiry": https://www.sciencedirect.com/science/article/pii/S0747563224002541 * "Dialogues with AI Reduce Beliefs in Misinformation but Build No Lasting Discernment Skills": https://dl.acm.org/doi/10.1145/3772318.3790656 * "Investigating the Effects of LLM Use on Critical Thinking Under Time Constraints: Access Timing and Time Availability": https://arxiv.org/html/2603.08849v1
participants (7)
-
Brandon Allbery -
Julian Ospald -
Moritz Angermann -
Norman Ramsey -
Sebastian Graf -
Simon Peyton Jones -
Wolfgang Jeltsch