Why LLMs Are Useful to Programmers and Not so Much to Others

One of the emerging dichotomies is the way in which people's perspectives on LLMs are shaped by the primary way they interact with them. Programmers who use them to help write code tend to think they're quite useful and end up overestimating their usefulness in other areas. Conversely, people in other fields, such as those that involve substantial original writing, are finding them to be so useless that they end up underestimating their usefulness in programming.

While I believe that programming is quite likely the field where LLMs are the most useful, if only because AI developers inherently have the most direct experience there, I am going to use writing as the opposite example because that is where I have the most personal experience from which to speak from some sort of authority.

The reason that LLMs are useful for programming is not that LLMs are actually good at writing code. They're not. They frequently produce code that completely misunderstands what is needed, doesn't run without error or my personal favorite, tell me to fix my code with an exact copy of my code.

The critical difference is the ability to quickly and easily pull out the good stuff from a bunch of mostly bad code. I think there are 3 significant reasons why this is the case:

1. Well developed error finding tools

The nature of programming means that there are robust systems of identifying, fixing and preventing errors that simply cannot exist in a less structured endeavour such as writing.

Every programming language produces error message, some more helpful than others, that show up for certain types of mistakes.

Not that all code that runs without a breaking error is necessarily completely bug free, but extremely minor problems, such as misplaced or missing punctuation, can stop an entire program from working at all. Being able to immediately pinpoint the cause of the problem can save untold hours of looking for errors.

Another error finding tool is tests that are run to confirm that working programs behave as expected so that new features and additions don't break previously working functionality.

One of the more extreme examples is Oracle Database as described in this 2018 Hacker News post about the 20 to 30 hour testing process that keeps new code from breaking anything in the 25 million existing lines of code:

What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.

...

The only reason why this product is still surviving and still works is due to literally millions of tests!

2. Limited opportunity cost to trying something

There are many situations in programming where the opportunity cost to trying something to see if it works is as low as a few seconds.

Here is one example:

(FWIW, a handy use of an AI tool: I ran the episode through a system to get a transcript which is so, so, but it put a time stamp like every 5 words. I started to write a script to remove the time stamps.. but then... just asked the AI to do it, and it worked)

— Mike Masnick (@mmasnick.bsky.social) January 15, 2025 at 10:55 PM

There are many situations like this where LLM produced code can be tested to see if it works in just a few seconds. If you know the input, what the output should be and glance at the code to make sure it's not going to do anything that can't be undone, just running it to see if it works correctly.

Conversely, the time it takes to read through a written work to look for mistakes can easily take just as long as initially producing the content if it requires any sort of fact checking.

3. New work is derivative and repetitive

Obviously there are programming projects that are truly new and innovative and not like anything that has existed previously, but there are so many projects that are just implementations of one idea in a certain language or framework