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

171–180 of 422 posts

Re: Some thoughts on LLMs and software development

#171

Post by daveguy »

epolanski wrote: post #114
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?

I would expect it to be almost tautologically true. It's the easiest to implement, and the most deployed. It has to be the most used, even if a lot of people don't know they're using it.

It was the original success of LLMs -- code autocomplete. All of the agentic coding have autocomplete under the hood. Autocomplete is almost literally what LLMs do + post-processing.

Re: Some thoughts on LLMs and software development

#172

Post by FromTheFirstIn »

epolanski wrote: post #108
jeppester wrote: post #107

In my company I feel that we getting totally overrun with code that's 90% good, 10% broken and almost exactly what was needed. We are producing more code, but quality is definitely taking a hit now that no-one is able to keep up. So instead of slowly inching towards the result we are getting 90% there in no time, and then spending lots and lots of time on getting to know the code and fixing and fine-tuning everything…

As Fowler himself states, there's a need to learn to use these tools properly. In any case poor work quality is a failure of tech leadership and culture, it's not AI's fault.

It’s funny how nothing seems to be AI’s fault.

Re: Some thoughts on LLMs and software development

#175

Post by weakfish »

epolanski wrote: post #115
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.

I think this gets lost on far too many discussions. There is no “why” - it’s statistics, and the closest we have to a “why” is that a lot of code out there sucks

Re: Some thoughts on LLMs and software development

#176

Post by x0x0 »

anskskbs wrote: post #76
skhameneh wrote: post #52

Earlier quoted context omitted.

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.

> It's an active engagement and best results are achieved when everything is planned and laid out in advance The most efficient way to communicate these plans is in code. English is horrible in comparison. When you’re using an agent and not reviewing every line of code, you’re offloading thinking to the AI. Which is fine in some scenarios, but often not what people would call high quality software. Writing code was n…

ime this is the problem. When I have to deeply understand what an llm created, I don't see much of a speed improvement vs writing it myself.

With an engineer you can hand off work and trust that it works, whereas I find code reviewing llm output something that I have to treat as hostile. It will comment out auth or delete failing tests.

Re: Some thoughts on LLMs and software development

#177

Post by Arubis »

amelius wrote: post #131
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!

> and they don't get mad when you fire them! No, typically __you__ are mad when you fire them ...

If you’re making hire/fire decisions while emotional, you’re doing it wrong.

Re: Some thoughts on LLMs and software development

#179

Post by kurtis_reed »

Arubis wrote: post #177
amelius wrote: post #131

Earlier quoted context omitted.

> and they don't get mad when you fire them! No, typically __you__ are mad when you fire them ...

If you’re making hire/fire decisions while emotional, you’re doing it wrong.

Whoosh

Re: Some thoughts on LLMs and software development

#180

Post by skydhash »

ares623 wrote: post #67
skydhash wrote: post #60

Earlier quoted context omitted.

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?

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

That's the catch 22 with LLM. You're supposed to be both the asker and the verifier. Which in practice, it's not that great. LLMs will just find the snippets of code that matches somehow and just act on it (It's the "I'm feeling Lucky" button with extra steps)

In traditional programming, coding is a notation too more than anything. You supposed to have a solution before coding, but because of how the human brain works, it's more like a blackboard, aka an helper for thinking. You write what you think is correct, verify your assumptions, then store and forget about all of it when that's true. Once in a while, you revisit the design and make it more elegant (at least you hope you're allowed to).

LLM programming, when first started, was more about a direct english to finished code translation. Now, hope has scaled down and it's more about precise specs to diff proposal. Which frankly does not improve productivity as you can either have a generator that's faster and more precise (less costly too) or you will need to read the same amount of docs to verify everything as you would need to do to code the stuff in the first place (80% of the time spent coding).

So no determinism with LLMs. The input does not have any formal aspects, and the output is randomly determined. And the domain is very large. It is like trying to find a specific grain of sand on a beach while not fully sure it's there. I suspect most people are doing the equivalent of taking a handful of sand and saying that's what they wanted all along.

Post reply on HN