LLM's are obviously a very contentious topic that has been dominating the conversation for over three years now. Thus, nothing I have to say on the topic hasn't already been presented better by a smarter person than me. Nevertheless, I want to present (parts of) my current stance here. If I have linked you to this page, know that I'm not dismissive of you, I am just getting a bit tired of the subject and don't like repeating myself again and again.

As you'll have guessed from the title, I am currently not interested in using LLM's in the coding process. In fact, I am in general not really interested in the technology as a whole, but for the sake of conciseness, I will limit this to coding, specifically. In short, I don't see a real need for it, offloading the task of coding seems actively counterproductive to me, and I've got serious ethical concerns with how these things are being built, operated, and pushed (sorry, I refuse to sell all of my morals for work).

For some context, I have been vaguely interested in programming since 10th grade or so and have been actively programming since 2017 and professionally since 2023. I am mostly interested in software design and dev tooling but also like to dabble in performance optimizations when necessary. I've mostly programmed in Python and Java, though nowadays I am more interested in purely functional languages, especially Clojure.

I give this context because my perspective is from someone who is very comfortable with reading, designing, and writing code. I can't remember the last time I've struggled with a coding project on a technical level (e.g. not knowing how to design or implement something). Obviously, I don't magically create perfect code at a prodigious pace or without any issues, but those usually arise from incomplete, unclear, or incompatible requirements or needing to use a tool that is lacking in decent documentation.

I Don't See the Need

One of the most common objections to generating code itself is that "writing the program is not the bottleneck". I largely agree with this. Obviously, the physical act of writing out code still takes a bit of time, but in my experience, it is not what most software developers are actively doing most of the time. If I would have to guess, I probably spend 10 to 20 percent of my time actively writing code.

Now, what I've heard a lot is that developers don't always use LLM's to generate code; they only generate the boring, boilerplate stuff. This always baffles me. My answer to having lots of boilerplate would be to instead invest in robust libraries that take care of repetitions. I suspect that part of this is that I program in a very functional style, which introduces abstractions from common operations, such as iterating over data structures (see my series on map, filter, reduce, which I really need to continue, oops).

Another common use-case I've seen suggested is generating tests. This, again, I don't see a need for. Test-driven development (TDD), which has you write tests before you implement something, seems to be relatively mainstream nowadays, at least in my bubble. With TDD, it obviously doesn't make any sense to automatically generate tests, since those are essentially the specification of your functionality.

Related to generating tests, I've seen it suggested that you can generate test data with LLM's. This, again, just doesn't seem to be a good solution to me, given that property-based testing frameworks are pretty ubiquitous and well established now. These let you write special kinds of tests with randomized inputs and can get very sophisticated. You can even generated complex, custom data structures with inter-dimensional dependencies. While that obviously takes some initial effort, a well-designed code-base can really profit from this approach. However, property-based testing seems to be a lot less common than TDD, from what I gather, so I am less surprised at this suggestion.

Finally, there is reading code. Obviously, you should never need to require external help to understand a code-base. Ideally, there is some documentation describing the general structure and architecture and all the functions are well documented, largely eliminating the need to even dive into code itself. Of course, not all code-bases fulfill all those criteria all of the time. However, I don't think LLM's are trustworthy enough to rely on in these cases. Though I do admit they may be useful as a jumping-off point, to get started somewhere. I see little risk here, as long as they are not too heavily relied upon and the actual documentation is written by humans.

I Think They Are Counterproductive

But even if the "productivity gains" from using LLM's during the software engineering process were real, I still think relying on them will lead to worse outcomes in the long-run.

For one, on a purely egoistical note, I think coding is fun and fulfilling, and I think a lot of people will agree. The act of thinking something up in your head, writing it down, and seeing the results is awesome. In our current world, coding is probably the best way to be a craft worker. Writing code also requires relatively little cognitive effort, though it is full of micro-decisions, like naming variables, which prevents it from being completely brain-dead. This, to me, is a huge relief from the high cognitive effort of contextualizing a project and coming up with well designed solutions. The burn-out rate among programmers is already pretty high; I don't want to imagine what it will look like if the one least taxing part of the job gets replaced by one of the most taxing ones, code review.

On that note, I am also sure that the appeal of this career will drastically go down if we just query LLM's to generate software. As I have just mentioned, this basically means replacing writing code with reviewing it. And that seems to be one of the least liked aspects of software engineering. Personally, I really like reviewing code, but that is only because I know there is another human being on the other hand that is willing to learn from or discuss with me. It is less about ensuring the quality of the code at hand at more about improving the quality of code that that programmer, or the reviewer, will produce for the rest of this project, and hopefully even for the rest of their career.

However, there is also a long-term productiveness argument to be made in favor of typing code out by hand:

  • The act of typing something out makes it stick way more than merely reading it does. There's a reason why the person that understands a piece of code the best is always the one who wrote it. And this isn't just constrained to understanding of the implementation of a function, but the entire domain it lives in. By kind of living in the domain for a bit, I tend to get a way stronger appreciation for it.
  • Similarly, writing the code makes you feel more responsible for it. While there can also be some negatives associated with it, like becoming overly defensive about a solution, I think this is generally positive. You want to have at least one person who actually cares about any piece of code. If they feel responsible for it, they are more likely to fix any issues that may come up due to it.
  • The fact that typing takes some time also means that you are forced to engage with the code, its implementation, and its context for some amount of time. Because it is not particularly taxing, this leaves some brain space for thinking about these things a bit more thoroughly.
  • There is an incredibly useful signal during coding: something feels painful. This is one of my go-to ways of evaluating if a design, both of the functionality I'm currently building and its broader context, actually works. Now, sometimes you can also tell that something isn't quite right just by looking at it, but I find that it is much easier to just overlook those issues (instead of actively deciding not to follow them). This may be as small as missing a function in the domain and as large as a design actively fighting against what I'm currently trying to do.

And then there is the fact that, fundamentally, LLM's, and machine learning models in general, are replication machines. They find patterns in the input data. This essentially means that, if software engineering were to heavily rely on LLM's, the field of computer science would stagnate. The cost of using a smaller and/or newer language would be too heavy to bear, as there is too little training data for it, leading to worse quality of the generated code. But even for existing languages, the ecosystem would essentially become locked in – already heavily used libraries and frameworks become an even larger convergence point than they already are. And good luck trying to stray from the conventional coding style (e.g. doing functional programming in Python) or building domain-specific languages. As someone who loves learning new things, this would basically kill my passion for software engineering.

Ethical Concerns

Because this isn't really a technical issue, I don't want to go into too much detail here. Luckily, I don't think this is really necessary, as these issues should be common knowledge.

Training and operating LLM's requires ridiculous amounts of resources. And what's worse is that we are still in the middle of the climate crisis, so we cannot really afford to use those. Water is getting sparser and their electricity usage is keeping fossil-fueled power plants running. The vast sums of money investments would be better served actually saving this planet and the hardware required to run LLM's is making all electronics more expensive, in the middle of a cost of living crisis.

LLM's results are also only impressive because of the vast amount of data that is being fed into them. While it looks like it may technically be legal, scraping any publicly available source of information, regardless of its license or the owner's interests, is obviously amoral. What's worse, the fact that crawlers are getting more and more unscrupulous in order to try to obtain previously inaccessible information is making websites more and more expensive to run. This is especially bad for smaller projects like Codeberg or the small web in general. I've heard some accounts (like this one) of scrapers now making up more than half of all requests to sites. As illustrated in Codeberg's statement on LLM's, this is just one of the ways that tech companies are externalizing the costs of building these products.

Finally, there is the issue of power (not electricity, this time). Currently, the really useful models are either fully controlled by big tech companies or require powerful hardware to run locally. The former gives huge amounts of power to those companies, incomparable to their current influence through control of social media, search, and ads if the prophecies are to be believed, whilst the latter prices out small businesses and most consumers.