Different Beasts
#software
#ai
#writing
2026-07-09
Both software developers and writers create text for a living, but their average sentiment about using LLMs for their jobs is different. Programmers have generally embraced LLMs at varying degrees at their day-jobs and for hobby projects, while a larger proportion of writers remains against LLM usage for their work. At least, that has been my general impression from what I’ve been reading and listening.
For this post, I will set aside important moral considerations about the effects of LLMs: energy consumption, water usage, pollution, scam potential, IP theft, and layoffs attributed to AI. Also, I will briefly ignore that many of the supposed benefits, such as higher productivity and better output quality, are not being realized in many fields where LLMs are applied. These issues cannot be easily dismissed, but on this occasion I will proceed to focus on a different aspect of LLM usage.
Assuming all other problems with generative AI were gone, from a professional ethics perspective, it would be acceptable for developers to use LLMs to generate code, even without disclosing it, but not for writers to generate text. If developers are asked about AI usage, however, they should be honest about it. The main reason for this difference is that code is not the interface that users see; words are. Users cannot see the code and do not care about its specifics, while most readers do care about the actual words on the page. Users only care about the effects of the code (how the software works), not its shape. As long as the system operates as expected by the user, most users will have no qualms about AI usage for code generation.
Programmer -> Code -> Interface: User Interface (UI) <- User
Writer -------------> Interface: Text <---------------- Reader
So, while developers write code that is mediated by the user interface, writers create text that is seen directly by the reader. Note that the code used to create the user interface IS NOT the user interface itself. In fact, people who design user interfaces (designers, in general) should feel more aligned with writers on AI usage sentiment. Work in the interface is directly perceived by the user.
Expectations While Reading
Readers assume that the words they read were written by a human unless told otherwise. In nonfiction, they will make the effort to read because they assume another human went through the effort of thinking and writing so as to create a sensible set of words that convey a well-reasoned idea. In fiction, readers expect that the author’s personality, experiences, ability, and feelings (his or her humanity) reflect on the choice of words and structure, generating written stories that thrill, evoke, and disseminate insights about the human condition.
When I chose how to write, I am making a set of decisions that inform the words that will be seen by the reader. When I chose how to code, the effect on the user is indirect. Code is (except for a few weird exceptions) not written for its aesthetic effect, but for its functionality, and there are multiple ways to achieve an almost identical functionality. From the user’s perspective, code is an invisible means to an end. Users, in general, do not expect every single line of code to be carefully chosen and crafted for their enjoyment. But more importantly, when I write, I’m also articulating my thoughts internally, deciding how I think the world works, what is true, and what should I say about it. Without writing the words it’s almost impossible to think the thoughts.
Following that reasoning, it’s more important to avoid (or disclose) AI usage in some pieces of text than others. For example, when reading is about enjoyment or deep understanding, writers should carefully consider whether to use LLMs is worth it. Novels, short stories, essays, and New Yorker articles are expected to be carefully written and reviewed by humans. I’ll call this kind of writing High-Quality Writing or HiQ writing, since readers will usually have a higher bar for it. On the other hand, quick video summaries, daily stock reports, chart summaries, and other kinds of text where the specific words are not as important as the information they are trying to transmit are examples of LoQ writing. In other words, when the choice of words matters, AI usage should be discouraged or at least carefully reviewed. True, LLMs can sometimes help with tasks like research, fact-checking, and edition, with varying degrees of success, but writers should be careful not to let LLMs do their writing for them if they are to honor the social contract. The key activity of writing is carefully choosing and structuring words to convey ideas, and if LLMs do that for the writer, there is little reason for the reader to read, since he could that by himself.
Contrast this with software development, where code is invisible to the user (though not inconsequential). In software, the concept of plagiarism is almost nonexistent. Depending on licensing, as in the case of open-source software, copying, and reusing code is encouraged. Programmers are often free to include other programmers’ code in their codebases (for example, in the form of libraries), and will happily share their code with the expectation of it being copied verbatim.
Other Developers Are Code Readers
Software developers read code, so the effect of the code on them is not indirect, but direct. Discussions abound on the importance of a clean codebase but, as an industry, software has developed practices to improve code quality not only because it affects the users indirectly, but also because it affects developers directly. While code quality can generate effects that users experience, like performance and stability, its effects on the work of software developers are much more tangible. Better code leads to a better understanding of the codebase, meaning that developers can better manage the application’s behavior. This has highly beneficial consequences, like a lower defect rate, higher velocity (coding features faster), faster debugging, and better estimations.
It bears saying that no one knows exactly what good code looks like, but most coders will agree when a piece of code is ugly. While aesthetic and logical judgements could be made about a piece of code, the key part of good code is avoiding complexity. Users cannot guess good code from using the application alone. Applications might look and work fine on the surface, yet be the result of messy code, meaning that subtle bugs might be undetected until users interact with the specific buggy code path.
Another key distinction between writing and coding is that most readers are expected to read all the words in the text, while each user only triggers a small percentage of the written code depending on which features they use. This means that for some users a lot of coding decisions are completely inconsequential. But even if every user triggered every code path (which is statistically impossible even for small codebases), sometimes different coding implementations are semantically the same thing: they perform very similar work in similar time using similar resources.
Quality
Quality is the opposite of slop. It is achieved by making the right decisions in order to improve the product (text or code), and a higher number of correct decisions leads to higher quality. For both writing and coding, professional standards are about the expected quality of the product. In coding, the product is both the application and the code itself: the output for users (the application) and for other developers (codebase). LLMs have the capacity to churn out output fast, so they have a huge potential to lower the quality of the product because they make a huge number of decisions that might not be correct for a given context. While having tools and strategies to create a lot of code fast is nothing new, the speed and scale of LLMs make matters worse.
While LLMs can do an acceptable job on LoQ writing they still can’t do a great job when each word matters. Articles, stories, nonfiction, and novels (HiQ writing) written with heavy AI usage display obvious tells, are unoriginal, and sometimes make it painfully obvious that there is no cohesive consciousness driving the text forward.
On the other hand, LLMs can do a good job on certain programming tasks, like helping create front-end components, integrating applications with third-party APIs, and building prototypes. Coding is a much more constrained discipline since it seeks to achieve a set of specific goals (requirements) while, in writing, goals and constraints are not that clear. Again, LLMs fail when a cohesive idea is required: when taste and context is needed. That is, when someone needs to understand the feature in context, considering the system architecture, the chosen abstractions, the potential for maintainability, and the overall complexity.
Programmers using LLMs with discipline can still keep a high-quality output, even if LLMs write the code for them. Writers using LLMs for writing (LLMs that choose or edit their words) are outsourcing their thinking: the thing that allows them to choose the right words, structures, and ideas to build their product (text) and present it to the readers. But programmers need to be careful too. It’s too easy to fall into the temptation to cut corners to speed things up, even knowing that this leads to the accumulation of technical and cognitive debt. Choosing quality over speed is a fight that has to be fought every day.