Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The insecure evangelism of LLM maximalists

lewiscampbell.tech

Post reply on HN
Print view View original

171–180 of 295 posts

Re: The insecure evangelism of LLM maximalists

#171

Post by moron4hire »

meowface wrote: post #23

I feel no strong need to convince others. I've been seeing major productivity boosts for myself and others since Sonnet 3.5. Maybe for certain kinds of projects and use cases it's less good, maybe they're not using it well; I dunno. I do think a lot of these people probably will be left behind if they don't adopt it within the next 3 years, but that's not really my problem.

What's there to be left behind on? That's like arguing people who stick to driving cars with manual transmissions are going to get left behind when buses "inevitably get good."

The whole point of the AI coding thing is that it lets inexperienced people create software. What skill moat are you building that a skilled software developer won't be able to pick up in 20 minutes?

Re: The insecure evangelism of LLM maximalists

#172

Post by [deleted] »

lijok wrote: post #67
j2kun wrote: 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.

[deleted]

Re: The insecure evangelism of LLM maximalists

#173

Post by dzonga »

if A.I maximalist gospel was true - we would see a company raising $10M Series A | Seed (these days)

spend 60% on A.I, 30% on Humans and 10% on operations but I can bet you my sole penny that's not happening - so we know someone is tryna sell us a polished turd as a diamond

Re: The insecure evangelism of LLM maximalists

#175

Post by 2muchcoffeeman »

throwawayffffas wrote: post #115
wild_egg wrote: post #41

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.

Are people not reviewing and refactoring LLM code?

Re: The insecure evangelism of LLM maximalists

#176

Post by _kb »

SchemaLoad wrote: post #160
ymyms wrote: post #38

Earlier quoted context omitted.

My gut says that is not a property of LLM evangelists, but a property of current internet culture in general. People with strong, divisive, and engaging opinions seem to do well (by some definition of well) online.

It's weird how some people seem to treat using an LLM as part of their personality in a borderline cult like way. So someone saying they don't use it or don't find it useful triggers an anger response in them.

That is not novel - see language/framework choice, OS (or even distro) preferences, editor wars, indentation. People develop strong opinions about tools, technology, and techniques regardless of domain. LLM maximalists just have the unfortunate capability to generate infinite content about their specific shiny thing.

Re: The insecure evangelism of LLM maximalists

#177

Post by raddan »

zahlman wrote: post #143
raddan wrote: post #110

Earlier quoted context omitted.

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…

Just out of curiousity (as someone fairly familiar with the BMP spec, and also PNG incidentally): what did you find to be the trickiest/most complex aspects?

None of this is fresh in my mind, so my recollections might be a little hazy. I think the only issue I personally had when writing a decoder was keeping the alignment of various fields right. I wrote the decoder in C# and if I remember correctly I tried to get fancy with some modern-ish deserialization code. I think I eventually resorted to writing a rather ugly but simple low-level byte reader. Nevertheless I found it to be a relatively straightforward program to write and I got most of what I wanted done in under a day.

The vibe coded version was a different story. For simplicity, I wanted to stick to an early version of BMP. I don’t remember the version off the top of my head. This was a simplified implementation for students to use and modify in a class setting. Sticking to early version BMPs also made it harder for students to go off-piste since random BMPs found on the internet probably would not work.

The main problem was that the LLM struggled to stick to a specific version of BMP. Some of those newer features (compression, color table, etc, if I recall correctly) have to be used in a coordinated way. The LLM made a real mess here, mixing and matching newer features with older ones. But I did not understand that this was the problem until I gave up and started writing things myself.

Re: The insecure evangelism of LLM maximalists

#178

Post by moron4hire »

rudedogg wrote: 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 firing up old coal plants and skyrocketing RAM prices and $5000 consumer GPUs and violating millions of developers' copyrights and occasionally coaxing someone into killing themselves is the cost of Brian Who Got Peter Principled Into Middle Management getting to enjoy programming again instead of blaming his kids for why he watches football and drinks all weekend instead of cultivating a hobby, I guess we have no choice but to oblige him his little treat.

Re: The insecure evangelism of LLM maximalists

#179

Post by hu3 »

krapp wrote: post #130
hu3 wrote: post #104

Earlier quoted context omitted.

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.

You're offering a very generous interpretation. To the point of extrapolating what's written. Allow me to exemplify:

> I genuinely don't mind if other people vibe code. Go for it!

> But that is not enough for the vocal proponents. It's the future!

The author is okay for others to voice their positive opinion about LLMs as long as it is limited to vibe coding.

It starts defining a gatekeeping threshold of what level of positive opinion is acceptable for others to have, according to the author.

Re: The insecure evangelism of LLM maximalists

#180

Post by bawolff »

Terr_ wrote: 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…

> What I "fear" from LLMs-in-coding is that they will provide an unlimited flow of "mess around until it works" drudgery tasks with none of the upside.

I feel like its very true to the hacker spirit to spend more time customizing your text editor than actually programming, so i guess this is just the natural extension.

Post reply on HN