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

Some thoughts on LLMs and software development

martinfowler.com

Post reply on HN
Print view View original

111–120 of 422 posts

Re: Some thoughts on LLMs and software development

#111

Post by Guthur »

furyofantares wrote: post #99
nicwolff wrote: post #81

> I’ve often heard, with decent reason, an LLM compared to a junior colleague. No, they're like an extremely experienced and knowledgeable senior colleague – who drinks heavily on the job. Overconfident, forgetful, sloppy, easily distracted. But you can hire so many of them, so cheaply, and they don't get mad when you fire them!

These metaphors all suck. Well, ok, yours is funny. But anyway, LLMs are just very different from any human. They are extremely shallow, even compared to a junior developer. But extremely broad, even compared to the most experienced developer. They type real fuckin fast compared to anyone on earth, but they need to be told what to do much more carefully than anyone on earth.

I just spent a good 2 hours trying to debug a SM6 Vulkan issue with unreal engine using an LLM, it had got me to good state but UE kept falling to load a project, it transpired that the specific error message would provide a fix as the top Google result, which I found when I eventually decided to look for myself.

LLM did help a lot to get some busy work out of the way, but it's difficult to know when you need to jump out of the LLM loop and go old skool.

Re: Some thoughts on LLMs and software development

#112

Post by epolanski »

Scubabear68 wrote: post #68

"Hallucinations aren’t a bug of LLMs, they are a feature. Indeed they are the feature". I used to avidly read all his stuff, and I remember 20ish years ago he decided to rename Inversion of Control to Dependency Injection. In doing so, and his accompany blog, he showed he didn't actually understand it at a deep level (and hence his poor renaming). This feels similar. I know what he's trying to say, but he's just wron…

I'll take the bait.

What didn't he understand properly about inversion of control then.

Re: Some thoughts on LLMs and software development

#113

Post by stillsut »

> we should always consider asking the LLM the same question more than once, perhaps with some variation in the wording. Then we can compare answers,

Yup, this matches my recommended workflow exactly. Why waste time trying to turn an initially bad answer into a passable one, when you could simply re-generate (possibly with different context)

I wrote up an example of this workflow here: https://github.com/sutt/agro/blob/master/docs/case-studies/a...

Re: Some thoughts on LLMs and software development

#114

Post by epolanski »

iLoveOncall wrote: post #38

> One of the big problems with these surveys is that they aren’t taking into account how people are using the LLMs. From what I can tell the vast majority of LLM usage is fancy auto-complete, often using co-pilot. This is a completely wrong assumption and negates a bunch of the points of the article...

How is it wrong?

Do you have any hard number and data to state that tab/auto complete are less popular than agentic coding?

Re: Some thoughts on LLMs and software development

#115

Post by epolanski »

insane_dreamer wrote: post #75

> I’ve often heard, with decent reason, an LLM compared to a junior colleague. But I find LLMs are quite happy to say “all tests green”, yet when I run them, there are failures. If that was a junior engineer’s behavior, how long would it be before H.R. was involved? Reminds me of a recent experience when I asked CC to implement a feature. It wrote some code that struck me as potentially problematic. When I said, "why…

It did so because his training, weights and context and a billion of matrix calculations led him there.

Re: Some thoughts on LLMs and software development

#116

Post by Scubabear68 »

epolanski wrote: post #112
Scubabear68 wrote: post #68

"Hallucinations aren’t a bug of LLMs, they are a feature. Indeed they are the feature". I used to avidly read all his stuff, and I remember 20ish years ago he decided to rename Inversion of Control to Dependency Injection. In doing so, and his accompany blog, he showed he didn't actually understand it at a deep level (and hence his poor renaming). This feels similar. I know what he's trying to say, but he's just wron…

I'll take the bait. What didn't he understand properly about inversion of control then.

That it is ultimately about object lifetime management. Dependency injection is a big part of it, but not the only thing.

Re: Some thoughts on LLMs and software development

#117

Post by Scubabear68 »

ares623 wrote: post #74
Scubabear68 wrote: post #68

"Hallucinations aren’t a bug of LLMs, they are a feature. Indeed they are the feature". I used to avidly read all his stuff, and I remember 20ish years ago he decided to rename Inversion of Control to Dependency Injection. In doing so, and his accompany blog, he showed he didn't actually understand it at a deep level (and hence his poor renaming). This feels similar. I know what he's trying to say, but he's just wron…

As far as an LLM is concerned, there is no difference between "negative" hallucination and a positive one. It's all just tokens and embeddings to it. Positive hallucinations are more likely to happen nowadays, thanks to all the effort going into these systems.

This basically ruins the term “hallucination” and makes it meaningless, when the term actually describes a real phenomenon.

Re: Some thoughts on LLMs and software development

#118

Post by mehagar »

skhameneh wrote: post #52
manmal wrote: post #44

Earlier quoted context omitted.

> written code is no longer a time sink It still is, and should be. It’s highly unlikely that you provided all the required info to the agent at first try. The only way to fix that is to read and understand the code thoroughly and suspiciously, and reshaping it until we’re sure it reflects the requirements as we understand them.

Vibe coding is not telling an agent what to do and checking back. It's an active engagement and best results are achieved when everything is planned and laid out in advance — which can also be done via vibe coding. No, written code is no longer a time sink. Vibe coding is >90% building without writing any code. The written code and actions are literally presented in diffs as they are applied, if one so chooses.

How could you possibly plan out "everything" in advance? Code itself would be the only way to explicitly specify the "everything".

Re: Some thoughts on LLMs and software development

#119

Post by ninetyninenine »

BlueTemplar wrote: post #94
xmprt wrote: post #43

Earlier quoted context omitted.

I think you're both correct but have different definitions of hallucinations. You're judging it as a hallucination based on the veracity of the output. Whereas Fowler is judging it based on the method by which the output is achieved. By that judgement, everything is a hallucination because the user cannot differentiate between when the LLM is telling the truth and isn't. This is different from human hallucinations wh…

LLMs don't hallucinate : they bullshit (which is not caring about truth).

This isn't a good characterization of it either. I don't think LLMs know the difference. Bullshit implies they are lying.

It's possible LLMs are lying but my guess is that they really just can't tell the difference.

Re: Some thoughts on LLMs and software development

#120

Post by whartung »

didericis wrote: post #39
ares623 wrote: post #25

> Other forms of engineering have to take into account the variability of the world. > Maybe LLMs mark the point where we join our engineering peers in a world on non-determinism. Those other forms of engineering have no choice due to the nature of what they are engineering. Software engineers already have a way to introduce determinism into the systems they build! We’re going backwards!

Part of what got me into software was this: no matter how complex or impressive the operation, with enough time and determination, you could trace each step and learn how a tap on a joystick lead to the specific pixels on a screen changing. There’s a beautiful invitation to learn and contribute baked into a world where each command is fully deterministic and spec-ed out. Yes, there have always been poorly documented…

"Computers are deterministic!"

If I wanted to plumb together badly documented black boxes, I'd have become an EE.

Post reply on HN