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

51–60 of 422 posts

Re: Some thoughts on LLMs and software development

#51

Post by tptacek »

sodapopcan wrote: post #37
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!

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.

Re: Some thoughts on LLMs and software development

#52

Post by skhameneh »

manmal wrote: post #44
skhameneh wrote: post #36

There are many I've worked with that idolize Martin Fowler and have treated his words as gospel. That is not me and I've found it to be a nuisance, sometimes leading me to be overly critical of the actual content. As for now, I'm not working with such people and can appreciate the article shared without clouded bias. I like this article, I generally agree with it. I think the take is good. However, after spending rid…

> 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.

Re: Some thoughts on LLMs and software development

#53

Post by Towaway69 »

rancar2 wrote: post #12

My favorite quote to borrow: “Furthermore I think anyone who says they know what this future will be is talking from an inappropriate orifice.”

Predicting the future isn't about being correct tomorrow, rather it’s about selling something to someone today.

An insight I picked up along the way…

Re: Some thoughts on LLMs and software development

#54

Post by armchairhacker »

tptacek wrote: post #18
sebnukem2 wrote: post #6

> hallucinations aren’t a bug of LLMs, they are a feature. Indeed they are the feature. All an LLM does is produce hallucinations, it’s just that we find some of them useful. Nice.

In that framing, you can look at an agent as simply a filter on those hallucinations.

This vaguely relates to a theory about human thought: that our subconscious constantly comes up with random ideas, then filters the unreasonable ones, but in people with delusions (e.g. schizophrenia) the filter is broken.

Salience (https://en.wikipedia.org/wiki/Salience_(neuroscience)), "the property by which some thing stands out", is something LLMs have trouble with. Probably because they're trained on human text, which ranges from accurate descriptions of reality to nonsense.

Re: Some thoughts on LLMs and software development

#55

Post by ants_everywhere »

tptacek wrote: post #50
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!

'potatolicious says we're going forwards : https://news.ycombinator.com/item?id=44978319

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-determinism than is obvious.

Re: Some thoughts on LLMs and software development

#56

Post by sfink »

skhameneh wrote: post #36

There are many I've worked with that idolize Martin Fowler and have treated his words as gospel. That is not me and I've found it to be a nuisance, sometimes leading me to be overly critical of the actual content. As for now, I'm not working with such people and can appreciate the article shared without clouded bias. I like this article, I generally agree with it. I think the take is good. However, after spending rid…

> We are headed in a direction where written code is no longer a time sink.

Written code has never been a time sink. The actual time that software developers have spent actually writing code has always been a very low percentage of total time.

Figuring out what code to write is a bigger deal. LLMs can help with part of this. Figuring out what's wrong with written code, and figuring out how to change and fix the code, is also a big deal. LLMs can help with a smaller part of this.

> Juniors can onboard faster and more independently with LLMs,

Color me very, very skeptical of this. Juniors previously spent a lot more of their time writing code, and they don't have to do that anymore. On the other hand, that's how they became not-juniors; the feedback loop from writing code and seeing what happened as a result is the point. Skipping part of that breaks the loop. "What the computer wrote didn't work" or "what the computer wrote is too slow" or even to some extent "what the computer wrote was the wrong thing" is so much harder to learn from.

Juniors are screwed.

> LLMs have the ability to lighten cognitive loads and increase productivity,

I'm fascinated to find out where this is true and where it's false. I think it'll be very unevenly distributed. I've seen a lot of silver bullets fired and disintegrate mid-flight, and I'm very doubtful of the latest one in the form of LLMs. I'm guessing LLMs will ratchet forward part of the software world, will remove support for other parts that will fall back, and it'll take us way too long to recognize which part is which and how to build a new system atop the shifted foundation.

Re: Some thoughts on LLMs and software development

#57

Post by AaronAPU »

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!

It was forward when Newton discovered the beautiful simple determinism of physics.

Was it going backwards when the probabilistic nature of quantum mechanics emerged?

Re: Some thoughts on LLMs and software development

#58

Post by ants_everywhere »

xmprt wrote: post #43
ninetyninenine wrote: post #27

Earlier quoted context omitted.

Nah I don't agree with this characterization. The problem is, the majority of those hallucinations are true. What was said would make more sense if the majority of the responses were, in fact, false, but this is not the case.

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 some underlying issue with the brain's architecture.

For consistency you might as well say everything the human mind does is hallucination. It's the same sort of claim. This claim at least has the virtue of being taken seriously by people like Descartes.

https://en.wikipedia.org/wiki/Hallucination_(artificial_inte...

Re: Some thoughts on LLMs and software development

#59

Post by [deleted] »

tptacek wrote: post #50
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!

'potatolicious says we're going forwards : https://news.ycombinator.com/item?id=44978319

[deleted]

Re: Some thoughts on LLMs and software development

#60

Post by skydhash »

ants_everywhere wrote: post #55
tptacek wrote: post #50

Earlier quoted context omitted.

'potatolicious says we're going forwards : https://news.ycombinator.com/item?id=44978319

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.
Post reply on HN