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

61–70 of 422 posts

Re: Some thoughts on LLMs and software development

#61

Post by ninetyninenine »

ants_everywhere wrote: post #58
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…

an LLM hallucination is defined by its truth > In the field of artificial intelligence (AI), a hallucination or artificial hallucination (also called confabulation,[1] or delusion)[2] is a response generated by AI that contains false or misleading information presented as fact.[3][4] You say > This is different from human hallucinations where it makes something up because of something wrong with the mind rather than…

Even the colloquial term outside of AI is characterized by the veracity of the output.

Re: Some thoughts on LLMs and software development

#62

Post by daviding »

I get a lot of productivity out of LLMs so far, which for me is a simple good sign. I can get a lot done in a shorter time and it's not just using them as autocomplete. There is this nagging doubt that there's some debt to pay one day when it has too loose a leash, but LLMs aren't alone in that problem.

One thing I've done with some success is use a Test Driven Development methodology with Claude Sonnet (or recently GPT-5). Moving forward the feature in discrete steps with initial tests and within the red/green loop. I don't see a lot written or discussed about that approach so far, but then reading Martin's article made me realize that the people most proficient with TDD are not really in the Venn Diagram intersection of those wanting to throw themselves wholeheartedly into using LLMs to agent code. The 'super clippy' autocomplete is not the interesting way to use them, it's with multiple agents and prompt techniques at different abstraction levels - that's where you can really cook with gas. Many TDD experts have great pride in the art of code, communicating like a human and holding the abstractions in their head, so we might not get good guidance from the same set of people who helped us before. I think there's a nice green field of 'how to write software' lessons with these tools coming up, with many caution stories and lessons being learnt right now.

edit: heh, just saw this now, there you go - https://news.ycombinator.com/item?id=45055439

Re: Some thoughts on LLMs and software development

#63

Post by ants_everywhere »

skydhash wrote: post #60
ants_everywhere wrote: post #55

Earlier quoted context omitted.

adding to this, software deals with non-determinism all the time. For example, web requests are non-deterministic. They depend, among other things, on the state of the network. They also depend on the load of the machine serving the request. One way to think about this is: how easy is it for you to produce byte-for-byte deterministic builds of the software you're working on? If it's not trivial there's more non-deter…

Mostly the engineering part of software is dealing with non-determinism, by avoiding it or enforcing determinism. Take something like TCP, it's all about guaranteeing the determinism that either the message is sent and received or it is not. And we have a lot of algorithms that tries to guarantee consistency of information between the elements of a system.

Right, you handle determinism by applying engineering. E.g. having fail safes, redundancies, creating robust processes, etc.

Re: Some thoughts on LLMs and software development

#64

Post by Lionga »

tptacek wrote: post #45
Lionga wrote: post #42

Earlier quoted context omitted.

Isn't an "agent" not just hallucinations layered on top of other random hallucinations to create new hallucinations?

No, that's exactly what an agent isn't . What makes an agent an agent is all the not -LLM code. When an agent generates Golang code, it runs the Go compiler, which is in the agent's architecture an extension of the agent. The Go compiler does not hallucinate.

The most common "agent" is an letting an LLM run a while loop (“multi-step agent”) [1]

[1] https://huggingface.co/docs/smolagents/conceptual_guides/int...

Re: Some thoughts on LLMs and software development

#65

Post by pton_xd »

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…

Agreed. The beauty of programming is that you're creating a "mathematical artifact." You can always drill down and figure out exactly what is going on and what is going to happen with a given set of inputs. Now with things like concurrency that's not exactly true, but, I think the sentiment still holds.

The more practical question is though, does that matter? Maybe not.

Re: Some thoughts on LLMs and software development

#66

Post by tra3 »

daviding wrote: post #62

I get a lot of productivity out of LLMs so far, which for me is a simple good sign. I can get a lot done in a shorter time and it's not just using them as autocomplete. There is this nagging doubt that there's some debt to pay one day when it has too loose a leash, but LLMs aren't alone in that problem. One thing I've done with some success is use a Test Driven Development methodology with Claude Sonnet (or recently…

It feels like Tdd/llm connection is implied — “and also generate tests”. Thought it’s not cannonical tdd of course. I wonder if it’ll turn the tide towards tech that’s easier to test automatically, like maybe ssr instead of react.

Re: Some thoughts on LLMs and software development

#67

Post by ares623 »

skydhash wrote: post #60
ants_everywhere wrote: post #55

Earlier quoted context omitted.

adding to this, software deals with non-determinism all the time. For example, web requests are non-deterministic. They depend, among other things, on the state of the network. They also depend on the load of the machine serving the request. One way to think about this is: how easy is it for you to produce byte-for-byte deterministic builds of the software you're working on? If it's not trivial there's more non-deter…

Mostly the engineering part of software is dealing with non-determinism, by avoiding it or enforcing determinism. Take something like TCP, it's all about guaranteeing the determinism that either the message is sent and received or it is not. And we have a lot of algorithms that tries to guarantee consistency of information between the elements of a system.

But there is an underlying deterministic property in the TCP example. A message is either received within a timeout or not.

How can that be extralopated with LLMs? How does a system independently know that it's arrived at a correct answer within a timeout or not? Has the halting problem been solved?

Re: Some thoughts on LLMs and software development

#68

Post by Scubabear68 »

"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 wrong. He's trying to say the LLM is hallucinating everything, but Fowler is missing is that Hallucination in LLM terms refers to a very specific negative behavior.

Re: Some thoughts on LLMs and software development

#69

Post by sodapopcan »

tptacek wrote: post #51
sodapopcan wrote: post #37

Earlier quoted context omitted.

As pertaining to software development, I agree. I've been hearing accounting (online and from coworkers) of using LLMs to do deterministic stuff. And yet, instead of at least prompting once to "write a script to do X," they just keep prompting "do X" over and over again. Seems incredibly wasteful. It feels like there is this thought of "We are not making progress if we aren't getting the LLM to do everything. Having…

This is the 2025 equivalent of the people who once wrote 2000 word blog posts about how bad it was to use "cat" instead of just shell redirection.

These are hardly equivalent. One is someone preferring one deterministic way over another. The other is more akin to arguing that it's better to ask someone to manually complete a task for you instead of caching the instructions on your computer. Now if the LLM does caching then you have more of a point, I don't have enough experience there.

Re: Some thoughts on LLMs and software development

#70

Post by krainboltgreene »

sfink wrote: post #10
krainboltgreene wrote: post #3

> All major technological advances have come with economic bubbles, from canals and railroads to the internet. Is this actually correct? I don't see any evidence for a "airflight bubble" or a "car bubble" or a "loom bubble" at the technologies' invention. Also the "canal bubble" wasn't about the technology, it was about the speculation on a series of big canals but we had been making canals for a long time. More impo…

Apologies for arguing from first principles, but for anything that spurs a lot of activity, the only alternative to a bubble is this: people ramp up investment and activity and enthusiasm only as much as the underlying thing can handle, then gradually taper off the increase and gently level off at the equilibrium "carrying capacity" of the new technology. Does that sound like any human, ever, to you? (The only time t…

If you were right then we'd have a lot more than a dozen listed bubbles on wikipedia.

That's an absurd framing for a cute quip.

Post reply on HN