Live data from Hacker News

The insecure evangelism of LLM maximalists

lewiscampbell.tech

121–130 of 295 posts

Re: The insecure evangelism of LLM maximalists

#121
post #57

Earlier quoted context omitted.

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…

"actually good enough to meet the goals?" There's "okay for now" and then there's "this is so crap that if we set our bar this low we'll be knee deep in tech debt in a month". A lot of LLM output in the specific areas _I_ work in is firmly in that latter category and many times just doesn't work.

So I can tell you don’t use these tools, or at least much, because at the speed of development with them you’ll be knee deep in tech debt in a day, not a month, but as a corollary can have the same agentic coding tools undergo the equivalent of weeks of addressing tech debt the next day. Well, I think this applies to greenfield AI-first oriented projects that work this way from the get go and with few humans in the loop (human to human communication definitely becomes the rate limiting step). But I imagine that’s not the nature of your work.

Re: The insecure evangelism of LLM maximalists

#122
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…

I feel like it makes me more productive, but I am not even sure it does even with my light usage. How do we even measure it?

I also feel like it makes me more productive but measuring software engineering productivity is famously difficult. If there was an easy way to measure it, managers at bigco would have employed it with abandon years ago.

Re: The insecure evangelism of LLM maximalists

#123
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…

> if you’re seeing output that is consistently better than what you produce by hand, you’re probably just below average at programming

even though this statement does not mathematically / statistically make sense - vast majority of SWEs are “below average.” therein lies the crux of this debate. I’ve been coding since the 90’s and:

- LLM output is better than mine from the 90’s

- LLM output is better than mine from early 2000’s

- LLM output is worse than any of mine from 2010 onward

- LLM output (in the right hands) is better than 90% of human-written code I have seen (and I’ve seen a lot)

Re: The insecure evangelism of LLM maximalists

#124

Earlier quoted context omitted.

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…

LLM generated code is technical debt. If you are still working on the codebase the next day it will bite you. It might be as simple as an inconvenient interface, a bunch of duplicated functions that could just be imported, but eventually you are going to have to pay it.

In your comment replace “LLM” with “Human SWE” and statement will still be correct in vast majority of the situations :)

Re: The insecure evangelism of LLM maximalists

#125
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…

It'd be rather surprising if you could train an AI on a bunch of average code, and somehow get code that's always above average. Where did the improvement come from? We should feed the output code back in to get even better code.

AI generally can improve through reinforcement learning, but this requires it to be able to compare its output to some form of metric. There aren't a lot of people I'd trust to RLHF for code quality, and anything more automated than that is destined to collapse due to Goodhart's Law.

Re: The insecure evangelism of LLM maximalists

#126
post #110

Earlier quoted context omitted.

I've been playing with vibe coding a lot lately and I think in most cases, the current SOTA LLM's don't produce code that I'd be satisfied with. I kind of feel like LLM's are really really good at hacking on a messy and fragile structure, because they can "keep track many things in their head" BUT An LLM can write a PNG decoder that works in whatever language I choose in one or a few shots. I can do that too, but it…

I tried vibe coding a BMP decoder not too long ago with the rationale being “what’s simpler than BMP?” What I got was an absolute mess that did not work at all. Perhaps this was because, in retrospect, BMP is not actually all that simple, a fact that I discovered when I did write a BMP decoder by hand. But I spent equal time vibe coding and real coding. At the end of the real coding session, I understood BMP, which I…

Mind explaining the process you tried? As someone who’s generally not had any issue getting LLMs to sort out my side projects (ofc with my active involvement as well), I really wonder what people who report these results are trying. Did you just open a chat with claude code and try to get a single context window to one shot it?

Re: The insecure evangelism of LLM maximalists

#127
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…

The most prolific coders are also more competent than average. Their proliferations are what have trained these models. These models are trained on incredibly successful projects written by masters of their fields. This is usually where I find the most pushback is that the most competent SWEs see it as theft and also useless to them since they have already spend years honing skills to work relentlessly and efficientl…

I'd assume most of the code visible on the web leans amateur. A huge portion of github repos seem to be from students these days. You'll see GitHub's Education page listing "5 million students" (https://github.com/education), which I assume is an under-estimate, as that's only the formal program.

Re: The insecure evangelism of LLM maximalists

#128

Earlier quoted context omitted.

LLM generated code is technical debt. If you are still working on the codebase the next day it will bite you. It might be as simple as an inconvenient interface, a bunch of duplicated functions that could just be imported, but eventually you are going to have to pay it.

In your comment replace “LLM” with “Human SWE” and statement will still be correct in vast majority of the situations :)

That's legit true. All code is technical debt. Human SWEs have one saving grace. Sometimes they refactor and reduce some of the debt.

Re: The insecure evangelism of LLM maximalists

#129

Earlier quoted context omitted.

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…

LLM generated code is technical debt. If you are still working on the codebase the next day it will bite you. It might be as simple as an inconvenient interface, a bunch of duplicated functions that could just be imported, but eventually you are going to have to pay it.

All code is technical debt though. We can't spend infinite hours finding the absolute minima of technical debt introduced for a change, so it is just finding the right balance. That balance is highly dependent on a huge amount of factors: how core is the system, what is the system used for, what stage of development is the system, etc.

Re: The insecure evangelism of LLM maximalists

#130
post #104
post #72

Earlier quoted context omitted.

I think you should read the article again, because this comment is a straw man vis-a-vis the article.

Is it? The article starts from the premise that LLMs are only good for vibe-coding.

No it doesn't.

It starts from the premise that the author finds LLMs are good for limited, simple tasks with small contexts and clearly defined guidelines, and specifically not good for vibe-coding.

And the author literally mentions that they aren't making universal claims about LLMs, but just speaking from personal experience.

Post reply on HN