In other words, your objection isn't to LLMs, it's to delegation, since the exact same argument would apply to having "some magical thing that could write my code for me" be your co-worker or a contractor.
It's fair for the type of code you want to write for your own growth. But even with that, there's more than enough bullshit boilerplate and trivial cross-language differences that contribute zero (or negatively) to your growth, and is worth having someone else, or something else, write it for you. LLMs are affordable for this, where people usually are not.
If that's the only thing LLMs are good for, my money for improving software productivity is in good old fashioned developer tools.
A better language reduces boilerplate. A better compiler helps you reason about errors. Better language features help you be more expressive. If I need to spool up a jet turbine feeding H100's just to decipher my error messages, the solution is a better compiler, not a larger jet engine.
I myself have noticed this: a wild heterogeneity in the types of tasks for which LLM are helpful. Its appearance as a silver bullet withers the closer you get to essential complexity.
One of my fears with the growing use of LLMs for writing software is that people are using them as a catch-all that prevents them from feeling the pain that indicates to us that there is a better way to do something.
For example, nobody would ever have developed RAII if manual memory management didn’t peeve them. Nobody would have come up with C if they didn’t feel the pain of assembly, or Rust without C, or Typescript without JavaScript, etc. Nobody would have come up with dozens of the genius tools that allow us to understand and reason about our software and enable us to debug it or write it better, had they not personally and acutely felt the pain.
At my job, the people most enthusiastic about LLMs for coding are the mobile and web devs. They say it saves them a lot of time spent writing silly boilerplate code. Shouldn’t the presence of that boilerplate code be the impetus that drives someone to create a better system? The entire firmware team has no interest in the technology, because there isn’t much boilerplate in C. Every line means something.
I worry LLMs will lead to terrible or nonexistent abstractions in code, making it opaque, or inefficient, or incorrect, or all of the above.
Its an interesting observation for sure, but those developers for mobile and web sit at the tippy top of all other abstractions layers. At that position a certain amount of boiler plate is needed because not all controls and code behind are the same, and there is a mighty collection of hacks on hacks to get a lot of things done. I think this is more of “horses for courses” thing where developers higher in the abstraction stack will always benefit from LLMs more and developers lower down the stack have more agency for improvement. At the end of the day, I think everyone gets more productive which is a net positive. Its just that not all developers are after the same goal (Application dev vs library devs vs system devs)
To add to this, LLMs write pretty trite poetry, for example. If we think of code from the creative side, it’s hard to imagine that we’d want to simply hand all coding over to these systems. Even if we got working solutions (which is a major undertaking for large systems), it seems we’d be sacrificing elegance, novelty, and I’d argue more interesting explorations.
> If I need to spool up a jet turbine feeding H100's just to decipher my error messages, the solution is a better compiler, not a larger jet engine.
You don't need a jet turbine and H100s for that, you need it once for the whole world to get that ability; exercising it costs comparatively little in GPU time. Like, can't say how much GPT-4o takes in inference, but Llama-3 8B works perfectly fine and very fast on my RTX 4070 Ti, and it has a significant enough fraction of the same capabilities.
Speaking of:
> A better compiler helps you reason about errors.
There's only so much it can do. And yes, I've actually set up an "agent" (predefined system prompt) so I can just paste the output of build tooling verbatim, and get it to explain error messages in it, which GPT-4 does with 90%+ accuracy. Yes, I can read and understand them on my own. But also no, at this point, parsing multiple screens of C++ template errors or GCC linker failures is not a good use of my life.
(Environment-wise, I'm still net ahead of a typical dev anyway, by staying away from Electron-powered tooling and ridiculously wasteful modern webdev stacks.)
> A better language reduces boilerplate.
Yes, that's why everyone is writing Lisp, and not C++ or Java or Rust or JS.
Oh wait, wrong reality.
> Better language features help you be more expressive.
That's another can of worms. I'm not holding much hopes here, because as long as we insist on working directly on plaintext codebase treated as single source of truth, we're already at Pareto frontier in terms of language expressiveness. Cross-cutting concerns are actually cross-cutting; you can't express them all simultaneously in a readable way, so all the modern language design advances are doing is shifting focus and complexity around.
LLMs don't really help or hurt this either, though they could paper over some of the problem by raising the abstraction level at which programmers edit their code, in lieu of the tooling actually being designed to support such operations. I don't think this would be good - I'd rather we stopped with the plaintext single-source-of-truth addiction in the first place.
> Its appearance as a silver bullet withers the closer you get to essential complexity.
100% agreed on that. My point is, dealing with essential complexity is usually a small fraction of our work. LLMs are helpful in dealing with incidental complexity, which leaves us more time to focus on the essential parts.
> Yes, that's why everyone is writing Lisp, and not C++ or Java or Rust or JS.
> Oh wait, wrong reality.
You are a bit too cynical. The tools (compilers and interpreters and linters etc) that people are actually using have gotten a lot better. Both by moving to better languages, like more Rust and less C; or TypeScript instead of Javascript. But also from compilers for existing languages getting better, see especially the arms race between C compilers kicked off by Clang throwing down the gauntlet in front of GCC. They both got a lot better in the process.
(Common) Lisp was a good language for its time. But I wouldn't hold it up as a pinnacle of language evolution. (I like Lisps, and especially Racket. And I've programmed about half of my career in Haskell and OCaml. So you can rest assured about my obscure and elitist language cred. I even did a year of Erlang professionally.)
---
Btw, just to be clear: I actually agree with most of what you are writing! LLMs are already great for some tasks, and are still rapidly getting better.
You are also right that despite better languages being available, there are many reasons why people still have to use eg C++ here or there, and some people are even stuck on ancient versions of or compilers for C++, with even worse error messages. LLMs can help.
It's fair for the type of code you want to write for your own growth. But even with that, there's more than enough bullshit boilerplate and trivial cross-language differences that contribute zero (or negatively) to your growth, and is worth having someone else, or something else, write it for you. LLMs are affordable for this, where people usually are not.