Comment by NumberCruncher | Hacker News Reader

Comment by NumberCruncher | Hacker News Reader

I don’t really understand why there’s so much hate for LLMs here, especially when it comes to using them for coding. In my experience, the people who regularly complain about these tools often seem more interested in proving how clever they are than actually solving real problems. They also tend to choose obscure programming languages where it’s nearly impossible to hire developers, or they spend hours arguing over how to save $20 a month.

Over time, they usually get what they want: they become the smartest ones left in the room, because all the good people have already moved on. What’s left behind is a codebase no one wants to work on, and you can’t hire for it either.

But maybe I’ve just worked with the wrong teams.

EDIT: Maybe this is just about trust. If you can’t bring yourself to trust code written by other human beings, whether it’s a package, a library, or even your own teammates, then of course you’re not going to trust code from an LLM. But that’s not really about quality, it’s about control. And the irony is that people who insist on controlling every last detail usually end up with fragile systems nobody else wants to touch, and teams nobody else wants to join.

It has been discussed ad nauseum. It demolishes learning curve all of us with decade(s) of experience went through, to become seniors we are. Its not a function of age, not a function of time spent staring at some screen or churning our basic crud apps, its function of hard experience, frustration, hard won battles, grokking underlying technologies or algorithms.

Llms provide little of that, they make people lazy, juniors stay juniors forever, even degrading mentally in some aspects. People need struggle to grow, when you have somebody who had his hand held whole life they are useless human disconnected from reality, unable to self-sufficiently achieve anything significant. Too easy life destroys both humans and animals alike (many experiments have been done on that, with damning results).

There is much more like hallucinations, questionable added value of stuff that confidently looks OK but has underlying hard-to-debug bugs but above should be enough for a start.

I suggest actually reading those conversations, not just skimming through them, this has been stated countless times.

I regularly check in on using LLMs. But a key criteria for me is that an LLM needs to objectively make me more efficient, not subjectively.

Often I find myself cursing at the LLM for not understanding what I mean - which is expensive in lost time / cost of tokens.

It is easy to say: Then just don't use LLMs. But in reality, it is not too easy to break out of these loops of explaining, and it is extremely hard to assess when not to trust that the LLM will not be able to finish the task.

I also find that LLMs consistently don't follow guidelines. Eg. to never use coercions in TypeScript (It always gets in a rogue `as` somewhere) - to which I can not trust the output and needs to be extra vigilant reviewing.

I use LLMs for what they are good at. Sketching up a page in React/Tailwind, sketching up a small test suite - everything that can be deemed a translation task.

I don't use LLMs for tasks that are reasoning heavy: Data modelling, architecture, large complex refactors - things that require deep domain knowledge and reasoning.

> Often I find myself cursing at the LLM for not understanding what I mean...

Me too. But in all these cases, sooner or later, I realized I made a mistake not giving enough context and not building up the discussion carefully enough. And I was just rushing to the solution. In the agile world, one could say I gave the LLM not a well-defined story, but a one-liner. Who is to blame here?

I still remember training a junior hire who started off with:

“Sorry, I spent five days on this ticket. I thought it would only take two. Also, who’s going to do the QA?”

After 6 months or so, the same person was saying:

“I finished the project in three weeks. I estimated four. QA is done. Ready to go live.”

At that point, he was confident enough to own his work end-to-end, even shipping to production without someone else reviewing it. Interestingly, this colleague left two years ago, and I had to take over his codebase. It’s still running fine today, and I’ve spent maybe a single day maintaining it in the last two years.

Recently, I was talking with my manager about this. We agreed that building confidence and self-checking in a junior dev is very similar to how you need to work with LLMs.

Personally, whenever I generate code with an LLM, I check every line before committing. I still don’t trust it as much as the people I trained.

> ... Who is to blame here?

That is not really relevant, is it? The LLM is not a human.

The question is whether it is still af efficient to use LLMs after spending huge amounts of time giving the context - or if it is just as efficient to write the code yourself.

> I still remember training a junior hire who started off with

Working with LLMs is not training junior developers - treating it as such is yet another resource sink.

I think we have to agree that we disagree. What works for you doesn't have to work for me and vice-versa.

If you want to sit and throw tokens after thinking you are treating an LLM like a junior developer, all power to you.

Meanwhile, I think I will stick to get tangible performance benefits out if its usage.

Reply on news.ycombinator.com