An ethical love-letter to distributed technology communities.
This essay is explicitly addressed to my fellow technologists: software developers, hobby coders, digital humanists, computer science theorists, and all the other members of this big family of people who do tech. That doesn’t mean that what I write here can’t be of interest to anyone else (I’ll be very flattered if it’s of interest to anybody, tbh!). But the argument I’ll make is based on the idea that you and I share a community.
I want to talk about our community, and why it’s important. I want to suggest that using LLMs to generate content to be included in technology projects, whether that’s code or text or images, or code reviews or proofreading, harms our shared community.
(When I refer to “LLMs” in this essay, I’m referring specifically to the large commercial models trained by companies like Anthropic. I’m not talking about small-scale models you might train yourself, and I’m not talking about other applications of machine learning. These are fascinating technologies, with some remarkable and life-enhancing applications. They are not the target of this essay.)
Numerous tech projects have declared a position against the use of LLMs by contributors, including popular applications such as GIMP and Inkscape, the Clojure and Zig languages, the Gentoo and NetBSD operating systems, the Creative Commons organization, the Linux Man Pages project, and many more. Stack Overflow moderators went on strike in 2023, largely in protest at the site’s reversal of its policy banning LLM-generated content, which moderators saw as a rejection of community consensus in favour of “business pivots”.
So rejecting LLM-authored contributions is not a fringe position for a technology project to take. For some, the position is largely ethical. For others, it’s as much “an economic question about who pays for open source sustainability” (byteiota, 2026). LLM-generated contributions can be made at massive scale, and often contain errors and problems that are hard for humans to notice and fix. Allowing contributors to use LLMs to generate their contributions may cause significant additional work for volunteer maintainers, even as it makes the job of contributors easier. (Of course, LLM use can persuade people that they are being made more productive, even as their productivity actually falls (Becker, 2025), so it is possible that absolutely nobody’s job is being made easier.)
You’ll inevitably already have formed opinions about LLMs, and you’ll have had the opportunity to read what has been written about concerns relating to the environment, exploitation of underpaid workers, labour rights, security, privacy, copyright, and a host of other issues. I don’t think I’m going to influence your opinion by throwing every possible ethical issue with LLMs at you in the hope that one of them sticks. Instead, I want to approach LLMs from the perspective of the community we share, as people involved in technology. And I’d like to start by inviting you to think about how you came to be a technologist.
For me, I’m embarrassed to say, it was about a man. I taught at the same Oxford college as The Man. He was a computer scientist; I specialized in early medieval English literature. He was tall and clever and lovely, and we started dating. I had already dabbled a little in HTML (the gateway drug for so many of us who came of age in the Geocities era). I’d heard that there were ways of analysing language using computers, if you knew how to program. The Man promised to help me install Linux on my computer which, he said, was the First Big Step.
Then he dumped me.
I cried. A lot. When I stopped crying, I decided that I did not need The Man (or Any Man) to tell me any damn thing. I set up a dual-boot of Windows and Linux on my laptop. It was terrifying; I was sure I’d blow the machine up somehow, and I couldn’t afford to replace it. But, miraculously, it all went quite well. I picked up a guide to Perl, and before I knew it I was writing code to analyze Old English poetry using regular expressions.
Nowadays, I write mostly in Python, with some XSLT on the side. I don’t really think of myself as a software developer; I’m just a linguist who writes software. I know a lot of people like me, without formal computer science training, who picked up coding because we had stuff we wanted to do.
What’s missing from this description of my path to becoming a technologist?
It’s the community. Not people whose faces and names I knew, who sat next to me in lectures or who I could meet in Oxford’s severely overpriced coffee shops. It’s the distributed technology community of people, many known only by their online usernames. The people who would answer questions about programming in Perl from strangers on mailing lists or online bulletin boards. The people who volunteered their time writing detailed guides for new programmers. The people who developed code to make various tasks easier for Linux newbies who had only ever used Windows. The people whose Python questions on Stack Overflow pointed me towards useful answers by yet other people.
Without that community, there is precisely no chance that I could have become a technologist. The distributed technology community is an absolute marvel. It knows more than any individual could ever hope to know. It is generous in sharing knowledge. At its best, it is patient and encouraging and collaborative. It wants to invite you in and tell you everything it knows. Your biggest problem may be getting it to stop when your brain is full.
Online communities have a variety of well-documented problems, including gatekeeping and negativity in user interactions, which may encourage people to take their questions to LLMs. Communities like Stack Overflow, which are part of a commercial network, are also at risk from corporate priorities, which can conflict with community interests. But the answer to these problems is not to abandon technological knowledge communities altogether. The answer is building better communities focused on shared ethical principles, in which community members are required to treat each other with respect. This is difficult work. But we should do it.
Why should we do it? Well, I’m willing to bet that you, my fellow technologist, have benefitted from the distributed technology community on countless occasions. I’m willing to bet that you’ve contributed to it, as well. Maybe you think “No, all I ever do is ask questions”. But the questions are important, because without the questions, there wouldn’t be any answers. The questions help other people find answers more quickly. The questions contribute to the organization of knowledge within the distributed technology community. We should work to build better communities, because that is how we pay forward our debt to the communities that built us.
I want to pause here and ask you to think honestly about how important the distributed technology community has been to you. How much has that community offered to you in the past? How many opportunities has it given you to ask questions, to make connections, to engage in discussion about niche topics, to refine your opinions and improve your practice? I’d like you to weigh the significance of the distributed technology community in your technological life, and read what comes next with an awareness of that weight.
Knowledge is currently being reimagined as something acquired from machines. The number of humans discussing problems with each other on Stack Overflow has gone into a dramatic decline since the rise of LLMs (although not everyone agrees that LLMs were the major factor in this decline).
The use of LLMs threatens communities of knowledge creation, both online and off. The LLM industry “extracts knowledge as a one-time resource rather than sustaining its regeneration” (Greshnev, 2026). Not only are online resources being depleted as open communities full of reciprocal discussion are replaced by hidden individual interactions with chatbots, but there is also a drop in entry-level programming jobs, where new programmers would traditionally be able to develop their technical skills (Greshnev, 2026).
LLMs perform well enough on answering Stack Overflow questions in general, although their responses will often use deprecated libraries or provide code that does not actually fix the problem (Da Silva, 2025; Wang, 2025). A community of human experts therefore remains essential to provide support for more complex problems. Writing to explain their reasons for going on strike in 2023, Stack Exchange moderators asserted that “[c]ontent posted without innate domain understanding, but written in a ‘smart’ way, is dangerous to the integrity of the Stack Exchange network’s goal: To be a repository of high-quality question-and-answer content”. The moderators recognize that LLM-generated content is dangerous to the status of the technological knowledge commons, not because it is incapable of being correct, but because it has no human agency taking responsibility for its correctness. LLM-generated content is inappropriate for the knowledge commons because it is the product of mere textual patterns, not of knowledge.
Without doubt, all of Stack Overflow’s content was slurped up to train current LLMs. But where will the next generation of LLMs find content from experts discussing the latest technologies, up-to-date security practices, new algorithms and programming techniques? By asking LLMs to provide (often confidently incorrect) answers to their tech questions, developers are not only destabilizing professional communities of practice, but also neglecting to maintain the rich technological commons which has previously been built up from public discussions of questions and answers. At some point, if the trend of reliance on LLMs continues, there will no longer be a convenient knowledge commons that can be used as a source for training new LLMs (Greshnev, 2026). The distributed technology community will have been dismantled, and its replacement - never a particularly good replacement in any case - will degenerate in quality as its sources of useful training data dry up.
I’ve written previously about what I feel is our responsibility as technologists to build communities based on firm and explicit ethical principles. As I wrote in a previous essay, it isn’t possible to separate the professional from the political, or the technological from the ethical. When we try to do that, we end up with tech projects that discriminate against minoritized people, not because their creators particularly intended to discriminate, but because bias is endemic in every culture, and the community had no ethical guardrails requiring creators to check for that bias.
A key part of the work of building community is about openness, inclusivity, and accessibility. Diverse perspectives are crucial in the development of innovative ideas. Research suggests that valuable contributions to online knowledge communities come equally from participants whose viewpoints place them at the ideological centre of a community and from those whose viewpoints place them at the periphery (Safadi, 2021). Both the familiar and the novel have a valuable role to place in advancing community knowledge. Crucially, the more socially embedded those with peripheral ideologies are, the easier it is for their often innovative ideas to take hold (Safadi, 2021). Making sure that people with diverse viewpoints feel welcome in the community is not just an act of altruism, then; it’s also good for the community.
Tech communities are fairly notorious for lack of diversity and representation of certain minoritized groups. To my mind, it isn’t usually useful to think about this as a matter of individual fault, but rather as one of communal action or inaction. There is often a sense that, if a community is not actively excluding a group of people, it has done enough to be inclusive. Sadly, the reality is far less simple.
Imagine walking into a room for a meeting, dressed in jeans and a t-shirt, and finding that everyone there is dressed in tuxedos and ballgowns. What’s your instinctive reaction? Do you feel as though you’re in the right place? Do you feel welcome? Even if everyone is perfectly friendly and nobody mentions that you’re not dressed up, I’m willing to bet you’d feel a bit weird for that entire meeting.
This is rather how I feel as a woman walking into a meeting whose participants are all men. Perhaps my reaction wouldn’t be quite as dramatic - but that’s largely because women in tech are used to this situation by now. The men may all be absolutely lovely, and they may never make any overt sexist remarks, and even so, the woman may well keep feeling, at the back of her mind, that this meeting isn’t for people like her.
Using LLMs in tech projects reinforces the demographic imbalances of tech communities by encouraging the unthinking generation of content which is, by its nature, a statistical replication of all the biases and overt bigotry available on the internet. We know that LLM content replicates social biases such as misogyny and racism (e.g. Okerlund, 2022; Weidinger, 2021). It’s also fairly obvious that certain types of bias may be hard to recognize, particularly if you don’t belong to the marginalized group affected by the bias. Maybe you think these biases won’t come out if all you’re doing is generating some technical prose. But I wouldn’t bet on it. And I wouldn’t bet on your ability to recognize that bias when you review the LLM-generated text.
Perhaps you’re thinking, “Okay, maybe there’s a case here for avoiding LLMs for generating substantive content, like prose or code. But surely there’s no harm in using them to automate tasks like proofreading or copyediting?” And I can see why you’d think that. There’s not too much opportunity for bias (although I can imagine some scenarios...) when all the LLM is doing is highlighting errors, and these aren't the kinds of issues you'd otherwise discuss with the distributed tech community. Proofreading specifications and documentation with an LLM doesn't really represent a loss for the technological knowledge commons.
There is comparatively little research on the effectiveness of LLMs for tasks like proofreading and copyediting. The results of using an LLM to copyedit have not always been encouraging (Lingard, 2023). LLMs may create a fairly high signal-to-noise ratio, producing significantly more corrections than a human editor or a focused editing tool such as Grammarly, but with far fewer of those corrections actually being useful (August, 2026). LLM suggestions for editorial improvements to text have been characterized as lacking in useful detail, overlong, sometimes very inappropriate to the written context, and biased towards the norms of US English even when the text itself was not written in that variety (Otmar, 2024). LLM editors are good at sounding like they are giving feedback, but all they are doing is mimicking the linguistic behaviour of a human editor. They will find some errors because they are common types of error also found by editors in their training data. But they won’t necessarily notice the unexpected, and they will be prolific in noticing things that could be errors but actually aren’t.
Once again, these results highlight the transferred cost of using LLMs for tasks where accuracy is required, as a human is still needed to check the LLM’s (over-detailed and somewhat irrelevant) output, and to read through the text for errors or unclear writing which may have been missed by the LLM. If the human editor knows how to do the task - they are a confident user of the language in question and have experience in technical writing - they are perfectly qualified to proofread for themselves, and will likely find the LLM’s scattershot approach as much a hindrance as a help. If, on the other hand, the human editor is not a confident user of the language - perhaps they speak it as an additional language; perhaps they have a disability or condition affecting the use of language - they may not be entirely qualified to judge the LLM’s output.
My stated focus here is on community, though, and how tech communities are affected by using LLMs. The evidence suggesting that LLMs are not good choices for tasks such as proofreading and copyediting is interesting, but it must be secondary to the question of whether using LLMs in this way is good for the community. One particular problem springs to mind from this perspective: by using an LLM for this kind of task, you remove opportunities for human contribution and achievement in your project.
Communities are often structured around a core of people, with others distributed between the core and the periphery. The core in tech projects generally includes the people ’in charge’, whether that’s those who do most of the technical work, those who have an official governance role in the community, those who are senior in the community, those who have particular expertise, or some combination of these and other factors. The periphery includes people who are dipping a toe into the community, people who perhaps don’t feel entirely confident of their ability or right to contribute.
Research supports the assumption that people from underrepresented groups are likely to contribute less actively in professional settings, whether through self-censorship or as a result of (consciously or unconsciously) biased behaviour from other participants (e.g. Houtti, 2023; Tuggle, 2021; Farid, 2022). The likelihood is, therefore, that the periphery in a tech project may contain more underrepresented people than the core does. It’s fairly obvious, in addition, that people whose experience of the technology in question is limited - the newbies, the junior programmers, the hobbyists - will place themselves at the periphery.
Tasks that don’t necessarily require detailed technical knowledge, like proofreading documentation, can therefore provide perfect opportunities for community members at the periphery to contribute meaningfully to a project. This offers multiple benefits: to the project, to the individual, and to the community.
The project benefits from having its outputs reviewed by a member of its target audience. Review by a less-experienced user can be particularly valuable in the case of documentation and help pages.
The individual benefits by gaining a greater sense of belonging in the community, and (ideally) gains confidence for making future, perhaps more technical, contributions. They also gain deeper knowledge of the project, which is likely to support their technical development.
In turn, the community gains a member who is intimately familiar with some part of its documentation, which increases the general distribution of knowledge about the project. The community also benefits from modelling the potential for peripheral members to move closer to the core through making a variety of contributions. Other peripheral members may be encouraged by seeing the community’s welcoming and inclusive nature in action, while the core members may be reminded, even if only subconsciously, of the important role they play in creating a welcoming community.
Of course, on any specific occasion the community may struggle to find volunteers to take on these tasks. But if the community resorts to LLMs when this happens, this establishes the idea that these are not valued tasks, which makes them less attractive as ways for peripheral community members to begin contributing in the future.
If, instead, core members take on these tasks themselves when there are no other volunteers, they not only create a precedent that these are valued tasks, but also consolidate their own knowledge of the project’s content, and show by example that “housekeeping” tasks are as important as the core technical tasks in the project.
Research tells us that such “housekeeping” work tends to be gendered as “women’s work” in institutional contexts (Bird, 2004), and women in tech talk of their role as “glue”, doing tasks such as writing and maintaining documentation which are not recognized as having the same status as the core technical work (Burton, 2022). When core members of a project, particularly those from dominant demographics, start acting as “glue”, they set an example. Delegating the housekeeping to an LLM sets a very different example.
Why does the use of LLMs, in particular, constitute a line we should not cross? There are plenty of ethical problems in tech, particularly when we look at the monolithic corporations such as Apple and Meta. Why not also ban people using Apple hardware, or insist that we may not use Google’s products for any community business? We might do that, of course. But, for me, there are two major reasons to focus on LLMs, and both are related to our commitment to building strong, inclusive tech communities.
Firstly, LLMs are unnecessary. We have to hold our noses and use some kind of computer hardware, even though we know that all the corporations building that hardware are more or less ethically dubious, because having a computer is essential to our work. We all use some kinds of software, even though it can be difficult to find even open-source projects which have a particularly ethical approach to tech. It’s hard to imagine circumstances where using LLMs is similarly necessary.
You might argue that LLMs can be used to make content accessible to people with disabilities, or to help those whose primary language isn’t English. This kind of circumstance provides the strongest argument I have seen so far for the use of LLMs. If someone told me that they had used an LLM to help them access some aspect of a project, I would find it hard to fault them. But I would also want to know why the project wasn’t ensuring broad accessibility so that LLM use was unnecessary.
Authors writing in their second (or third, or fourth...) language should be able to ask for support from other community members when creating content for inclusion in the project. If that support is not available, then the community is, again, failing to ensure equal access to all its members.
It should never be absolutely necessary for someone to rely on an LLM to generate contributions to a project, if the community is doing its job properly and ensuring that everyone has the resources necessary to participate fully. Someone might prefer to use an LLM rather than ask for help, but that is not the same as LLM use being an absolute necessity. Avoiding cases where LLM use is made necessary means building a community with a supportive culture and positive attitudes towards ensuring accessibility.
I want to repeat here what I’ve already said about inclusivity in general: establishing ethical cultural norms is, on the whole, much more important than policing individual behaviours. People may still choose to use LLMs for personal projects, even if they’re forbidden from using them to generate content for collaborative work within a community. They may use LLMs for accessibility or translation or any of a number of other tasks, even if they can’t use them to generate the actual content they submit to a project. But if the project is built with accessibility in mind, they should never need to use LLMs just to participate. Building inclusive and accessible communities supports people’s ethical agency, as well as setting expectations about the importance of ethical decision making in technological contexts.
The second reason I see LLMs, in particular, as a line in the sand is that using LLMs has a pervasive influence on the quality and the content of what one creates. I may not like the ethics of the company that manufactured my laptop, but that doesn’t make a material difference to what I produce when I use it. The use of LLMs to draft prose or write code or check for errors, in contrast, has both obvious and hidden effects on the output.
LLM content is measurably different from human-produced content. I’ve already outlined how LLM copyeditors perform quite differently from humans, and there are more research papers than I can reasonably cite here showing how LLM-generated text differs from human-authored text. LLMs reproduce patterns from their training data; that’s the core of what they do. This doesn’t just mean reproducing textual patterns (or, indeed, whole chunks of text). It also means reproducing patterns of bias, whether that is overt racism or hidden misogyny (Okerlund, 2022). LLM training data includes everything from the novels of George R. R. Martin to child sexual abuse materials, so the patterns available for reproduction are almost limitless, and some of them are very unpleasant.
You may or may not feel that the massive use of copyrighted content for LLM training constitutes a fair use of that content, and there are legitimate differences of opinion about this question (e.g. Noble, 2025; Gervais, 2024; Variety, 2023). But, importantly, LLM-generated text and code may contain regurgitated chunks of copyrighted material (Gervais, 2024, Mueller2024), and generally fails to reproduce licensing conditions if it regurgitates content which has a restrictive license (Xu, 2025). This violates the intellectual property rights of the original creators in ways that legal systems are, as yet, not well equipped to handle. But we may judge it as ethically undesirable even if it is not actually illegal. Solidarity with the community of creators, both in tech and outside it, means recognizing how much uncompensated labour is embodied by LLM outputs.
Humans are idiosyncratic; they don’t write statistically perfect text. Humans don’t tend to accidentally replicate copyrighted content verbatim. LLM-generated content represents a statistical aggregate of human content, so LLM content can never replicate the surprising innovation of the human mind. LLM-generated content is therefore materially different from human-authored content. It is regressive, taking any text, good or bad, and blending it into a bland regurgitation of the absolute average of human creativity, spiced up with all of humanity’s accidental biases and deliberate bigotries.
Our communities deserve better. Tech projects should demand care and attention in whatever is contributed to them. That doesn’t just mean attention to spelling and grammar and formatting. It means attention to the content itself. It means attention to eradicating bias and promoting inclusion and access. It does not mean absorbing content that we know is generated from a statistical average of all the hate and bias and bullying and sexual abuse the world wide web can offer.
As I said at the beginning, I don’t think I will change the minds of my fellow techies by throwing every possible ethical argument against LLMs at you all at once. I would hope that you have spent some time reading about these other arguments. We owe it to marginalized groups, in particular, to listen when they speak about how our industry is perpetuating and worsening their marginalization. As I’ve written previously, willingness to listen and to hold ourselves to account is part of how we create inclusive, sustainable communities.
Perhaps you come away from this with the feeling that you’d still rather use LLMs. If you do continue using them, I hope you are at least aware of the catastrophic impact LLM use has on the knowledge commons which, without doubt, has helped you grow into the technologist you are. Instead of helping the technological commons flourish, LLM training has stripped its produce, and LLM use is now salting the earth. If you do continue to use LLMs, please try not to let it prevent you contributing the thoughts in your own messy human brain to the technological knowledge commons. Give the community a chance to develop new ideas in response to your questions and thoughts.
But, as I’ve said, I’m less worried about what you do as an individual, and more worried about the decisions we make in and for our communities. The right thing, in my view, for tech communities and projects to do is to reject contributions of LLM-generated content. This doesn’t mean policing whether someone used an LLM to check for spelling errors before submitting some text, or whether they asked an LLM to help with a coding question. It isn’t the place of tech projects to control every aspect of contributors’ workflows. But projects can demand that what is submitted to them, whether that’s a bug report or some code or a redraft of documentation, should not be the output of an LLM. People may not comply, and that’s a matter for their own consciences. But tech communities can, and should, draw this line in the sand.
LLM vendors are in the process of locking users in to their products, using massively subsidized prices to make LLMs “a load-bearing part of every team’s daily workflow” (State Of Brand, 2026), and banking on that lock-in to keep customers paying even when the prices start to reflect the real cost of the LLMs. Major companies are slowly realizing that the cost of using LLMs is actually far greater than the cost of human employees (Fortune, 2026), even as LLMs cause public, costly, and dangerous screwups (Forbes, 2024, Wired, 2024).
LLMs are eroding public trust in technology ever further (Okerlund, 2022), making the web less useful as a repository of knowledge, spreading misinformation at alarming rates (Garry, 2024). LLMs are antithetical to communal understanding, because they tell every individual what that individual wants to hear, with an absolute inability to care whether what they output is true or not. This road ends with the breakdown of shared experience and knowledge, replacing community with hyper-individualism and microcosms of incompatible “facts”.
Of course, blaming the tech community, or even Big Tech, for this breakdown is simplistic. There are broader social issues at play here (Masnick, 2020). Yet public trust in the tech industry has undeniably been hit over and over again by the genuine ethical failures of companies like Meta, Amazon, Apple, and whatever Elon Musk is calling his thing now. In the face of these and other scandals, there may not be much those of us in small tech communities can do to restore trust. But does that mean we shouldn’t try?
I happen to think it means we should try harder.
But we cannot begin to repair the reputational damage to technology as a discipline unless we are willing to make overtly ethical decisions about our technological choices.
LLMs are a line in the sand for me because of their creators’ negligent or deliberate damage to the environment, to labour rights, to scientific integrity, to education, to the open web, to minoritized languages, to human diversity, to healthcare, to privacy, to learning and relationships and mental health.
They are a line in the sand because they are destroying the technological knowledge commons, and replacing it with tools which divert the members of my community into private pseudo-relationships with sycophantic simulacra.
They are a line in the sand because, with all this ethical and physical and psychological damage, with all this destruction of communities and jobs and actual lives, they aren’t even that good at what they’re supposed to do.
Without community to provide the foundations for all our efforts and achievements, even the most antisocial of us is impoverished. Human labour is central to human community: building community is hard work. But the hard work is where the achievement lies, and the achievement makes the community.