Live data from Hacker News

The insecure evangelism of LLM maximalists

lewiscampbell.tech

81–90 of 295 posts

Re: The insecure evangelism of LLM maximalists

#81
post #3

Hearing people on tech twitter say that LLMs always produce better code than they do by hand was pretty enlightening for me. LLMs can produce better code for languages and domains I’m not proficient in, at a much faster rate, but damn it’s rare I look at LLM output and don’t spot something I’d do measurably better. These things are average text generation machines. Yes you can improve the output quality by writing a…

This has been my experience as well. It's let me apply my general knowledge across domains, and do things in tech stacks or languages I don't know well. But that has also cost me hours debugging a solution I don't quite understand. When working in my core stack though it's a nice force multiplier for routine changes.

>When working in my core stack though it's a nice force multiplier for routine changes.

what's your core stack?

Re: The insecure evangelism of LLM maximalists

#82
post #3

Hearing people on tech twitter say that LLMs always produce better code than they do by hand was pretty enlightening for me. LLMs can produce better code for languages and domains I’m not proficient in, at a much faster rate, but damn it’s rare I look at LLM output and don’t spot something I’d do measurably better. These things are average text generation machines. Yes you can improve the output quality by writing a…

After a certain experience level though, I think most of us get to the point of knowing what that difference in quality actually matters. Some seniors love to bikeshed PRs all day because they can do it better but generally that activity has zero actual value. Sometimes it matters, often it doesn't. Stop with the "I could do this better by hand" and ask "is it worth the extra 4 hours to do this by hand, or is this ac…

Perhaps writing code by hand will be considered micro optimisation in the future.

Just like writing assembly is today.

Re: The insecure evangelism of LLM maximalists

#83
post #14

This doesn't feel completely right. Simon Wilson (known for Django) has been doing a lot of LLM evangelism on his blog these days. Antirez (Redis) wrote a blog post recently with the same vibe. I doubt they are not good programmers. They are probably better than most of us, and I doubt they feel insecure because of the LLMs. Either I'm wrong, or there's something more to this. edit: to clarify, I'm not saying Simon a…

I suspect for truly talented people, they just like talking to LLMs. And they're also not 100% focused on programming anymore, so the async nature of it matters more than it does to people who write code full time for a living.

Re: The insecure evangelism of LLM maximalists

#84
post #13

"I find LLMs useful as a sort of digital clerk - searching the web for me, finding documentation, looking up algorithms. I even find them useful1 in a limited coding capacity; with a small context and clear guidelines." I am curious why the author doesn't think this saves them time (i.e. makes them more productive). I never had terribly high output as a programmer. I certainly think LLMs have helped increased the amo…

It seems you find LoC as a measure of productivity. This would answer your question as to why the author does not find it makes them more productive. If total output increases, but quality decreases (which in terms of code means more bugs) then has productivity increased or has it stayed the same? To answer my own question, if you can pump out features faster but turn around and spend more time on bugs than you do pr…

I didn't mean to imply LoC as a measurement of productivity. What I really mean is more "amount of useful code produced to a level the human-using-the-llm determines to be useful".

To try and give an example, say that you want to make a module that transforms some data and you ask the LLM to do it. It generates a module with tons of single-layer if-else branches with a huge LoC. Maybe one human dev looks at it and says, "great this solves my problem and the LoC and verbosity isn't an issue even though it is ugly". Maybe the second looks at it and says, "there's definitely some abstraction I can find to make this easier to understand and build on top of."

Depending on the scenario and context, either of them could be correct.

Re: The insecure evangelism of LLM maximalists

#85
post #3

Hearing people on tech twitter say that LLMs always produce better code than they do by hand was pretty enlightening for me. LLMs can produce better code for languages and domains I’m not proficient in, at a much faster rate, but damn it’s rare I look at LLM output and don’t spot something I’d do measurably better. These things are average text generation machines. Yes you can improve the output quality by writing a…

After a certain experience level though, I think most of us get to the point of knowing what that difference in quality actually matters. Some seniors love to bikeshed PRs all day because they can do it better but generally that activity has zero actual value. Sometimes it matters, often it doesn't. Stop with the "I could do this better by hand" and ask "is it worth the extra 4 hours to do this by hand, or is this ac…

[deleted]

Re: The insecure evangelism of LLM maximalists

#86
post #7

> And then, inevitably, comes the character evaluation, which goes something like this: I saw a version of this yesterday where a commenter framed LLM-skepticism as a disappointing lack of "hacker" drive and ethos that should be applied to making "AI" toolchains work. As you might guess, I disagreed: The "hacker" is not driven just by novelty in problems to solve, but in wanting to understand them on more than a surf…

I share your fear. We have a hard enough time finding juniors (hell, non-juniors) that know how to program and design effectively. The industry jerking itself off over Leetcode practice already stunted the growth of many by having them focus on rote memorization and gaming interviews. With ubiquitous AI and all of these “very smart people” pushing LLMs as an alternative to coding, I fear we’re heading into an era whe…

> to cut out all of the people that never really had an interest in CS

I had assumed most of them had either filtered out at some stage (an early one being college intro CS classes), ended up employed somewhere that didn't seem to mind their output, or perpetually circle on LinkedIn as "Lemons" for their next prey/employer.

My gut feeling is that messy code-gen will increase their numbers rather than decrease them. LLMs make it easier to generate an illusion of constant progress, and the humans can attribute the good parts of the output to themselves, while blaming bad-parts on the LLM.

Re: The insecure evangelism of LLM maximalists

#87
post #31
post #14

This doesn't feel completely right. Simon Wilson (known for Django) has been doing a lot of LLM evangelism on his blog these days. Antirez (Redis) wrote a blog post recently with the same vibe. I doubt they are not good programmers. They are probably better than most of us, and I doubt they feel insecure because of the LLMs. Either I'm wrong, or there's something more to this. edit: to clarify, I'm not saying Simon a…

The author claims it's not just that one evangelizes it, but that they become hostile when someone claims to not have the same experience in response. I don't recall Either Willison or Antirez scaring people by saying they will be left behind or that they are just afraid of becoming irrelevant. Instead they just talk about their positive experiences using it. Willison and Antirez seem to be fine to live and let live…

Thanks for clarifying for people.

And yeah, as I laid out in the article (that of course, very few people actually read, even though it was short...), I really don't mind how people make code. It's those that try so hard to convince the rest of us I find very suspect.

Re: The insecure evangelism of LLM maximalists

#88
post #67
post #52

Earlier quoted context omitted.

How would one set this sort of test up? I surely have example domains where LLMs routinely do poorly (for example, custom bazel rules and workspaces), but what would constitute a "showcase" here?

To change my mind I’ll be satisfied with a thorough description of the domain and ideally a theory on why it does poorly in that domain. But we’re not talking LLMs here, we’re talking opus4.5 specifically.

A theory besides... not enough training data? Is it even possible to formulate a coherent theory about this? I'm talking about customizing a widely-used build system, not exactly state-of-the-art cryptography. What could I possibly say that you wouldn't counter with "skill issue" (which goes back to the author's point)?

If you say it's demonstrably impossible that someone can't be made more productive with opus4.5, then it should probably be up to you to demonstrate impossibility.

Re: The insecure evangelism of LLM maximalists

#89
post #13

"I find LLMs useful as a sort of digital clerk - searching the web for me, finding documentation, looking up algorithms. I even find them useful1 in a limited coding capacity; with a small context and clear guidelines." I am curious why the author doesn't think this saves them time (i.e. makes them more productive). I never had terribly high output as a programmer. I certainly think LLMs have helped increased the amo…

It seems you find LoC as a measure of productivity. This would answer your question as to why the author does not find it makes them more productive. If total output increases, but quality decreases (which in terms of code means more bugs) then has productivity increased or has it stayed the same? To answer my own question, if you can pump out features faster but turn around and spend more time on bugs than you do pr…

LoC is a terrible metric for comparing productivity of different developers, even before you get to Goodhart's Law.

OTOH, for a given developer to implement a given feature in a given system, at the end of the day, some amount of code has to be written.

If a particular developer finds that AI lets him write code comparable to what he would have written, in lieu of the code he would have written, but faster than he can do it alone, then looking at lines written might actually be meaningful, just in that context.

Re: The insecure evangelism of LLM maximalists

#90
post #42
post #14

This doesn't feel completely right. Simon Wilson (known for Django) has been doing a lot of LLM evangelism on his blog these days. Antirez (Redis) wrote a blog post recently with the same vibe. I doubt they are not good programmers. They are probably better than most of us, and I doubt they feel insecure because of the LLMs. Either I'm wrong, or there's something more to this. edit: to clarify, I'm not saying Simon a…

You seem to be mistaking set and members here. The piece's critique is against the set (LLM Evangelists), not against specific members of the set (the ones you mentioned). One can agree with the point of the piece while still acknowledging there are good programmers who are also LLM evangelists.

You are right, I went a bit too quickly so let me expand a bit my chain of thoughts.

The article is against the set of LLM evangelists who are hostile towards the skeptics.

I 100% agree with the part that basically says fuck you to them.

However, explaining the hostile part with there being the feeling of insecurity (which is plausible but would need evidence) is not fully convincing and it seems dangerous to accept this conclusion and stop looking for the actual reasons this quickly.

And the fact that there are actually good programmers persuaded that LLMs help them weakens the "insecurity" argument quite a bit, at least as the only explanation.

As someone currently pretty much hostile to LLMs, I'm quite interested in what's currently at play but I'm suspicious of claims that initially feel good but are not strongly backed.

Like, if these hostile people were actually shills, we would want to know this and not have closed the eyes too early because of some explanation that felt good, right? Or any actual reason.

Post reply on HN