Live data from Hacker News

Some thoughts on LLMs and software development

martinfowler.com

221–230 of 422 posts

Re: Some thoughts on LLMs and software development

#221

Earlier quoted context omitted.

"but quality is definitely taking a hit now that no-one is able to keep up." And its going to get worse! So please explain to me how in the net, you are going to be better off? You're not. I think most people haven't taken a decent economics class and don't deeply understand the notion of trade offs and the fact there is no free lunch.

Technology has always helped people. Are you one of the people that say optimizing compilers are bad? Do you not use the intellisense? Or IDEs? Do you not use higher level languages? Why not write in assembly all the time? No free lunch right. Yes there are trade offs, but at this point if you haven’t found a way to significantly amplify and scale yourself using llms, and your plan is to instead pretend that they are…

Technology does not always help people, in fact often it creates new problems that didn't exist before.

Also telling someone to "adapt to the times" is a bit silly. If it helped as much as its claimed, there wouldn't be any need to try and convince people they should be using it.

A LOT of parallels with crypto, which is still trying to find its killer app 16 years later.

Re: Some thoughts on LLMs and software development

#222

Earlier quoted context omitted.

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.

No one seems to be able to grasp the possibility that AI is a failure

Re: Some thoughts on LLMs and software development

#223
post #134

Earlier quoted context omitted.

More of a error-correcting feedback loop rather than a filter, really. Which is very much what we do as humans, apparently. One recent theory of neuroscience that is becoming influential is Predictive Processing -- https://en.wikipedia.org/wiki/Predictive_coding -- this postulates that we also constantly generate a "mental model" of our environment (a literal "prediction") and use sensory inputs to correct and update…

You ever see something out of the corner of your eye and you were mistaken? It feels like LLM hallucinations. "An orange cat on my counter?!" And an instant later, your brain has reclassified "a basketball on my counter" as that fits the environment model better as several instant-observations gather contexts: not moving, more round, not furry, I don't own a cat, yesterday my kid mentioned something about tryouts, bo…

I leaned heavily on my own meta cognition recently when withdrawing from a bereavment benzo habit recently. The combo of flu symptoms, anxiety and hallucinations are fierce. I knew O was seeing things that were not real; light fittings turning into a rotating stained glass slideshow. So I'm totally on board with the visual model hypothesis. My own speculation is that audio perception is less predictive as audio structure persists deeper into my own DMT sessions than does vision, where perspective quickly collapses and vision becomes kaleidoscopic. Which may be a return to the vision we had as newborns. Maybe normal vision is only attained via socialisation?

Re: Some thoughts on LLMs and software development

#224
post #211
post #151

Earlier quoted context omitted.

LLMs (Sonnet, Gemini from what I tested) tend to “fix” failing tests by either removing them outright or tweaking the assertions just enough to make them pass. The opposite happens too - sometimes they change the actual logic when what really needs updating is the test. In short, LLMs often get confused about where the problem lies: the code under test or the test itself. And no amount of context engineering seems to…

I think in part the issue is that the LLM does not have enough context. The difference between a bug in the test or a bug in the implementation is purely based on the requirements which are often not in the source code and stored somewhere else(ticket system, documentation platform). Without providing the actual feature requirements to the LLM(or the developer) it is impossible to determine which is wrong. Which is w…

Oh, absolutely, context matters a lot. But the thing is, they still fail even with solid context.

Before I let an agent touch code, I spell out the issue/feature and have it write two markdown files - strategy.md and progress.md (with the execution order of changes) inside a feat_{id} directory. Once I’m happy with those, I wipe the context and start fresh: feed it the original feature definition + the docs, then tell it to implement by pulling in the right source code context. So by the time any code gets touched, there’s already ~80k tokens in play. And yet, the same confusion frequently happens.

Even if I flat out say “the issue is in the test/logic,”, even if I point out _exactly_ what the issue is, it just apologizes and loops.

At that point I stop it, make it record the failure in the markdown doc, reset context, and let it reload the feature plus the previous agent’s failure. Occasionally that works, but usually once it’s in that state, I have to step in and do it myself.

Re: Some thoughts on LLMs and software development

#225

Earlier quoted context omitted.

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.

If poor work gets merged, the responsibility lies in who wrote it, who merged it, and who allows such a culture.

The tools used do not hold responsibilities, they are tools.

Re: Some thoughts on LLMs and software development

#226

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 an auditable entity in regulated businesses, like banks. Fowler suggests we get more comfortable with uncertainty because other eng domains have developed good risk mgmt. Cart before horse. Other engineering domains strive to mitigate the irreducible uncertainty of the physical world. AI adds uncertainty to any system. And there are many applications where increased uncertainty will lead to an increase in human suffering.

Re: Some thoughts on LLMs and software development

#227

Earlier quoted context omitted.

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.

How could a tool be at fault? If an airplane crashes is the plane at fault or the designers, engineers, and/or pilot?

Re: Some thoughts on LLMs and software development

#228

Earlier quoted context omitted.

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

No one seems to be able to grasp the possibility that AI is a failure

> No one seems to be able to grasp the possibility that AI is a failure.

Do you think by the time GPT-9 comes, we'll say "That's it, AI is a failure, we'll just stop using it!"

Or do you speak in metaphorical/bigger picture/"butlerian jihad" terms?

Re: Some thoughts on LLMs and software development

#229

Earlier quoted context omitted.

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

No one seems to be able to grasp the possibility that AI is a failure

You've failed to figure out when and how to use it. It's not a binary failed/succeeded thing.

Re: Some thoughts on LLMs and software development

#230

Earlier quoted context omitted.

Technology has always helped people. Are you one of the people that say optimizing compilers are bad? Do you not use the intellisense? Or IDEs? Do you not use higher level languages? Why not write in assembly all the time? No free lunch right. Yes there are trade offs, but at this point if you haven’t found a way to significantly amplify and scale yourself using llms, and your plan is to instead pretend that they are…

Technology does not always help people, in fact often it creates new problems that didn't exist before. Also telling someone to "adapt to the times" is a bit silly. If it helped as much as its claimed, there wouldn't be any need to try and convince people they should be using it. A LOT of parallels with crypto, which is still trying to find its killer app 16 years later.

My parents could have said your first paragraph when I tried to teach them they could Google their questions and find answers.

Technology moves forward and productivity improves for those that move with it.

Post reply on HN