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 -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to